diff options
Diffstat (limited to 'RFC')
37 files changed, 53635 insertions, 0 deletions
diff --git a/RFC/draft-klensin-cram-03.txt b/RFC/draft-klensin-cram-03.txt new file mode 100644 index 00000000..bfac1d5b --- /dev/null +++ b/RFC/draft-klensin-cram-03.txt @@ -0,0 +1,261 @@ +
+Network Working Group J Klensin
+Internet Draft R Catoe
+Document: draft-klensin-cram-03.txt P Krumviede
+ MCI
+ September 1996
+
+
+
+
+ IMAP/POP AUTHorize Extension for Simple Challenge/Response
+
+Status of this Memo
+
+ This document is an Internet Draft. Internet Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its Areas,
+ and its Working Groups. Note that other groups may also distribute
+ working documents as Internet Drafts.
+
+ Internet Drafts are draft documents valid for a maximum of six
+ months. Internet Drafts may be updated, replaced, or obsoleted by
+ other documents at any time. It is not appropriate to use Internet
+ Drafts as reference material or to cite them other than as a
+ ``working draft'' or ``work in progress``.
+
+ To learn the current status of any Internet-Draft, please check the
+ 1id-abstracts.txt listing contained in the Internet-Drafts Shadow
+ Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
+ munnari.oz.au.
+
+ A revised version of this draft document will be submitted to the
+ IESG for processing as a Proposed Standard for the Internet
+ Community, updating RFC 1731. Discussion and suggestions for
+ improvement are requested. This document reflects editorial
+ comments received during the last call period; the protocol is
+ unchanged from the previous version. This draft will expire
+ before February 22, 1997. Distribution of this draft 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.
+
+ 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".
+
+ 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 draft
+ [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
+
+
+
+3. References
+
+ [CHAP] Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
+ RFC 1334, October 1992.
+
+ [IMAP] Crispin, M. "Internet Message Access Protocol - Version 4",
+ RFC 1730, University of Washington, December, 1994.
+
+ [IMAP-AUTH] Myers, J. "IMAP4 Authentication Mechanisms",
+ RFC 1731, Carnegie Mellon, December, 1994
+
+ [KEYED-MD5] Krawczyk, H "HMAC-MD5: Keyed-MD5 for Message
+ Authentication" work in progess (draft-ietf-ipsec-hmac-md5-00.txt),
+ IBM, March 1996.
+
+ [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 ",
+ RFC 1939 (STD 53), 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 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 current draft.
+
+
+6. Authors' Addresses
+
+ John C. Klensin
+ MCI Telecommunications
+ 800 Boylston St, 7th floor
+ Boston, MA 02199
+ USA
+ Email: klensin@mci.net
+ Tel: +1 617 960 1011
+
+ Randy Catoe
+ MCI Telecommunications
+ 2100 Reston Parkway
+ Reston, VA 22091
+ USA
+ Email: randy@mci.net
+ Tel: +1 703 715 7366
+
+ Paul Krumviede
+ MCI Telecommunications
+ 2100 Reston Parkway
+ Reston, VA 22091
+ USA
+ Email: paul@mci.net
+ Tel: +1 703 715 7251
+
+
diff --git a/RFC/draft-newman-tls-imappop-05.txt b/RFC/draft-newman-tls-imappop-05.txt new file mode 100644 index 00000000..680556e8 --- /dev/null +++ b/RFC/draft-newman-tls-imappop-05.txt @@ -0,0 +1,618 @@ + + + + + + +Network Working Group C. Newman +Internet Draft: Using TLS with IMAP4, POP3 and ACAP Innosoft +Document: draft-newman-tls-imappop-05.txt November 1998 + + + Using TLS with IMAP4, POP3 and ACAP + + +Status of this memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + To view the entire list of current Internet-Drafts, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net + (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au + (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US + West Coast). + +Abstract + + This specification defines extensions to IMAP [IMAP4], POP [POP3] + and ACAP [ACAP] which activate TLS [TLS]. This also defines a + simple PLAIN SASL [SASL] mechanism for use underneath strong TLS + encryption with ACAP or other protocols lacking a clear-text login + command. + +1. Motivation + + The TLS protocol [TLS] (formerly known as SSL) provides a way to + secure a TCP connection from tampering and eavesdropping. + Obviously, the option of using such security is desirable for IMAP + [IMAP4], POP [POP3] and ACAP [ACAP]. Although advanced SASL [SASL] + authentication mechanisms can provide a lightweight version of this + service, TLS is a full service security layer and is complimentary + to simple authentication-only SASL mechanisms or clear-text + password login commands. Furthermore, many sites have a high + investment in authentication infrastructure (e.g., a large database + of a one-way-function applied to user passwords), so a privacy + + + +Newman [Page 1] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + layer which is not tightly bound to user authentication can protect + against network eavesdropping attacks without requiring a new + authentication infrastructure and/or forcing all users to change + their password. + +1.1. Conventions Used in this Document + + The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD + NOT", "MAY", and "OPTIONAL" in this document are to be interpreted + as described in "Key words for use in RFCs to Indicate Requirement + Levels" [KEYWORDS]. + + Formal syntax is defined using ABNF [ABNF]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +2. Basic Interoperability and Security Requirements + + The following requirements apply to all implementations of the + STARTTLS extension for IMAP4, POP3 and ACAP. + +2.1. Cipher Suite Requirements + + Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher + suite is REQUIRED. This is important as it assures that any two + compliant implementations can be configured to interoperate. + + All other cipher suites are OPTIONAL. + +2.2. TLS Operational Mode Security Requirements + + Both clients and servers SHOULD have an operational mode where use + of TLS encryption is required to login. Clients MAY have an + operational mode where TLS is used only when advertised by the + server, but login occurs regardless. For backwards compatibility, + servers SHOULD have an operational mode which permits clients to + login when TLS is not used. + +2.3. Clear-Text Password Requirement + + A server which implements both STARTTLS and a clear-text password + authentication mechanism (including but not limited to the IMAP4 + LOGIN command, POP3 PASS command and the PLAIN mechanism in section + 6) MUST have an operational mode where all clear-text login + commands and mechanisms are disabled unless TLS encryption is + active. + + + + +Newman [Page 2] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + +2.4. Server Identity Check + + During the TLS negotiation, the client MUST check its understanding + of the server hostname against the server's identity as presented + in the server Certificate message, in order to prevent + man-in-the-middle attacks. Matching is performed according to + these rules: + + o The client MUST use the server hostname it used to open the + connection as the value to compare against the server name as + expressed in the server certificate. The client MUST NOT use + any form of the server hostname derived from an insecure remote + source (e.g., insecure DNS reverse lookup). + + o If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + o Matching is case-insensitive. + + o A "*" wildcard character MAY be used as the left-most name + component in the certificate. For example, *.example.com would + match a.example.com, foo.example.com, etc. but would not match + example.com. + + o If the certificate contains multiple names (e.g. more than one + dNSName field), then a match with any one of the fields is + considered acceptable. + + If the match fails, the client SHOULD either ask for explicit user + confirmation, or terminate the connection and indicate the server's + identity is suspect. + +3. IMAP4 STARTTLS extension + + When the TLS extension is present in IMAP4, "STARTTLS" is listed as + a capability in response to the CAPABILITY command. This extension + adds a single command, "STARTTLS" to the IMAP4 protocol which is + used to begin a TLS negotiation. + +3.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + NO - security layer already active + + + +Newman [Page 3] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client SHOULD discard cached + information about server capabilities and re-issue the CAPABILITY + command. This is necessary to protect against man-in-the-middle + attacks which alter the capabilities list prior to STARTTLS. The + server MAY advertise different capabilities after STARTTLS. + + The formal syntax for IMAP4 is amended as follows: + + command_any =/ "STARTTLS" + + Example: C: a001 CAPABILITY + S: * CAPABILITY IMAP4rev1 STARTTLS + S: a001 OK CAPABILITY completed + C: a002 STARTTLS + S: a002 OK Begin TLS negotiation now + <TLS negotiation, further commands are under TLS layer> + C: a003 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL + S: a003 OK CAPABILITY completed + C: a004 LOGIN joe password + S: a004 OK LOGIN completed + +4. POP3 STARTTLS extension + + The POP3 STARTTLS extension adds the STLS command to POP3 servers. + If this is implemented, the POP3 extension mechanism [POP3EXT] MUST + also be implemented to avoid the need for client probing of multiple + commands. The capability name "STLS" indicates this command is + present. + + STLS + + Arguments: none + + + +Newman [Page 4] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + Restrictions: + Only permitted in AUTHORIZATION state. + + Discussion: + A TLS negotiation begins immediately after the CRLF at the + end of the +OK response from the server. A -ERR response + MAY result if a security layer is already active. Once a + client issues a STLS command, it MUST NOT issue further + commands until a server response is seen and the TLS + negotiation is complete. + + The STLS command is only permitted in AUTHORIZATION state + and the server remains in AUTHORIZATION state, even if + client credentials are supplied during the TLS negotiation. + The AUTH command [POP-AUTH] with the EXTERNAL mechanism + [SASL] MAY be used to authenticate once TLS client + credentials are successfully exchanged, but servers + supporting the STLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client SHOULD discard cached + information about server capabilities and re-issue the CAPA + command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list + prior to STLS. The server MAY advertise different + capabilities after STLS. + + Possible Responses: + +OK -ERR + + Examples: + C: STLS + S: +OK Begin TLS negotiation + <TLS negotiation, further commands are under TLS layer> + ... + C: STLS + S: -ERR Security Layer already active + +5. ACAP STARTTLS extension + + When the TLS extension is present in ACAP, "STARTTLS" is listed as + a capability in the ACAP greeting. No arguments to this capability + are defined at this time. This extension adds a single command, + "STARTTLS" to the ACAP protocol which is used to begin a TLS + negotiation. + + + + + + +Newman [Page 5] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + +5.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + NO - security layer already active + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + After the TLS layer is established, the server MUST re-issue an + untagged ACAP greeting. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The client SHOULD discard cached capability + information and replace it with the information from the new ACAP + greeting. The server MAY advertise different capabilities after + STARTTLS. + + The formal syntax for ACAP is amended as follows: + + command_any =/ "STARTTLS" + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + <TLS negotiation, further commands are under TLS layer> + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + +6. PLAIN SASL mechanism + + Clear-text 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 an unencrypted network connection. + + + +Newman [Page 6] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + This defines the "PLAIN" SASL mechanism for use with ACAP and other + protocols with no clear-text login command. This MUST NOT be + implemented unless strong TLS encryption or an equivalent strong + encryption layer is also implemented. + + The mechanism consists of a single message from the client to the + server. The client sends the authorization identity (identity to + login as), followed by a US-ASCII NUL character, followed by the + authentication identity (identity whose password will be used), + followed by a US-ASCII NUL character, followed by the clear-text + password. The client may leave the authorization identity empty to + indicate that it is the same as the authentication identity. + + The server will verify the authentication identity and password + with the system authentication database and verify that the + authentication credentials permit the client to login as the + authorization identity. If both steps succeed, the user is logged + in. + + The server MAY also use the password to initialize any new + authentication database, such as one suitable for CRAM-MD5 + [CRAM-MD5]. + + Non-US-ASCII characters are permitted as long as they are + represented in UTF-8 [UTF-8]. Use of non-visible characters or + characters which a user may be unable to enter on some keyboards is + discouraged. + + Clients are encouraged to support pure-binary passwords as they may + be safe from dictionary attacks. However, if the client offers a + character-based interface for password entry it MUST use UTF-8 + encoding for the characters. + + The formal grammar for the client message using Augmented BNF + [ABNF] follows. + + message = [authorize-id] NUL authenticate-id NUL password + authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + password = *NZ-OCTET ; MUST accept up to 255 octets + NUL = %x00 + NZ-OCTET = %x01-FF ; all non-NUL octet values + UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / + UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 + UTF8-1 = %x80-BF + UTF8-2 = %xC0-DF UTF8-1 + UTF8-3 = %xE0-EF 2UTF8-1 + UTF8-4 = %xF0-F7 3UTF8-1 + + + +Newman [Page 7] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + UTF8-5 = %xF8-FB 4UTF8-1 + UTF8-6 = %xFC-FD 5UTF8-1 + + Here is an example of how this might be used to initialize a + CRAM-MD5 authentication database for ACAP: + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a001 AUTHENTICATE "CRAM-MD5" + S: + "<1896.697170952@postoffice.reston.mci.net>" + C: "tim b913a602c7eda7a495b4e6e7334d3890" + S: a001 NO (TRANSITION-NEEDED) + "Please change your password, or use TLS to login" + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + <TLS negotiation, further commands are under TLS layer> + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + C: a003 AUTHENTICATE "PLAIN" {21+} + C: <NUL>tim<NUL>tanstaaftanstaaf + S: a003 OK CRAM-MD5 password initialized + + Note: In this example, <NUL> represents a single ASCII NUL octet. + + Here is an example session where a client erroneously attempts to + use PLAIN prior to starting TLS: + + Example: S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS) + C: a001 AUTHENTICATE "PLAIN" {21} + S: a001 NO (ENCRYPT-NEEDED) + "Can't use PLAIN without encryption" + +7. imaps and pop3s ports + + The common practice of using a separate port for a "secure" version + of each protocol has a number of disadvantages in the IMAP [IMAP4], + ACAP [ACAP] and POP [POP3] environment. Rather than using the best + security available, it means that clients have to be explicitly + configured to use the separate secure port or suffer the + performance loss of probing for active ports. Furthermore this is + even more serious as it would require a new URL scheme which could + only be resolved by TLS-enabled clients. + + Separate "imaps" and "pop3s" ports were registered for use with + TLS. Use of these ports is discouraged in favor of the STARTTLS or + STLS command. + + One of the arguments used in favor of the separate port technique + is that it simplifies configuration of firewalls which filter by IP + port. However, a quality server implementation running on the + + + +Newman [Page 8] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + standard port can be configured to require use of the STARTTLS + command or a suitably strong SASL mechanism for non-local + connections. This provides superior functionality as the client + need not be re-configured for use outside the firewall and faster + non-clear-text SASL mechanisms may be acceptable to many sites for + non-local connections. + +8. IANA Considerations + + This document constitutes registration of the "STARTTLS" IMAP4 + capability as required by section 7.2.1 of RFC 2060. + + This document defines the "STLS" POP3 capability as follows: + + CAPA tag: STLS + Arguments: none + Added commands: STLS + Standard commands affected: May enable USER/PASS as a side-effect. + CAPA command should be re-issued after successful completion. + Announced states/Valid states: AUTHORIZATION state only. + Specification reference: this memo + + This document defines the "STARTTLS" ACAP capability as follows: + + Capability name: STARTTLS + Capability keyword: STARTTLS + Capability arguments: none + Published Specification(s): this memo + Person and email address for further information: + see author's address section below + + This document defines the "PLAIN" SASL mechanism as follows: + + SASL mechanism name: PLAIN + Security Considerations: See section 9 of this memo + Published specification: this memo + Person & email address to contact for further information: + see author's address section below + Intended usage: COMMON + Author/Change controller: see author's address section below + +9. Security Considerations + + TLS only provides protection for data sent over a network + connection. Messages transferred over IMAP or POP3 are still + available to server administrators and usually subject to + eavesdropping, tampering and forgery when transmitted through SMTP + or NNTP. TLS is no substitute for an end-to-end message security + + + +Newman [Page 9] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + mechanism using MIME security multiparts [MIME-SEC]. + + An active attacker can remove STARTTLS from the capability list. + In order to detect such an attack, clients SHOULD either warn the + user when session privacy is not active, or be configurable to + refuse to proceed without an acceptable level of security. + + Both client and server MUST verify the level of protection + negotiated by TLS is adequate for local security policy, and + terminate the TCP connection if it is not. An active attacker can + always cause a down-negotiation to the weakest authentication + mechanism or cipher suite available. For this reason, + implementations need to be configurable to refuse weak mechanisms + or cipher suites. + + Any protocol interactions prior to the TLS handshake are performed + in the clear and can be modified by an active attacker. For this + reason, clients SHOULD discard cached information about server + capabilities advertised prior to the start of the TLS handshake. + + Clients are encouraged to clearly distinguish between a level of + encryption known to be vulnerable to a reasonable attack using + modern hardware (such as encryption with a 40-bit key) and one + which is believed to be safe from such an attack. + + When the PLAIN mechanism (or the IMAP4 LOGIN or POP3 PASS command) + 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 network privacy mechanisms. Stronger SASL + authentication mechanisms such as Kerberos address this issue. + + Use of clear-text login mechanisms (e.g., the IMAP4 LOGIN command, + POP3 PASS command or the PLAIN mechanism) without a suitable + encryption layer such as that provided by TLS expose the user's + password to a common network eavesdropping attack. Therefore, the + PLAIN mechanism MUST NOT be implemented unless a suitable + encryption layer, such as that provided by TLS is also implemented. + + Additional security requirements are discussed in section 2. + +10. References + + [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: + ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, + November 1997. + + [ACAP] Newman, Myers, "ACAP -- Application Configuration Access + Protocol", RFC 2244, Innosoft, Netscape, November 1997. + + + +Newman [Page 10] + +Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 + + + [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension + for Simple Challenge/Response", RFC 2195, MCI, September 1997. + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, University of Washington, December 1996. + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, + Carnegie-Mellon University, December 1994. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, Harvard University, March 1997. + + [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for + MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted + Information Systems, CyberCash, Innosoft International, October + 1995. + + [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC + 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. + + [POP3EXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism", + Work in progress. + + [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + Carnegie Mellon, December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, Netscape Communications, October 1997. + + [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in + progress. + + [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", + RFC 2279, Alis Technologies, January 1998. + +11. Author's Address + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 USA + + Email: chris.newman@innosoft.com + + + + + + + + +Newman [Page 11] diff --git a/RFC/lan-mail-protocols b/RFC/lan-mail-protocols new file mode 100644 index 00000000..13e984ee --- /dev/null +++ b/RFC/lan-mail-protocols @@ -0,0 +1,1330 @@ + + SERVING DESKTOP COMPUTERS USING A CENTRAL MAIL SERVER ON AN INTERNET + + + _________________________________________________________________ + + Author + John Wobus, jmwobus@syr.edu (corrections welcome) + + Date + 2/4/1997 + + This file + http://web.syr.edu/~jmwobus/comfaqs/lan-mail-protocols.html + + Other LAN Info + http://web.syr.edu/~jmwobus/lans/ + + + _________________________________________________________________ + +Contents + + * Introduction + * List of Protocols and RFCs + * Other Sources of Information + * Capabilities of Well-known mail clients + * List of Implementations + * Some other packages for desktop systems + * Key and Other Issues + + + _________________________________________________________________ + +Introduction + + + + There are advantages to having a central server receive the mail + destined to desktop computers and having the desktop computer collect + the mail from the server on demand: + * Your desktop computer may be down quite a bit and less network + bandwidth and less of the processing resources of the sending + computer are used if the computer receiving your mail is ready to + receive. + * Some people use more than one desktop computer to read mail. + * A desktop computer may not have the resources to store all the + mail you receive. + * It can make your e-mail address more like other users'. + + + + The easiest way to "implement" this is to run the central mail server + like any multi-user system: let people sign on to it and use some mail + utility. Then desktop computer users can use "terminal sessions" to + sign on to the central mail server and read their mail (e.g. with Unix + "pine"). This has the disadvantage of making the desktop computer + users learn and use the central mail server's procedures. + + SMTP, the "internet" mail protocol used to deliver mail between + multi-user systems only supports mail transfer initiated by the sender + to actually, it has a method to initiate reception, but the method + didn't catch on and is not used). Other protocols have been devised to + allow a desktop computer to request transfer of mail, thus able to + make use of a central server. These include the published variants of + POP, IMAP, and DMSP. + + POP, POP2, POP3 + + + + These are rather minimal and are designed to be so. The three are + similar but not enough alike to be interoperable. They are basically + designed to identify the user by username and password, to transfer + the mail from server to desktop computer and to delete the mail + transferred. It is assumed that SMTP will be used to send mail. + Messages can be retrieved individually, but the only information you + can get about a message without transferring it is its length in + bytes-- useful for desktop computers with limited storage. + + POP3 has a number of optional extensions including Xtnd Xmit which + allows clients to send mail through the POP3 session rather than using + SMTP. Another extension is APOP which allows RSA MD5 encryption of + passwords passed over the network. + + POP3 is now by far the most-used variant of POP, but POP2 may still be + used at a few sites. POP3 has a couple of optional extensions: one to + avoid sending passwords, and one to aid in reading bulletin boards. + + IMAP2, IMAP2BIS, IMAP3, IMAP4, IMAP4REV1 + + + + The IMAP family is similar to the POP family, but also gives clients a + way to do string searches through mail that still resides on the + server. This is designed to allow the desktop computer to be more + selective as to which mail will be transferred. The POP protocols, on + the other hand, are designed for simpler server software. + + IMAP2 is used quite a bit. IMAP3 is an incompatible offshoot that has + not been implemented much. IMAP4 is a relatively recent extension of + IMAP2 which makes the servers cognizant of the MIME-structure of a + message. IMAP2bis was the original name of IMAP4, which has since been + refined, but there are/were some implementations of IMAP2bis that are + not IMAP4 compliant. IMAP4 also extends IMAP to have many other + features including some of DMSP's. IMAP4rev1 includes a few + enhancements to IMAP4. + + ACAP + + + + ACAP (Application Configuration Access Protocol), formerly IMSP + (Interactive Mail Support Protocol), is a protocol which is being + developed to compliment IMAP4 by offering related e-mail services + beyond the scope of IMAP4. It includes the ability to subscribe find & + subscribe to bulletin boards, mailboxes, and to find and search + address books. + + IMAP VS POP + + + + As of this writing (10/96), there are a many more POP than IMAP client + implementations and an Internet Service Provider is much more likely + to provide POP3 service than IMAP4. But interest in IMAP4 is growing + with big-time software houses announcing support. IMAP4 has more + features, basically designed to support a model where users store + their received mail on a server rather than on their own computer. The + big advantage cited for IMAP is that people who "do e-mail" from + different computers at different times have the same access to their + message store from any of the client-computers they use. The cost of + this model (aside from issues such as the complexity and the + availability of implementations) is in running a server with + sufficient space for the clients' message stores. With personal + computer disks now often above a gigabyte (presumeably growing to 10s + of gigabytes over the next few years) and multimedia messaging in our + future, people storing e-mail on their own hard disk will have a lot + of space and ways to use it. A central store serving 10-20 users will + not be overly difficult, but one for 1,000 or 10,000 users will be + very large (terabytes?) if it is to offer comparable space. The + question comes down to the tradeoff between the advantage to users who + computer-hop against the costs of managing the large amount of central + store. See also online document imap.vs.pop.html (reference below) and + section below "Issue of Remote Access". + + DMSP + + + + Also know as PCMAIL. Desktop computers can use this protocol to both + send and receive mail. The system is designed around the idea that + each user can own more than one workstation; however, the system + doesn't seem to handle the idea of a "public workstation" very well. + The desktop computers are assumed to hold state information about the + mail, a directory so to speak, and when the desktop computer is + connected to the server, this directory is updated to "reality". Note: + DMSP never gained the following of IMAP or POP and I've heard the + software is no longer available. + + WHO USES THESE PROTOCOLS? + + + + These protocols were designed and implemented mostly by + Internet-connected universities with some participation by other + Internet-connected research institutions. They were certainly devised + to handle the type of electronic mail that universities must do. A + typical site has probably 10 to 10,000 desktop computers and has an + Internet connection and also runs Unix, giving them the Unix sysadmin + expertise that makes running a Unix-based server attractive. Most of + the servers listed here run under Unix though some run under other + large systems and as time goes on, we are seeing more servers that run + on PCs and Macintoshes. + + A more recent use of these protocols has been by Internet Service + Providers and their customers. Internet Service Providers require a + way to offer e-mail services to however many customers they provide, + to customers who are connected to the network only part of the time. + Like a campus application, they may have 10 or 10,000 customers to + serve. These protocols offer a distinct advantage over SMTP for such + purposes and form an attractive complementary e-mail service for WWW + users. + + DISADVANTAGES + + + + There are a number of disadvantages associated with the use of these + protocols: + * since these have long been no more than a small part of the e-mail + market, software using these methods is often incompatible with + other useful and/or well-known software. A couple of examples are: + + Use of mail-enabled applications on desktop computers (there + is no fundamental reason that mail software using these + protocols can't provide the API used by mail-enabled + applications, but in general this hasn't come about yet) + + Use of the usual Unix mail readers & the Unix .forward files. + * since the server is holding mail for the person, the person can + use the server for storage. This leaves the potential for all the + disk-space problems inherent in shared disks: people hogging + disk-space or forgetting to clean up, etc. + * sizing the server: a perennial question people ask is "How big a + machine do I need to serve my campus (or department, or + whatever)". Naturally no one can give a straight answer because it + depends upon so many factors. + + ISSUE OF REMOTE ACCESS + + + + Modern commercial e-mail packages typically have features designed to + assist in remote access of ones e-mail. Features include: + * ability to download mail through a modem + * ability to synchronize two different systems which you are using + to read your e-mail by plugging them together. + + + + Any method of reading e-mail using PCs or Macintoshes can be used + remotely via remote control (the "PCanywhere(tm)" method, e.g. by + dialing up your own office PC/Macintosh and using one of the several + kinds of software that allow you to control your PC/Macintosh over the + phone). Also, any LAN-based method can be used by using one of the + several methods of providing the same protocol support over dialup + lines as are on LANs (SLIP or PPP for the above-mentioned, + TCP/IP-based protocols, ARA for Appletalk-based protocols, etc, and + sometimes using two different protocols, one incapsulated in the + other) under the constraint that any operations that use the network + will be much slower. Also, POP3 is sometime used directly over modems + (for example, Eudora can be used in this manner). + + The ideal protocol for remote access would not penalize the user for + the much slower communications speed (usually slower by a factor of + 100: note that a lot of LAN-based software was written without regard + to minimizing the necessary communication, thus is really hurt by such + slow speeds), yet would allow the same software to run both remotely + and locally, with a wonderful user interface. It would also not be + overly expensive in communications equipment or services. This is a + difficult set of objectives and the above-three protocols can achieve + some of them for some users, but what they actually achieve depends a + lot on the user's pattern of e-mail usage. If a user reads just a + small amount of mail, then we would not worry about the length of time + necessary to download it remotely with POP3, but if the person + receives a lot of mail, but just wants to read a small amount of it at + home, then with IMAP2, they could pick and choose what to read, + eliminating some download time. If someone is paying for the telephone + line time (possibly the user if it is a long distance call; in any + case, the institution pays a monthly fee for each line it offers, + which is dependent upon how many users it is serving, how often they + call, and how long their calls are) then IMAP2's natural method of + usage which requires the phone call to remain while a user is reading, + poking around, sending, and rearranging mail can be much more costly + than using POP3 if one call is used to quickly download all the mail + and another later call is used to send any replies. Thus with POP3 a + user might have two 1 minute calls before and after a 30 minute e-mail + session instead of keeping the call for 30 minutes with IMAP2, and + each phone line the institution offers could be serving 15 times as + many such users who would each pay a lot less in long-distance phone + bills. Note that with the advent of multimedia mail (see MIME below) + whose messages can be very large, it is possible that downloading even + one message that you end up not reading remotely could ruin such a + nice-sounding scenario. + + Note that with the growth of Internet Service Providers, remote access + is becoming the normal way for many people to do their e-mail, and + offering such services is one of the major growth areas for POP and + IMAP. + + MIME + + + + MIME (Multipurpose Internet Mail Extensions) is a relatively new + Internet standard for the format for messages with multiple parts, and + with non-ASCII data. Any client that can import or export files can + use MIME in a clumsy way if you have a program to create and/or decode + a MIME message. Some clients have built-in features to do this. + Client-server mail protocols generally only deal with entire messages, + and can retrieve MIME messages as well as any other messages since + MIME was carefully designed to be transparent to existing mail + systems. However, IMAP4 has features to allow retrieval of individual + parts of MIME-encoded messages. The chart below lists whether a + package has MIME support. Servers for protocols that don't offer any + special MIME features are marked na for Not Applicable since they need + do nothing for users to use MIME. All IMAP4 servers can also do this, + but the chart lists whether they include explicit MIME support. + + APPROACHES NOT COVERED BY THIS MEMO + * Proprietary protocols + * file sharing + * APIs + * X.400. + + + + Vendors can invent their own protocols similar to those listed above, + and some have. + + LAN e-mail can also be implemented using file sharing, e.g. using NFS + to allow separate Unix workstations to share the same mail spool area + just as if it were mail being stored on one system, or using Novell's + SMF (Simple Message Format) in a Novell file server. If the + applications are written so that they are careful to lock files + correctly, then this works. An advantage is that any network file + protocol can be used and the e-mail application can be somewhat + independent of the file protocol. For example, Unix systems could use + either AFS or NFS. Pegasus is a PC & Mac application that uses Novell + file service to do something similar. Specifications for client-server + interaction consist of the file service protocol along with the server + directory structures & conventions used for storing e-mail. + + A very popular approach with commercial vendors is the use of APIs. + The client talks to the server using an API (Applications Programming + Interface), i.e., a set of subroutine/procedure library call + definitions for a library providing subroutines/procedures to send, + receive, and manipulate e-mail. With the use of any remote procedure + call mechanism, the client can be located on a different computer from + the server. This allows some mixing and matching of RPC mechanisms, + underlying protocol stacks and APIs: e.g., a vendor defines an API, + and it can be run over IPX or TCP/IP, in each case over the protocol + stack's RPC mechanism. There are a number of APIs now being pushed by + vendors: MAPI (Microsoft); VIM (Lotus); AOCE (Apple). These API's have + been the basis for numerous mail-enabled applications: e.g. a word + processor that allows you to send or receive documents through e-mail + simply uses one of these APIs allowing it to communicate with any + server supporting the same API. Specifications for client-server + interaction consist of the protocol stack up to the RPC protocol, then + the API itself. + + Note that though the API approach in combination with remote procedure + calls allows one to implement client-server e-mail without the use of + the protocols covered by this document (IMAP, POP, etc), that there is + no theoretical reason why such APIs can't be used in an IMAP or POP + environment. The necessary software would be a "driver" or piece of + "middleware" that provides the APIs calls to mail-enabled applications + and uses POP, IMAP, or whatever over a LAN to reach a server. The + advantages/disadvantages of such an approach as compared to the use of + RPCs is open to debate. UniPalm's Mail-IT is an example of client + software that provides MAPI within the client and uses POP3 to access + the server. + + X.400 is the message transport defined for use between + telecommunications vendors and customers by the international + consortium of national standards bodies known as ISO. It roughly + corresponds to TCP/IP's SMTP and RFC822 header format. A consortium of + X.400 vendors (XAPIA) have developed an API for X.400 applications + called CMC. + + LDAP + + + + LDAP is a protocol (the Lightweight Directory Access Protocol) being + incorporated in some clients as an Internet way for the client to get + information about e-mail addresses from a server, i.e. to give you the + capability to type in someone's name and have the mail client software + retrieve the address from a server-based directory. LDAP also has + other uses. There are plans to incorporate LDAP clients into some IMAP + and POP clients. LDAP is essentially an Internet-based, simplified + X.500-like protocol and one of the original intentions of its creators + was to be gatewayed to X.500, thus giving relatively simple Internet + clients access to X.500 servers. Both LDAP and X.500 provide a method + for naming, retrieving, and searching fields in a directory, but do + not define the field-names or what is supposed to go in the fields. + Thus server/client interoperability requires further conventions. + + JAVA + + + + Java is a programming language currently (1996) touted as a tool for + web-based applications. It can affect the use of LAN protocols in a + number of ways: first of all, POP or IMAP clients can be written in + Java, using its cross-platform development capabilities to create + version for a number of platforms. Second, clients could be written as + "Applets", i.e. applications designed to be downloaded into web + browsers such as Netscape from a server. With such a design, a user + would only need access to a web browser to see their e-mail, e.g. drop + into a library and see your e-mail from one of its Internet-browser + kyosks. Applets are not normally allowed to access the + client-machine's disk files (which would result in too much risk when + browsing the Internet from the kind of people who develop computer + viruses), so such an application fits a little better into the IMAP + model (server storage of e-mail folders) than the POP model (client + storage of e-mail folders). Thirdly, Applets enable more practical use + of e-mail clients that use non-standard protocols rather than POP or + IMAP; interoperability is achieved because the server itself + distributes a compatible client applet right when the user accesses + the server. + _________________________________________________________________ + +List of Protocols and RFCs + + + + Note: for up-to-date information on the RFCs, get an index from an RFC + repository. For up-to-date information on the state of each RFC as to + the Internet Standards, see the most recent RFC called "Internet + Official Protocol Standards". + +Name: Simple Mail Transfer Protocol +Nickname: SMTP +Document: RFC 821 (Postel, August 1982) +TCP-port: 25 +Status: Internet standard (STD 10) + +Name: Post Office Protocol, Version 2 +Nickname: POP2 +Document: RFC 937 (Butler et al, February 1985) +TCP-port: 109 +Status: Functionally replaced by incompatible POP3 but still used some + +Name: Post Office Protocol, Version 3 +Nickname: POP3 +Document: RFC 1939 (Myers & Rose, May 1996) +TCP-port: 110 (109 also often used) +Status: In use, standards track +Sites: UC Irvine, MIT + +Name Post Office Protocol, Version 3 Authentication command +Nickname: POP3 AUTH +Document: RFC1734 (Myers, December 1994) + +Name: Post Office Protocol, Version 3 Extended Service Offerings +Nickname: POP3 XTND +Document: RFC 1082 (Rose, November 1988) + +Name: Distributed Mail Service Protocol +Nickname: DMSP, Pcmail +Document: RFC 1056 (Lambert, June 1988) +TCP-port: 158 +Status: Used very little +Sites: MIT + +Name: Interactive Mail Access Protocol, Version 2 +Nickname: IMAP2 +Document: RFC 1176 (Crispin, August 1990) +TCP-port: 143 +Status: In use, being replaced by upward-compatible IMAP4 +Sites: Stanford, U Washington + +Name: Interactive Mail Access Protocol, Version 2bis +Nickname: IMAP2bis +TCP-port: 143 +Status: Experimental, but in use, being replaced by upward-compatible IMAP4 + +Name: Interactive Mail Access Protocol, Version 3 +Nickname: IMAP3 +Document: RFC 1203 (Rice, February 1991) +TCP-port: 220 +Status: Historical, not used +Sites: Stanford + +Name: Internet Message Access Protocol, Version 4 +Nickname: IMAP4 +Document: RFC 1730 (Crispin, December 1994) +TCP-port: 143 +Status: Implementations exist, being replaced by revised version IMAP4rev1 +Sites: U Washington +Related: RFC 1731 (Myers, December 1994), + RFC 1732 (Crispin, December 1994), + RFC 1733 (Crispin, December 1994) + +Name: Internet Message Access Protocol, Version 4rev1 +Nickname: IMAP4rev1 +Document: RFC 2060 (Crispin, December 1996) +TCP-port: 143 +Status: Being implemented, Standards track +Sites: U Washington +Related: RFC 2061 (Crispin, December 1996), + RFC 2062 (Crispin, December 1996) + +Name: Interactive Mail Support Protocol +Nickname: IMSP +Document: Draft RFC: ? (Myers, June 1995) +TCP Port: 406 +Status: Experimental, renamed ACAP +Sites: Carnegie Mellon + +Name: Application Configuratino Access Protocol +Nickname: ACAP +Document: Draft RFC: ? (Myers, June 1996) +Status: ? +Sites: Carnegie Mellon + + + + Note: The "I" in IMAP used to stand for "Interactive". Now it stands + for "Internet" and the "M" stands for "Message" rather than "Mail". + Also, Internet drafts are available at ds.internic.net, munnari.oz.au, + and nic.nordu.net in directory internet-drafts. IMAP2bis is + essentially an early version of IMAP4. + _________________________________________________________________ + +Other Sources of Information + + My own info + http://web.syr.edu/~jmwobus/lans/#imappop + http://web.syr.edu/~jmwobus/internet/ + + The IMAP Connection web site + + http://www.imap.org + Main page + + http://www.imap.org/products.html + List of IMAP implementations + + http://www.imap.org/imap.vs.pop.brief.html + Outlines differences between IMAP and POP. + + http://www.imap.org/imap.vs.pop.html + Same, with more detail. + + http://www.imap.org/biblio.html + Bibliography of IMAP Documents. + + Information from University of Washington + http://www.washington.edu/imap/ + + By anonymous ftp from ftp.cac.washington.edu + mail/* (miscellaneous information) + + Information from andrew2.andrew.cmu.edu + + http://andrew2.andrew.cmu.edu/cyrus/email/clients-IMAP.html + List of IMAP clients + + http://andrew2.andrew.cmu.edu/cyrus/acap/acap.html + The ACAP Home Page + + Mailing lists: + pop@jhunix.hcf.jhu.edu + imap@cac.washington.edu + CW-EMAIL@EARNCC.EARN.NET + + By anonymous ftp from rtfm.mit.edu + This memo + comp.os.msdos.mail-news FAQ Memo + Mini FAQ on client-server mail protocols (similar to this memo + but shorter and more practical: + ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/mailclient-fa + q) + + Consortium + "The IMAP Consortium" (Getting under way as of March 1995). + + Page on MAPI API + http://www.wp.com/davidb/emapi.html + + + _________________________________________________________________ + +Capabilities of Well-known mail clients + + + + This section covers what I've been able to find out so far about the + well-known mail clients' ability to retrieve mail from a POP or IMAP + server. + +Client POP3 IMAP MIME +------ ---- ---- ---- +Apple PowerMail client ? ? ? +BeyondMail yes planned- yes +CE QuickMail client planned= planned= yes +Claris Emailer yes ? yes +DaVinci eMAIL client yes* ? yes* +Lotus cc:Mail Client no no no +Lotus Notes mail client no no ? +Microsoft Mail client no no no +Microsoft Exchange client yes+ no yes& +Netscape yes planned% yes + +Notes: +(-) Announced early 1996: target delivery: 4th quarter 1996. +(=) CE plans to rename the successor to their current client + QuickMail LAN, while introducing both a free and a commercial + POP3 client, then upgrade the commercial POP3 client to also + support IMAP. +(*) DaVinci SMTP eMAIL: I'm not sure if this is different from + the normal DaVinci client. +(+) Requires Internet Mail Client for Exhange, downloadable from + http://www.windows.microsoft.com or included in "Microsoft Plus". +(&) qp/base64 +(%) Planned for Netscape 4.0 + + + + + _________________________________________________________________ + +List of Implementations + + + +Prot Computer Implementation End MIME Source +------ ---------- ------------------- ---- ---- ------------------------------- +DMSP PC pc-epsilon (3.1) clnt ? allspice.lcs.mit.edu +DMSP PC pc-netmail (3.1) clnt ? allspice.lcs.mit.edu +DMSP PC pc-reader clnt ? allspice.lcs.mit.edu +DMSP Unix Pcmail 3.1 reposit. srvr na allspice.lcs.mit.edu +DMSP Unix/EMACS Pcmail 4.2 clnt ? allspice.lcs.mit.edu +DMSP PC PC/TCP 2.3 clnt ? FTP Software 8/4/94 +DMSP OS/2 PC/TCP clnt ? FTP Software +DMSP OS/2 TCP/2 clnt ? Essex Systems +DMSP OS/2 TCP/2 SERVER PACK srvr na Essex Systems +DMSP OS/2 TCP/2 ADV CLIENT clnt ? Essex Systems +IMAP1 MacOS MacMS 2.2.1 (obs) clnt no sumex-aim.stanford.edu* 7/13/95 +IMAP24 MacOS Mailstrom 1.04 clnt no sumex-aim.stanford.edu* 11/7/93 +IMAP24 MacOS Mailstrom 1.05 clnt no ftp-camis.stanford.edu 5/21/96 +IMAP24 MacOS Mailstrom 2(beta) clnt yes Tree Star Inc. 12/18/96 +IMAP? MacOS Mailstrom clnt ? lindy.stanford.edu 9/22/95 +IMAP? MacOS Mulberry (beta) clnt no mulberry@dial.pipex.com 7/30/96 +IMAP? MacOS Mulberry 1.1 clnt ? CyDaSoft 12/19/96 +IMAPb4 Mac/OT SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 MacOS SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 MS-WIN SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 WIN32 SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAPb4 Unix/Motif SIMEON 4.1 clnt yes ESYS Corp www.esys.ca 8/5/96 +IMAP4 ? SIMEON SERVER srvr ? ESYS Corp www.esys.ca 8/1/96 +IMAP2 MacOS PathWay clnt no The Wollongong Group 2/25/94 +IMAP2 Unix/X PathWay clnt no The Wollongong Group 2/25/94 +POP3 MacOS PathWay clnt no The Wollongong Group 2/25/94 +POP3 Unix/X PathWay clnt no The Wollongong Group 2/25/94 +POP3 OS/2 ? (in testing) srvr no kf5mg@computek.net 11/28/95 +POP2 MacOS MacPOP 1.5 clnt ? ? 10/24/94 +POP2 MS-DOS PC POP 2.1 clnt ? ? 10/24/94 +POP3 MacOS TCP/Connect II clnt ? InterCon Systems Corp +POP3 MS-WIN TCP/Connect II f W clnt yes InterCon Systems Corp 7/8/94 +POP3 NeXT EasyMail clnt yes ftp.cac.washington.edu 11/7/93 +IMAP2 NeXT MailManager srvr yes ftp.cac.washington.edu 11/7/93 +IMAP2 TOPS20 MAPSER srvr na ? 11/7/93 +IMAP2 Unix imap kit srvr na ftp.cac.washington.edu 2/1/94 +POP23 Unix imap kit srvr na ftp.cac.washington.edu 2/1/94 +POP23 Unix IPOP srvr na ftp.cac.washington.edu 2/23/96 +IMAP4 Unix imap4 kit (alpha) srvr na ftp.cac.washington.edu 5/31/95 +IMAP24 Unix Pine 3.90 clnt yes ftp.cac.washington.edu 9/23/94 +IMAP24 Unix Pine 3.91 clnt yes ftp.cac.washington.edu 10/14/94 +IMAP2b Unix Pine 3.95 clnt yes ftp.cac.washington.edu 7/30/96 +IMAP24 Unix Pine 4.0 (future) clnt yes ftp.cac.washington.edu 7/30/96 +IMAP24 MS-DOSl+ PC-Pine 3.90 clnt yes ftp.cac.washington.edu 9/23/94 +IMAP24 MS-DOSl+ PC-Pine 3.91 clnt yes ftp.cac.washington.edu 10/14/94 +POP23r Unix popclient x.x (rep) clnt no Renamed 'fetchmail' 10/7/96 +IMAPb4 Unix popclient x.x (rep) clnt no Renamed 'fetchmail' 10/7/96 +POP23r Unix fetchmail 2.0 clnt no www.ccil.org/~esr 11/19/96 +IMAPb4 Unix fetchmail 2.0 clnt no www.ccil.org/~esr 11/19/96 +POP23r Unix fetchmail 2.2 clnt no www.ccil.org/~esr 12/10/96 +IMAPb4 Unix fetchmail 2.2 clnt no www.ccil.org/~esr 12/10/96 +POP23r Unix fetchmail 2.3 clnt no www.ccil.org/~esr 12/18/96 +POP3k Unix fetchmail 2.3 clnt no www.ccil.org/~esr 12/18/96 +IMAPb4 Unix fetchmail 2.3 clnt no www.ccil.org/~esr 12/18/96 +POP23r Unix fetchmail 2.6 clnt no www.ccil.org/~esr 12/18/96 +POP3k Unix fetchmail 2.6 clnt no www.ccil.org/~esr 12/18/96 +IMAPb4 Unix fetchmail 2.6 clnt no www.ccil.org/~esr 12/18/96 +POP23r Unix fetchmail 3.3 clnt no www.ccil.org/~esr 2/4/97 +POP3k Unix fetchmail 3.3 clnt no www.ccil.org/~esr 2/4/97 +IMAPb4 Unix fetchmail 3.3 clnt no www.ccil.org/~esr 2/4/97 +POP? Unix gwpop clnt ? ftp.pasteur.fr 2/9/96 +POP? Unix popc clnt ? ftp.imag.fr 2/9/96 +POP? Unix popmail clnt ? ftp.cic.net 2/9/96 +POP? Unix movemail clnt ? GNU 2/9/96 +IMAP2 VMS Pine 3.88 port clnt yes vms.huji.ac.il 4/12/94 +IMAP? VMS Pine in PMDF 4.3 clnt ? Innosoft 4/1/94 +IMAP2 VMS ImapD port srvr yes vms.huji.ac.il 4/12/94 +POP3u Win3/95/NT Navigator 2.x clnt yes Netscape 7/29/96 +IMAP? Windows? pcMail (future) clnt ? OzMail 3/19/96 +POP? Solaris Navigator 3.0b4(fut)clnt ? Netscape 6/25/96 +IMAP4 ? Navigator 4.0 (fut) clnt yes Netscape 7/30/96 +IMAP4 MacOS Navigator 4.0 (fut) clnt yes Netscape 12/18/96 +POP3 Macintosh6 Eudora 1.3.1 clnt no ftp.qualcomm.com 7/14/94 +POP3 Mac7/PM7 Eudora 1.5.3 clnt yes ftp.qualcomm.com 8/4/95 +POP3mr Macintosh7 Eudora 2.0.2 clnt yes Qualcomm 5/10/94 +POP3mr Mac7/PM7 Eudora 2.0.3 clnt yes Qualcomm 9/13/94 +POP3mrkMac7/PM7 Eudora 2.1 clnt yes Qualcomm 9/13/94 +POP3mrkMac7/PM7 Eudora 2.1.1 clnt yes Qualcomm 8/4/95 +POP3mrkMac7/PM7 Eudora 2.1.2 clnt yes Qualcomm 8/4/95 +POP3mrkMac7/PM7 Eudora 2.1.3 clnt yes Qualcomm 8/4/95 +POP3 MS-WINw Eudora 1.4.4 clnt yes ftp.qualcomm.com 6/23/95 +POP3 MS-WINw Eudora 1.5.2b1 clnt yes ftp.qualcomm.com 8/4/95 +POP3 MS-WINw Eudora 2.0.3 clnt yes Qualcomm 9/13/94 +POP3 MS-WINw Eudora 2.1.1 clnt yes Qualcomm 8/4/95 +POP3 WIN32 Eudora Pro 2.2b8 clnt yes Qualcomm 12/5/95 +POP3 WIN3/95/NT Eudora Pro ? clnt yes Qualcomm 7/29/96 +POP3 Mac Eudora Pro 3.0 clnt yes Qualcomm 8/14/96 +POP3 OS/2 PMMail 11 clnt yes hobbes.nmsu.edu 6/2/95 +POP3 OS/2 POP3D 12 srvr yes hobbes.nmsu.edu 6/2/95 +POP3 OS/2 POP3D 14A srvr yes hobbes.nmsu.edu 9/12/95 +POP3 OS/2 POP3D 14B srvr yes hobbes.nmsu.edu 4/5/96 +POP? OS/2 popsrv99.zip srvr ? hobbes.nmsu.edu 2/15/96 +POP3r OS/2 popsrv10.zip srvr na ftp-os2.mnsu.edu 3/15/96 +POP3 MS-WIN Mi'Mail clnt yes http://www.irisoft.be 6/30/95 + +IMAP2b Unix/XM ML 1.3.1 clnt yes ftp-camis.stanford.edu 7/13/95 +IMAP24 Unix/XM ML 2.0 (future) clnt yes Stanford 7/13/95 +IMAP1 Unix imapd 3.2 (obs) srvr na ftp-camis.stanford.edu 7/13/95 +IMAP2b Unix imapd 3.4/UW srvr ? ftp.cac.washington.edu 12/13/94 +IMAP2b Unix imapd 3.5/UW srvr ? ftp.cac.washington.edu 4/25/95 +IMAP2b Unix imapd 3.6.BETA srvr ? ftp.cac.washington.edu 4/25/95 +IMAP2b Unix imapd 4.0/UW (fut) srvr ? U Wash 4/25/95 +IMAP? Unix imapd 8.0(124) srvr ? U Wash 1/31/97 +IMAP? Unix imapd 9.0(161) srvr ? U Wash 1/31/97 +IMAP4 ? imap-4 srvr yes ftp.cac.washington.edu 10/25/96 +POP3u ? imap-4 srvr na ftp.cac.washington.edu 10/25/96 +IMAP4 ? imap-4.1 ALPHA srvr yes ftp.cac.washington.edu 10/25/96 +POP3u ? imap-4.1 ALPHA srvr na ftp.cac.washington.edu 10/25/96 +IMAP? Unix/X Palm (in dev) clnt ? UMiami 11/7/93 +IMAP? Unix/X Cyrus (dev on hold) clnt yes CMU 10/4/94 +IMAP Unix Cyrus 1.4 srvr yes ftp.andrew.cmu.edu 12/1/95 +POP3 Unix Cyrus 1.4 srvr na ftp.andrew.cmu.edu 12/1/95 +KPOP Unix Cyrus 1.4 srvr na ftp.andrew.cmu.edu 12/1/95 +POP3u Unix Cyrus ? srvr na 3/12/96 +IMAP41 Unix Cyrus 1.5 srvr yes ftp.andrew.cmu.edu 1/3/97 +POP3k Unix Cyrus 1.5 srvr na ftp.andrew.cmu.edu 1/3/97 +KPOP Unix Cyrus 1.5 srvr na ftp.andrew.cmu.edu 1/3/97 +IMAP4 ? Futr Andrew Msg Sys ? ? Carnegie-Mellon 9/20/94 +IMAP? Xrx Lsp Mc Yes-Way clnt yes Stanford U 11/7/93 +IMAP2b MacOS ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2b MS-WINw ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2 Unix/XM ECSMail Motif clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2b Solaris ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP2 MS-DOS ECSMail DOS clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP? NT ECSMail clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP? OS/2 ECSMail OS/2 clnt yes ESYS Corp www.esys.ca 12/16/96 +IMAP? Unix UMAIL clnt no umail@umail.umd.edu 11/7/93 +IMAP? Unix MS clnt no ftp.cac.washington.edu 11/7/93 +IMAP2 MS-WIN PathWay clnt no The Wollongong Group 2/25/94 +POP3 MS-WIN PathWay clnt no The Wollongong Group 2/25/94 +POP? MS-WIN PathWay Access 3.0 clnt ? The Wollongong Group 8/4/94 +POP3 NT sendmail/POP3 (bet) srvr na www.metainfo.com 9/15/95 +POP3 NT sendmail/POP3 srvr na emwac.ed.ac.uk 12/5/95 (www.emw +ac.ed.ac.uk) +IMAP4 NT sendmail/POP3 (fut) srvr ? emwac.ed.ac.uk 5/21/96 (www.emw +ac.ed.ac.uk) +IMAP2 Amiga Pine 3.8x (in dev) clnt yes UWashington 11/7/93 +POP MacOS POPmail 1.7 clnt ? boombox.micro.umn.edu 9/1/95 +POP23 MacOS POPmail 2.09b clnt ? boombox.micro.umn.edu 9/1/95 +IMAP2 MacOS POPmail 2.09b clnt ? boombox.micro.umn.edu 9/1/95 +POP23 MacOS POPmail 2.2 clnt ? boombox.micro.umn.edu 9/1/95 +IMAP2 MacOS POPmail 2.2 clnt ? boombox.micro.umn.edu 9/1/95 +POP3 MacOS POPmail/Lab clnt ? boombox.micro.umn.edu 9/1/95 +POP NeXT OS BlitzMail srvr na ftp.dartmouth.edu 10/23/95 +POP DEC OSF/1 BlitzMail srvr na ftp.dartmouth.edu 10/23/95 +POP AIX BlitzMail (in dev) srvr na ftp.dartmouth.edu 10/23/95 +POP3 MS-WINw5 POPmail/Lab clnt ? boombox.micro.umn.edu 9/1/95 +POP3 MacOS Emailer 1.1 clnt yes Claris 7/29/96 +POP3 MacOS OfficeMail srvr na Claris 6/6/96 +IMAP2b Unix imapperl-0.6 clnt ? dnpap.et.tudelft.nl 2/6/96 +POP2 MacOS MailStop 1.1.3 srvr na boombox.micro.umn.edu 1/18/94 +POP3r MacOS MailShare 1.0(beta) srvr na glenn.anderson@stonebow.otago.a +c.nz 8/16/94 +POP3r MacOS MailShare 1.0fc6 srvr na ftp.qualcomm.com 8/4/95 +POP3r MacOS AIMS 1.0 srvr na Apple 10/27/95 +POP3r MacOS AIMS 1.1 srvr na Apple 5/21/96 (www.cybertech.ap +ple.com) +POP3r MacOS AIMS 1.1.1 srvr na Apple 10/17/96 +POP3r MacOS AIMS 2.0 (fut: '97) srvr ? Apple 10/17/96 +POP3r MacOS AIMS 2.1 (fut) srvr ? Apple 10/17/96 +IMAP MacOS AIMS 2.1 (fut) srvr ? Apple 10/17/96 +POP3 MacOS POPGate 1.1 gway ? Stalker 3/25/96 (www.stalker.co +m) +IMAP? MacOS MailDrop 1.1 clnt ? ackmo.baylor.edu 3/22/96 +IMAP2? MacOS MailDrop 1.2d6a clnt ? ackmo.baylor.edu 3/22/96 +IMAP? MacOS MailDrop 2 (dev) clnt ? Baylor 1/19/96 +POP2 MS-DOS LifeLine Mail 2.0 clnt ? SunSelect 12/7/93 +POP23 MS-DOS SelectMail 2.1 clnt ? SunSelect 1/25/94 +POP2 MS-DOSk ? srvr na ucsd.edu +POP2 MS-DOSk net091b srvr na boombox.micro.umn.edu 12/3/93 +POP3 MS-DOSk pop3nos v1.86 srvr na boombox.micro.umn.edu 12/3/93 +POP2 MS-DOSp POPMail 3.2.2 clnt ? boombox.micro.umn.edu 9/1/95 +IMAP? MS-DOSp POPMail/PC 3.2.2 clnt ? boombox.micro.umn.edu 1/11/94 +POP2 MS-DOSp POPMail 3.2.3 beta2 clnt ? boombox.micro.umn.edu 9/1/95 +IMAP? MS-DOSp POPMail 3.2.3 beta2 clnt ? boombox.micro.umn.edu 9/1/95 +POP3 MS-DOSk pop3serv srvr na biochemistry.crwu.edu +POP3 MS-DOSk nos11c-a.exe srvr na biochemistry.bioc.cwru.edu 9/16 +/94 +POP2 MS-DOS MD/DOS-IP clnt ? U Maryland +POP2 MS-DOS PC/TCP clnt ? FTP Software +POP2 OS/2 PC/TCP for OS/2 clnt ? FTP Software 11/2/93 +POP23 MS-WIN BW-Connect clnt no Beame & Whiteside 8/4/94 +POP3 MS-WIN Air Series 2.06 clnt no Spry 7/7/94 +IMAP? MS-WIN Air Mail ? ? AIR Co. Ltd 9/20/94 +IMAP? MS-WIN EMBLA ? ? ICL ProSystems 9/20/94 +IMAP4 ? Intrnt Msging Srvr srvr ? ICL TeamWare 9/8/1 +POP3 ? Intrnt Msging Srvr srvr ? ICL TeamWare 9/8/1 +POP23 MS-DOSp Minuet 1.0b18a(beta)clnt no minuet.micro.umn.edu 9/1/95 +POP? MS-WINls TCPMail clnt ? Pinesoft (pinesoft@net.com) +POP2 Unix U Minn popd 1.5c srvr na boombox.micro.umn.edu 11/19/93 +POP2 Unix/AIX aix_new_popd srvr na boombox.micro.umn.edu 9/1/95 +POP2 Unix/HP9k hp9000_popd srvr na boombox.micro.umn.edu 9/1/95 +POP23 MS-WINw POPmail clnt ? boombox.micro.umn.edu 9/1/95 +IMAP2 MS-WINw POPmail clnt ? boombox.micro.umn.edu 9/1/95 +POP2 Unix USC-ISI popd srvr na ? 10/24/94 +POP2 Unix imapd/ipop2d 3.4 srvr na ftp.cac.washington.edu 12/13/94 +POP3 Unix/curs Z-Mail Lite 3.2 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 Unix/line Z-Mail Lite 3.2 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 Unix/XM Z-Mail Motif 3.2.1 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 WIN3/95/NT Z-Mail 4.0.1 clnt yes NetManage 8/23/96 www.netmanage +.com +POP3 MacOS Z-Mail 3.3.1 clnt yes NetManage 8/23/96 www.netmanage +.com +IMAP4 WIN3/95/NT Z-Mail Pro clnt yes NetManage 8/23/96 www.netmanage +.com +IMAP4 WIN3/95/NT Z-Mail Pro 6.0 clnt yes NetManage 1/31/97 www.netmanage +.com +IMAP? MacOS Z-Mail ? clnt yes NetManage 5/21/96 +POP? Unix zync ? clnt ? NCD 9/23/94 (www.ncd.com) +POP23k UnixX xmh clnt ? ftp.x.org 2/15/94 +POP23k UnixX exmh clnt yes ? 8/8/95 +POP23k UnixX dxmail/mh clnt ? DEC +POP? Unix ucbmail clone clnt ? rtfm.mit.edu 12/16/94 +POP? Unix pop-perl-1.0 clnt ? sunsite.unc.edu 9/13/94 +POP? Unix/XO SXMail 0.9.74a (b) clnt ? ftp.uni-stuttgart.de 10/12/95 +POP2 VM FAL srvr na IBM +POP2 MS-WIN IBM TCP/IP for DOS clnt no IBM 7/7/94 +POP2 VM ? srvr na Texas Tech University +POP? VM ?POPD srvr na vmd.cso.uiuc.edu 2/4/94 +POP3 VM vmpop3.200 srvr na uriacc.uri.edu 1/10/95 +POP3 MUSIC/SP POPD 1.0 srvr na McGill Univ. Sys. Inc. 01/11/95 +POP2 OS/2 TCP/2 SERVER PACK srvr na Essex Systems +POP2 VMS MultiNet srvr na TGV, Inc. 07/26/95 +POP2 HP3000/MPE NetMail/3000 srvr na 3K Associates +POP3 ? NetMail/3000 srvr na 3K Associates +POP3k MacOS Eudora 1.3a8k clnt ? ftp.brown.edu 8/19/94 +POP3 MacOS MacPOP (Berkeley) clnt ? ftp.cc.berkeley.edu +POP3k MacOS TechMail 2.0 clnt ? net-dist.mit.edu +POP3 MacOS MacMH clnt ? jessica.stanford.edu/info +POP3 MacOS VersaTerm Link clnt ? Synergy Software 10/8/93 +POP3 MacOS LeeMail 2.0.2 (shw) clnt ? chs.cusd.claremont.edu 10/12/93 +POP3 Mac7pro Mail*Link Internet clnt yes StarNine Technologies 2/18/94 +POP3t Unix popper-1.7 srvr na ftp.cc.berkeley.edu 10/15/93 +POP3k Unix popper-1.7k srvr na ftp.brown.edu 10/19/94 +POP3k Unix hacked ucbmail clnt no UCSC 6/29/95 +POP3k Unix hacked pine clnt yes UCSC 6/29/95 +POP3 Unix popper-1.831 srvr na ftp.cc.berkeley.edu 11/3/93 +POP3 Solaris2.X popper-1.831/uore srvr na ftp.uoregon.edu 10/19/93 +POP3 Solaris2.X popper-1.9 srvr na ftp.chalmers.se 7/26/94 +POP3 Unix popperQC3 srvr na ftp.qualcomm.com 8/4/95 +POP3 Unix qpopper 2.1.3-r5 srvr na ftp.qualcomm.com 8/4/95 +POP3 Unix qpopper 2.1.4-r1 srvr na ftp.qualcomm.com 8/4/95 +POP3u Unix qpopper 2.1.4-r3 srvr na ftp.qualcomm.com 2/26/96 +POP3u Unix qpopper 2.1.4-r4 srvr na QualComm 5/16/95 +POP3r Unix Vers of qpopper srvr na QualComm 1/26/96 +POP3u Unix qpopper 2.2 beta srvr na Qualcomm 2/26/96 +POP? Unix zpop srvr na NCD 9/1/95 +POP3 Unix popper.rs2 srvr na ftp.qualcomm.com 8/4/95 +POP3 Unix perl popper srvr na ftp.xensei.com/users/ccrlphr 9/ +1/95 +POP23k Unix mh-6.8 (UCI RandMH) both yes ftp.ics.uci.edu 8/30/94 +POP23krUnix mh-6.8.3 (UCI RndMH)both yes ftp.ics.uci.edu 9/27/94 +POP23 Unix/EMACS RMAIL clnt no ? 8/2/95 +POP23 Unix/EMACS vm clnt no ftp.uu.net 8/2/95 +POP3 Linux miniclient clnt ? sunsite.unc.edu 8/30/94 +POP3 Unix imapd/ipop3d 3.4 srvr na ftp.cac.washington.edu 12/13/94 +POP3 Unix pop3d 1.004 srvr na ftp.ucdavis.edu 12/3/93 +POP2 Unix pop2d 1.001 srvr na ftp.ucdavis.edu 12/3/93 +POP3 Unix mush 7.2.5 clnt ? ? 12/16/94 +POP23k Unix popmaild srvr na ftp.wu-wien.ac.at 4/5/95 +IMAP AIX imap server srvr ? ftp.wu-wien.ac.at 4/5/95 +POP3 MacOS/AOCE MailConnect clnt yes ? 7/5/95 +POP3t MS-DOSnpo PC/TCP clnt ? FTP Software +POP3 OS/2 PC/TCP for OS/2 clnt ? FTP Software 11/2/93 +POP3 MS-DOS TechMail(future) clnt ? ? +POP3 MS-WINl TechMail for Wind. clnt ? net-dist.mit.edu 2/25/94 +POP3 OS/2l TechMail for Wind. clnt ? net-dist.mit.edu 2/25/94 +POP3 MS-DOSp NUPop 1.03 clnt no ftp.acns.nwu.edu 11/5/93 +POP3 MS-DOSp NUPop 2.02 clnt no ftp.acns.nwu.edu 1/18/94 +POP3 MS-DOSp NUPop 2.10 (alpha) clnt yes ftp.acns.nwu.edu 6/10/94 +POP23 MS-WINw Trumpet clnt no ftp.psychol.utas.edu.au 7/7/94 +POP3 MS-WIN Pceudora clnt ? ftp.qualcomm.com 9/24/93 +POP3 MS-WINw WinPmail 2.0b4 clnt ? risc.ua.edu 6/6/95 +POP3 MS-DOSp POPgate (Pmail gw) clnt ? risc.ua.edu 4/1/94 +POP3 MS-DOSl PMPOP (Pmail gw) clnt ? risc.ua.edu 4/1/94 +POP3x MS-WIN WinQVT (2.1) clnt ? QPC Software (shareware) 7/12/9 +4 +POP3 MS-WINp wnqvtnet 3.0 clnt ? ftp.cica.indiana.edu +POP3 MS-WINp wnqvtnet 3.9 clnt ? ftp.cica.indiana.edu 2/1/94 +POP3 MS-WIN Open Systems Mail clnt ? Pine Software +POP3 MS-WIN? IMAIL both ? Ipswitch 7/12/94 +POP3 NT Ipswitch srvr ? Ipswitch 5/24/96 +POP3 VMS IUPOP3 v1.7 srvr na ftp.indiana.edu 7/25/94 +POP3 VMS IUPOP3 v1.7-CMU-TEK srvr na ftp.indiana.edu 7/25/94 +POP3 VMS IUPOP3 v1.8-1 srvr na ftp.indiana.edu 7/25/94 +POP3 MS-DOS POP3 0.9 clnt na ftp.indiana.edu 7/25/94 +POP3 VMS MultiNet both ? TGV, Inc. 07/26/95 +POP3 VMS PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +POP3 Solaris PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +POP3 DigUNIX PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +POP3 OpenVMS PMDF 5.1 srvr na Innosoft 9/24/96 www.innosoft.c +om +IMAP? VMS PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? Solaris PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? DigUNIX PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? OpenVMS PMDF 5.1 srvr ? Innosoft 9/24/96 www.innosoft.c +om +IMAP? MS-DOS PMDF E-mail Interc clnt ? Innosoft 3/2/94 www.innosoft.co +m +IMAP? MacOS PMDF E-mail Interc clnt ? Innosoft 3/2/94 www.innosoft.co +m +POP? VMS PMDF E-mail Interc ? ? Innosoft 6/24/96 www.innosoft.c +om +IMAP? VMS PMDF E-mail Interc ? ? Innosoft 6/24/96 www.innosoft.c +om +POP3r VMS PMDF popstore clnt ? Innosoft 9/24/96 www.innosoft.c +om +IMAP4 SolarisX Roam (Future) clnt ? Sun 9/26/95 +IMAP? Windows? Roam (Future) clnt ? Sun 3/19/96 +IMAP4 SolarisX imapd (Future) clnt ? Sun 9/26/95 +IMAP4 Solaris Solstice IMS1.0 srvr yes SunSoft 10/17/96 http://www.sun +.com +POP3 Solaris Solstice IMS1.0 srvr yes SunSoft 10/17/96 http://www.sun +.com + +IMAP4 Solaris Solstice IMS2.0 (f) srvr yes SunSoft 10/17/96 http://www.sun +.com +POP3 Solaris Solstice IMS2.0 (f) srvr yes SunSoft 10/17/96 http://www.sun +.com +IMAP4 Solaris Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 Solaris Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN3.11 Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN3.11 Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN95 Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 MS-WIN95 Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 NT Solstice IMC0.9 clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 NT Solstice IMC? (fut) clnt yes SunSoft 4/5/96 http://www.sun.c +om +IMAP4 Win95 SOlstice 2.0 clnt ? SunSoft 1/31/97 +POP3 OS/2 TCP/2 SERVER PACK srvr na Essex Systems +POP3 OS/2 TCP/2 ADV CLIENT clnt ? Essex Systems +POP? MS-DOS UCDmail clnt ? ftp.ucdavis.edu 10/24/94 +POP? MS-DOS PC POP clnt ? ?Bill Schweickert/Sterling Fed +POP23 MS-WINnpo Super-TCP for W e.0 clnt yes Frontier Technologies 6/10/94 +POP? MS-WINnpo Super-TCP for W e.0 srvr yes Frontier Technologies 7/12/94 +POP3 WIN3/95/NT SuperHghwy Access 2 clnt yes Frontier Technologies 7/29/96 +POP? MS-WINw Windows ELM clnt ? lister.cc.ic.ac.uk 7/12/94 +IMAP? ? ELM patches clnt ? www.math.fu-berlin.de/~guckes/e +lm/patches 7/16/96 +POP23 MS-DOSni ChameleonNFS both ? NetManage 8/4/94 +POP23 MS-DOSni Chameleon beta clnt yes NetManage +POP23 MS-WINw Internet Chameleon clnt yes NetManage 7/12/94 +POP23 NT Chameleon V5.0 f NT both ? NetManage 11/28/95 +IMAP? Windows? Chameleon (future) clnt ? NetManage 3/19/96 +POP? MacOS MEWS clnt ? ? +POP? MacOS byupopmail clnt ? ? +POP? VM ? srvr na TTUVM1 +POP3 MacOS HyperMail ? ? ? +? OS/2 lamailpop ? ? ftp-so2.cdrom.com +POP? OS/2 Popclient clnt yes ? 1/19/96 +POP? OS/2 Emacs 19.xx clnt yes ? 1/19/96 +POP3 MS-DOSs pcelm clnt ? lister.cc.ic.ac.uk 1/25/94 +POP3 MS-WINs winelm clnt ? lister.cc.ic.ac.uk 1/25/94 +POP3 NetWare Mercury 1.11 srvr na risc.ua.edu 2/4/94 +POP3 NetWare34 Mercury 1.2.1 srvr na risc.ua.edu 3/29/96 +POP3 NetWare34 Mercury 1.3 srvr na risc.ua.edu 8/2/96 +POP3 MS-WINw IMail srvr na Ipswitch 7/15/94 +POP3 MS-Windows Pegasus/Win 2.3 clnt ? risc.ua.edu 6/6/96 +POP3 MS-Windows Pegasus/Win 2.2(r3) clnt ? risc.ua.edu 6/6/96 +POP3 MS-Windows Pegasus/Win 2.0(r1) clnt ? risc.ua.edu 6/6/96 +POP3 MS-DOS Pegasus/DOS 3.2(r2) clnt ? risc.ua.edu 6/6/96 +POP3 MacOS Pegasus/MAC 2.1.2 clnt ? risc.ua.edu 6/6/96 +POP23 MS-WINw Mail-IT 2 clnt yes mail-it@unipalm.co.uk 7/12/94 +POP23 Unix Mail-IT 2 clnt yes mail-it@unipalm.co.uk 9/9/94 +POP23 Unix servers w Mail-IT srvr na mail-it@unipalm.co.uk 12/16/94 +POP? MS-WIN RFD Mail 1.22 clnt ? ftp.std.com 7/19/94 +POP? MS-WIN RFD Mail 1.23 clnt ? ftp.std.com 9/16/94 +POP3 MS-WINw ws_gmail srvr na buckshot.usma.edu 9/16/94 +POP3 MS-WINw IMAIL srvr na Ipswitch 9/16/94 +POP3 MS-WINw Pronto Mail 2.01 clnt yes Commtouch 4/24/96 (www.commtouc +h.com) +IMAP MS-WINw Pronto clnt yes Commtouch 9/5/95 +IMAP4 ? Pronto97 clnt yes CommTouch 1/7/97 (www.commtouch +.com) +POP3 ? Pronto97 clnt yes CommTouch 1/7/97 (www.commtouch +.com) +POP23 MS-WINw Turnpike clnt yes Turnpike Ltd, http:www.turnpike +.com 8/11/95 +POP3 MS-WIN WinSmtp srvr na Seattle Labs, http://wildside.k +wnet.on.ca/winsmtp.html 11/3/95 +POP3r WIN95 SLmail95 srvr na http://www.seattlelab.com/ 5/14 +/96 +POP3r NT SLmailNT srvr na http://www.seattlelab.com/ 3/29 +/96 +POP3 ? VA Professional clnt yes Ashmount 4/30/96 http://www.asn +mount.com +POP3 ? VA Workgroup clnt yes Ashmount 4/30/96 http://www.asn +mount.com +POP3 NT post.office srvr na Software.com, Inc. 12/11/95 (ww +w.software.com) +POP3 Solaris post.office srvr na Software.com, Inc. 12/11/95 (ww +w.software.com) +POP? MS-? Exchange clnt ? Microsoft 10/24/95 +POP3 MS-? Exchange Server (f) srvr yes Microsoft 9/11/96 +IMAP4 MS-? Exch Server (maybe) srvr ? Microsoft 6/21/96 +POP3 MS-? Exchange Server 5.0 srvr ? Microsoft 1/14/97 +POP3 MS-? Inter. Mail & News clnt yes Microsoft 6/4/96 (www.microsoft +.com) +POP3 MS-? Inter. Mail Service gway ? Microsoft 6/4/96 (www.microsoft +.com) +POP3u NT Exchpop(?) 1.0 gway yes http://www.sts.co.il/pop3.htm 6 +/14/96 +POP3 MacOS Powertalk ? ? ? 11/7/95 +IMAP2 MS-WIN Siren Mail clnt yes Siren Software 12/28/95 +IMAP? Windows? Siren Mail 3.0 clnt yes Siren Software 3/19/96 +POP3 MS-WIN Siren Mail clnt yes Siren Software 12/28/95 +IMAP2 WIN95 Siren Mail clnt yes Siren Software 12/28/95 +POP3 WIN95 Siren Mail clnt yes Siren Software 12/28/95 +IMAP2 NTclient Siren Mail clnt yes Siren Software 12/28/95 +POP3 NTclient Siren Mail clnt yes Siren Software 12/28/95 +? Unix Siren Mail srvr ? Siren Software 12/28/95 +IMAP2 ? Siren Mail Server srvr ? Siren Software 8/1/96 +POP3 ? Siren Mail Server srvr ? Siren Software 8/1/96 +IMAP4 ? Siren Mail (future) clnt yes Siren Software 12/28/95 +IMAP? MacOS Siren Mail (future) clnt yes Siren Software 1/21/96 +IMAP? WIN95 Siren Mail (beta) clnt yes Siren Software 7/30/96 +POP3 MacOS NetAlly srvr na Delphic (www.delphic.com) 11/17 +/95 +POP3 DOSWIN BeyondMail clnt yes Banyan (beyondmail.banyan.com) +2/6/96 +IMAP4 ? BeyondMail (future) clnt yes Banyan (beyondmail.banyan.com) +9/6/96 +POP? NT MailSrv from Res K. srvr na Microsoft? +IMAP WIN? ? clnt ? Email connection 12/8/95 +POP3 NetWare34 SoftNet WEBserv srvr na Puzzle Systems 12/15/95 (info@p +uzzle.com) +POP3 NT Netscape Mail Srvr srvr na Netscape 12/18/95 (info@netscap +e.com) +POP3 SunOS Netscape Mail Srvr srvr na Netscape 12/18/95 (info@netscap +e.com) +POP3 Solaris Netscape Mail Srvr srvr na Netscape 12/18/95 (info@netscap +e.com) +IMAP4 NT Netscape M S 2.0(f) srvr ? Netscape 6/21/96 +IMAP4 NT Netscape M S 2.02 srvr ? Netscape 1/31/97 +POP3 OpenVMS TCPware Internet Sr srvr na Process Software 12/20/95 (info +@process.com) +POP3 Unix UMT (beta) clnt ? ftp.topaz.kiev.ua 12/29/95 (www +.topaz.kiev.ua) +POP3 NetWare 4 LAN WorkGroup 5 ???? na Novell 1/1/96 +IMAP2 Solaris MMail clnt yes Atelier de Software Ltd. 5/21/9 +6 +IMAP2 MacOS MMail (planned) clnt yes Atelier de Software Ltd. 5/21/9 +6 +POP? OS/2 Yarn/Souper(?) clnt ? ? 1/16/96 +POP3 NT Sendmail w POP3 1.0 srvr na MetaInfo 1/19/96 http://www.met +ainfo.com +POP3 NT Sendmail w POP3 1.1 srvr na MetaInfo 12/4/96 http://www.met +ainfo.com +POP3 ? PopGate gway na ftp.esi sys.com 1/19/96 +POP3 OS/2 ? (future) srvr na Secant 1/23/96 +?POP3 NT NT MAIL ? ? http://bhs.com 1/26/96 +POP3 NT MAILbus Internet srvr na Digital 2/20/96 (www.digital.co +m) +POP3 DEC UNIX MAILbus Internet srvr na Digital 2/20/96 (www.digital.co +m) +POP3r NT MAILbus Internet(b) srvr na Digital 2/20/96 (www.digital.co +m) +POP3r DEC UNIX MAILbus Internet(b) srvr na Digital 2/20/96 (www.digital.co +m) +POP? OS/2 lampop(?) clnt ? ? 1/26/96 +POP? NT NTMail clnt ? www.mortimer.com 2/9/96 +POP3 DOSWINMac OpenMail (future) clnt ? HP 3/29/96 http://www.openmail. +external.hp.com +IMAP DOSWINMac OpenMail (future) clnt ? HP 3/29/96 http://www.openmail. +external.hp.com +POP3 NetWare4 Connect2SMTP srvr ? Infinite Technologies 3/29/96 +POP3 OS/2 PowerWeb Server++ srvr na CompuSource 4/16/96 http://www. +compusource.co.za +POP3 OS/2 SIDIS/2 srvr na stargate.rz.fh-offenburg.de 6/4 +/96 +POP3 ? WIG v2.0 gway ? http://www.demon.co.uk/ 4/19/96 +POP3 WIN95 Windis32 srvr na Demon Internet 6/6/96 (www.demo +n.co.uk) +POP3 DOSWINMac DaVinci SMTP eMAIL clnt yes On Technology 4/24/96 +POP? WIN32 Mail OnNet (OnNet32)clnt yes FTP Software 5/3/96 (www.ftp.co +m) +POP? Unix xfmail clnt ? burka.netvision.net.il 5/110/96 +POP3rutOS/2 POP3s v1.01 srvr ? www.secant.com 5/14/96 +POP3 Java Aplt Yamp clnt ? www.mcs.net/~faisal/Yamp/yampix +.html 5/24/96 +POP3 NT NT Mail gway ? www.net-shopper.co.uk 5/31/96 +POP3 WIN? Mailcall chkr na ? 6/11/96 +POP3 WIN? Mailcheck chkr na ? 6/11/96 +POP3 DOS C2SMTP srvr na Infinite Technologies 6/11/96 +POP MacOS Quarterdeck v4(fut) clnt yes Starnine 6/11/96 (www.starnine. +com) +POP MacOS List Star ? ? Starnine 6/24/96 (www.starnine. +com) +POP3 MacOS Marionet 1.0 srvr na Allegiant 6/12/96 (www.allegian +t.com) +POP3 ? Mailcoach V1.0 srvr na http://www.multi.se/ymex/mailco +ach.htm 6/14/96 +IMAP4 WIN3/NT/95 JetMail clnt yes NetManage 7/29/96 +POP3 WIN3/NT/95 JetMail clnt yes NetManage 7/29/96 +POP3 NT Post.Office srvr na NetManage 8/22/96 www.netmanage +.com +POP3 SunOS Post.Office srvr na NetManage 8/22/96 www.netmanage +.com +POP3 Solaris Post.Office srvr na NetManage 8/22/96 www.netmanage +.com +POP3 Unix Z-Pop 1.0 srvr na NetManage 8/22/96 www.netmanage +.com +POP3 AppleShare FutureShare (fut) srvr na Apple 6/14/96 +POP? ? Applixware ? ? Applix 6/24/96 +POP3 Unix Mail*Hub srvr ? CDC 10/23/96 www.cdc.com +IMAP4 Unix Mail*Hub srvr ? CDC 10/23/96 www.cdc.com +POP? Unix TkRat clnt ? www.dtek.chalmers.se/~maf/ratat +osk 6/24/96 +IMAP? Unix TkRat clnt ? www.dtek.chalmers.se/~maf/ratat +osk 6/24/96 +IMAP? Unix Elm clnt ? ? 7/1/96 +POP3 WIN16/32 Virtual Access clnt yes www.ashmount.com 8/9/96 +POP3 ? pop-perl5 clnt ? ? 7/23/96 +POP3 WIN95 Agent clnt ? ? 7/23/96 +POP3 ? Mail eXtension 1.60 clnt ? Terckland 7/26/96 (ourworld.com +puserve.com/homepages/mailx) +POP3 WIN3/95/NT Emissary Office 1.1 clnt yes Attachmate 7/29/96 +POP3 WIN3/95 Pronto Mail 2.0 clnt yes CommTouch 7/29/96 +POP3 ? gcMail 081b (beta) clnt ? www.greencedars.com 8/9/96 +POP3r Java shareware Java cls clnt ? Koehn Consulting 8/2/96 +POP3 ? cucipop (future) srvr na cuci.nl 8/6/96 +POP3 MacOS QuickMail Pro clnt ? CE Software www.cesoft.com 12/1 +9/96 +POP3 ? QuickMail Pro (fut) clnt ? CE Software www.cesoft.com 8/9/ +96 +IMAP? ? QuickMail Pro (fut) clnt ? CE Software www.cesoft.com 8/9/ +96 +POP3 ? QuickMail POP (fut) clnt ? CE Software www.cesoft.com 8/9/ +96 +POP3 ? QM-Internet Gateway ? ? CE Software 6/24/96 +POP3 ? Lotus Notes 4.5 srv srvr ? Lotus 10/17/97 +POP3 Be BeMail clnt ? www.be.com 11/25/96 +POP3 NT Metainfo/Intergate srvr na ? 11/26/96 +POP3 Java Novita Mail clnt ? Novita Comm 12/10/96 +IMAP? Java Novita Mail clnt ? Novita Comm 12/10/96 +IMAP? Windows Winbox 3.1 Beta 1 clnt ? ftp.uv.es 12/13/96 +POP? Windows Winbox 3.1 Beta 1 clnt ? ftp.uv.es 12/13/96 +POP3 MacOS Bluto (future) clnt yes Bare Bones www.barebones.com 12 +/18/96 +POP3 WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +IMAP WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +------ ---------- ------------------- ---- ---- ------------------------------- + + + _________________________________________________________________ + +Some other packages for desktop systems + + +------ ---------- ------------------- ---- ---- ------------------------------- +? MS-DOSs CMM peer ? Cinetic Systems 1/25/94 +? MS-DOSs WinMail 1.1a peer ? Obsolete +SMTP MacOS LeeMail 1.2.4 peer ? Shareware, laf@mitre.org +SMTP MacOS LeeMail 2.0.2 (shw) peer ? chs.cusd.claremont.edu 10/12/93 +SMTP MS-DOSni ChameleonNFS peer ? NetManage 2/25/94 +SMTP MS-WINw ws_gmail peer ? buckshot.usma.edu 5/26/94 +uucp MacOS FernMail peer ? Shareware, dplatt@snulbug.mtvie +w.ca.us +prop MacOS MacPost both ? ftp.lu.se 10/19/93 +uucp MacOS Eudora >1.3.1 peer yes ftp.qualcomm.com 5/10/94 +MAPI WIN3/95/NT Eudora Pro ? clnt yes Qualcomm 7/29/96 +uucp MacOS UUPC peer ? dplatt@snulbug.mtview.ca.us +uucp MacOS gnuucp peer ? jim@fpr.com +uucp MS-DOS waffle peer ? ? dell@vox.darkside.com 10/24/9 +4 +uucp MS-DOS UUPC peer ? ? help@kew.com 10/24/94 +fshare MS-Windows Pegasus/Win 2.3 clnt ? risc.ua.edu 6/6/96 +fshare MS-Windows Pegasus/Win 2.2(r3) clnt ? risc.ua.edu 6/6/96 +fshare MS-Windows Pegasus/Win 2.0(r1) clnt ? risc.ua.edu 6/6/96 +fshare MS-DOS Pegasus/DOS 3.2(r2) clnt ? risc.ua.edu 6/6/96 +fshare MacOS Pegasus/MAC 2.1.2 clnt ? risc.ua.edu 6/6/96 +fshare MS-Windows Pegasus/Win 2.4.2 clnt ? risc.ua.edu 8/2/96 +fshare MS-DOS Pegasus/DOS 3.3.1 clnt ? risc.ua.edu 8/2/96 +SMTP MS-DOS Charon gway ? risc.ua.edu 10/15/93 +Waffle MS-WIN Boxer clnt ? ftp.halcyon.com 12/3/93 +? MS-? pcelm clnt ? simtel 12/3/93 +? MS-? elm-pc clnt ? lister.cc.ic.ac.uk 12/3/93 +SMTP MS-WINw Internt Ex for cc:m gway yes IMA 1/31/94 +SMTP Netware Mercury 1.11 gway ? risc.ua.edu 2/4/94 +? MacOS PowerMail clnt ? Apple 2/18/94 +SMTP OS/2 PC/TCP v1.3 peer ? FTP Software 2/18/94 +MAPI MS-DOS? Microsoft Mail clnt ? Microsoft 3/2/94 +? MacOS Microsoft Mail clnt ? Microsoft 3/15/94 +VIM DOSWINMac cc:mail clnt ? Lotus 3/15/94 +MHS/G DOSWINMac DaVinci eMAIL clnt ? On Technology 4/24/96 +P7uucp DOSWINMac OpenMail clnt ? HP 3/2/94 +? DOSWINMac WordPerfect Office clnt ? WordPerfect Corp. 3/15/94 +? DOSMac MailWorks clnt ? DEC 3/2/94 +MHS/G DOSWIN BeyondMail clnt yes Banyan (beyondmail.banyan.com) +2/6/96 +? DOSOS/2 Higgins Mail clnt ? Enable Software 1/26/95 +? MacOS QuickMail 3.6 clnt ? CE Software 6/6/96 +? DOS QuickMail 3.0 clnt ? CE Software 6/6/96 +? MS-WIN QuickMail 3.5 clnt ? CE Software 6/6/96 +? MacOS QuickMail 4.0 (fut) clnt ? CE Software 6/6/96 +? ? QuickMail ? clnt yes CE Software 7/15/96 +? MS-WIN Team clnt ? Futurus 1/26/95 +? DOSWIN ExpressIT! clnt ? Infinite Technologies 1/26/95 +MAPI WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +MHS WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +VIM WIN95/NT ExpressIT! 2000 clnt ? Infinite Technologies www.ihub. +com 1/14/97 +? ? GroupWise cnlt ? Novell 1/26/95 +? DOSWINMac Lotus Notes clnt ? Lotus 3/15/94 +FCP MacOS FirstClass 2.5 clnt no SoftArc 7/12/94 +FCP MS-WIN FirstClass 2.5 clnt no SoftArc 7/12/94 +FCP MacOS FirstClass 2.5 srvr no SoftArc 7/12/94 +MHS MacOS FirstClass/MHS gway no SoftArc 7/12/94 +UUCP MacOS FirstClass/UUCP gway no SoftArc 7/12/94 +MAPI MS-WINw Mail-IT 2 clnt yes mail-it@unipalm.co.uk 7/12/94 +MAPI ? ECSmail clnt ? ESYS Corp www.esys.ca 12/16/96 +VIM ? ECSmail clnt ? ESYS Corp www.esys.ca 12/16/96 +MAPI MS-WIN SIMEON 4.1 clnt ? ESYS Corp 222.esys.ca 12/16/96 +MAPI WIN3/95/NT Z-Mail 4.0.1 clnt yes NetManage 8/22/96 www.netmanage +.com +MAPI MS-WIN Air Mail ? ? AIR Co. Ltd 10/7/94 +MAPIs MS-WIN Siren Mail ? ? Siren Software 12/28/95 +MAPIs WIN95 Siren Mail ? ? Siren Software 12/28/95 +MAPIs NTclient Siren Mail ? ? Siren Software 12/28/95 +SMTP MS-WINw Mail-IT 2 peer yes mail-it@unipalm.co.uk 7/12/94 +? MS-WINw Panda ? ? ftp.cica.indiana.edu 7/12/94 +PSS MS-Win pMail 3.0 clnt no CommTouch 9/27/94 +PSS MS-DOS pMail 3.0 clnt no CommTouch 9/27/94 +PROP MacOS BlitzMail clnt no ftp.dartmouth.edu 10/23/95 +PROP NeXT OS BlitzMail srvr no ftp.dartmouth.edu 10/23/95 +PROP DEC OSF/1 BlitzMail srvr no ftp.dartmouth.edu 10/23/95 +PROP AIX BlitzMail (in dev) srvr no ftp.dartmouth.edu 10/23/95 +PROP ? FreeMail ? ? whttp://www.montana.com/freemai +l 95/12/8 +PROP MacOS CommuniGate both ? Stalker 5/21/96 (www.stalker.co +m) +SMPT MacOS SMTPGate gway ? Stalker 3/25/96 (www.stalker.co +m) +UUCP MacOS UUCPGate gway ? Stalker 3/25/96 (www.stalker.co +m) +? MacOS Quarterdeck Mail both yes Starnine 6/11/96 (www.starnine. +com) +MAPI WIN3/NT/95 JetMail clnt yes NetManage 7/29/96 +------ ---------- ------------------- ---- ---- ------------------------------- + + + _________________________________________________________________ + +Key and Other Issues + + +(a) What are the common extensions to POP3 and which clients/servers + support them? +POP3k - Kerberos +POP3a - AFS Kerberos +POP3x - ? +POP3t - xtnd xmit facility--allows client to send mail through additional + POP commands, thus allowing server to verify/log source of mail. +POP3r - APOP +POP3m - ? +POP3u - with UIDL command. +(b) What DOS protocol stacks are supported? +MS-DOSm - Lan Manager +MS-DOSn - NDIS Drivers +MS-DOSl - Lan Workplace for Dos +MS-DOSs - Sun PCNFS +MS-DOSp - Packet Drivers +MS-DOSo - ODI Drivers +MS-DOSi - IPXLink +MS-DOSf - FTP Software PC/TCP +MS-DOSk - KA9Q I think +MS-WIN? - similar +MS-WINw - WinSock compliant +MS-WIN5 - Windows 95 +WIN3 - Windows 3.x winsock +WIN3/95/NT - Windows 3.x Winsock, Windows 95 and Windows NT +WIN3/95 - Windows 3.x Winsock and WIndows 95 +NetWare3 - NetWare 3.x +NetWare4 - NetWare 4.x +NetWare34 - NetWare 3.x and 4.x +(c) Other notes +IMAP1 - Original IMAP: I've heard that MacMS actually uses a unique + dialect of it. Definitely obselete, unsupported, discouraged. +IMAP2b - IMAP2bis: name applied to various improved versions of IMAP2. + This development effort culminated in IMAP4. +IMAP24 - IMAP2 or IMAP4 +fshare - uses file sharing. +IMAPb4 - IMAP2, IMAP2bis, or IMAP4. +IMAP41 - IMAP4rev1 +MAPI - Microsoft's Messaging API +MAPIs - Simple MAPI. +VIM - Lotus's Vendor Independent Messaging API +CMC - XAPIA's Common Message Calls API +AOCE - Apple Open Collaborative Environment +PROP - System-specific proprietary protocol +FCP - Softarc's proprietary client-server protocol. +Unix/X - X Windows based +Unix/XM - Motif based +Unix/XO - OpenWindows based +PSS - PROFS Screen Scraper +sumex-aim.stanford.edu* - almost dead as of 7/13/95, to be replaced by + info-mac.org. +Metamail - a package with which MIME messages can be processed from + basically any Unix-based mail client. +POPGate (Stalker Software) - gateway to/from Stalker's CommuniGate + system: enables both use of POP3 to get software from a POP3 server + for use within a CommuniGate community, and to allow POP3 clients to + retrieve mail from a CommuniGate server. +DigUNIX - Digital Unix +Solaris - Solaris 2.x +(d) IMAP/MAPI adaptors: +Wollongong's Pathway Access 7/12/94 +mail-it@unipalm.co.uk's Mail-IT 7/12/94 +(e) IMAP/POP3 adaptors: +Included with NCD Z-mail 4.0 for Windows 9/14/95 +------ ----------- ------------------- ------- ------------------------------- diff --git a/RFC/rfc1081.txt b/RFC/rfc1081.txt new file mode 100644 index 00000000..c21d6e48 --- /dev/null +++ b/RFC/rfc1081.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group M. Rose +Request for Comments: 1081 TWG + November 1988 + + Post Office Protocol - Version 3 + + +Status of this Memo + + This memo suggests a simple method for workstations to dynamically + access mail from a mailbox server. This RFC specifies a proposed + protocol for the Internet community, and requests discussion and + suggestions for improvements. Distribution of this memo is + unlimited. + + This memo is based on RFC 918 (since revised as RFC 937). Although + similar in form to the original Post Office Protocol (POP) proposed + for the Internet community, the protocol discussed in this memo is + similar in spirit to the ideas investigated by the MZnet project at + the University of California, Irvine. + + Further, substantial work was done on examining POP in a PC-based + environment. This work, which resulted in additional functionality + in this protocol, was performed by the ACIS Networking Systems Group + at Stanford University. The author gratefully acknowledges their + interest. + +Introduction + + On certain types of smaller nodes in the Internet it is often + impractical to maintain a message transport system (MTS). For + example, a workstation may not have sufficient resources (cycles, + disk space) in order to permit a SMTP server and associated local + mail delivery system to be kept resident and continuously running. + Similarly, it may be expensive (or impossible) to keep a personal + computer interconnected to an IP-style network for long amounts of + time (the node is lacking the resource known as "connectivity"). + + Despite this, it is often very useful to be able to manage mail on + these smaller nodes, and they often support a user agent (UA) to aid + the tasks of mail handling. To solve this problem, a node which can + support an MTS entity offers a maildrop service to these less endowed + nodes. The Post Office Protocol - Version 3 (POP3) is intended to + permit a workstation to dynamically access a maildrop on a server + host in a useful fashion. Usually, this means that the POP3 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + + + +Rose [Page 1] + +RFC 1081 POP3 November 1988 + + + For the remainder of this memo, the term "client host" refers to a + host making use of the POP3 service, while the term "server host" + refers to a host which offers the POP3 service. + +A Short Digression + + This memo does not specify how a client host enters mail into the + transport system, although a method consistent with the philosophy of + this memo is presented here: + + When the user agent on a client host wishes to enter a message + into the transport system, it establishes an SMTP connection to + its relay host (this relay host could be, but need not be, the + POP3 server host for the client host). + + If this method is followed, then the client host appears to the MTS + as a user agent, and should NOT be regarded as a "trusted" MTS entity + in any sense whatsoever. This concept, along with the role of the + POP3 as a part of a split-UA model is discussed later in this memo. + + Initially, the server host starts the POP3 service by listening on + TCP port 110. When a client host wishes to make use of the service, + it establishes a TCP connection with the server host. When the + connection is established, the POP3 server sends a greeting. The + client and POP3 server then exchange commands and responses + (respectively) until the connection is closed or aborted. + + Commands in the POP3 consist of a keyword possibly followed by an + argument. All commands are terminated by a CRLF pair. + + Responses in the POP3 consist of a success indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. There are currently two success + indicators: positive ("+OK") and negative ("-ERR"). + + Responses to certain commands are multi-line. In these cases, which + are clearly indicated below, after sending the first line of the + response and a CRLF, any additional lines are sent, each terminated + by a CRLF pair. When all lines of the response have been sent, a + final line is sent, consisting of a termination octet (decimal code + 046, ".") and a CRLF pair. If any line of the multi-line response + begins with the termination octet, the line is "byte-stuffed" by + pre-pending the termination octet to that line of the response. + Hence a multi-line response is terminated with the five octets + "CRLF.CRLF". When examining a multi-line response, the client checks + to see if the line begins with the termination octet. If so and if + octets other than CRLF follow, the the first octet of the line (the + termination octet) is stripped away. If so and if CRLF immediately + + + +Rose [Page 2] + +RFC 1081 POP3 November 1988 + + + follows the termination character, then the response from the POP + server is ended and the line containing ".CRLF" is not considered + part of the multi-line response. + + A POP3 session progresses through a number of states during its + lifetime. Once the TCP connection has been opened and the POP3 + server has sent the greeting, the session enters the AUTHORIZATION + state. In this state, the client must identify itself to the POP3 + server. Once the client has successfully done this, the server + acquires resources associated with the client's maildrop, and the + session enters the TRANSACTION state. In this state, the client + requests actions on the part of the POP3 server. When the client has + finished its transactions, the session enters the UPDATE state. In + this state, the POP3 server releases any resources acquired during + the TRANSACTION state and says goodbye. The TCP connection is then + closed. + +The AUTHORIZATION State + + Once the TCP connection has been opened by a POP3 client, the POP3 + server issues a one line greeting. This can be any string terminated + by CRLF. An example might be: + + S. +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + The POP3 session is now in the AUTHORIZATION state. The client must + now issue the USER command. If the POP3 server responds with a + positive success indicator ("+OK"), then the client may issue either + the PASS command to complete the authorization, or the QUIT command + to terminate the POP3 session. If the POP3 server responds with a + negative success indicator ("-ERR") to the USER command, then the + client may either issue a new USER command or may issue the QUIT + command. + + When the client issues the PASS command, the POP3 server uses the + argument pair from the USER and PASS commands to determine if the + client should be given access to the appropriate maildrop. If so, + the POP3 server then acquires an exclusive-access lock on the + maildrop. If the lock is successfully acquired, the POP3 server + parses the maildrop into individual messages (read note below), + determines the last message (if any) present in the maildrop that was + referenced by the RETR command, and responds with a positive success + indicator. The POP3 session now enters the TRANSACTION state. If + the lock can not be acquired or the client should is denied access to + the appropriate maildrop or the maildrop can't be parsed for some + + + +Rose [Page 3] + +RFC 1081 POP3 November 1988 + + + reason, the POP3 server responds with a negative success indicator. + (If a lock was acquired but the POP3 server intends to respond with a + negative success indicator, the POP3 server must release the lock + prior to rejecting the command.) At this point, the client may + either issue a new USER command and start again, or the client may + issue the QUIT command. + + NOTE: Minimal implementations of the POP3 need only be + able to break a maildrop into its component messages; + they need NOT be able to parse individual messages. + More advanced implementations may wish to have this + capability, for reasons discussed later. + + After the POP3 server has parsed the maildrop into individual + messages, it assigns a message-id to each message, and notes the size + of the message in octets. The first message in the maildrop is + assigned a message-id of "1", the second is assigned "2", and so on, + so that the n'th message in a maildrop is assigned a message-id of + "n". In POP3 commands and responses, all message-id's and message + sizes are expressed in base-10 (i.e., decimal). + + It sets the "highest number accessed" to be that of the last message + referenced by the RETR command. + + Here are summaries for the three POP3 commands discussed thus far: + + USER name + Arguments: a server specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting or after an + unsuccessful USER or PASS command + Possible Responses: + +OK name is welcome here + -ERR never heard of name + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + ... + C: USER frated + S: -ERR sorry, frated doesn't get his mail here + + PASS string + Arguments: a server/user-id specific password (required) + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command + Possible Responses: + +OK maildrop locked and ready + -ERR invalid password + + + +Rose [Page 4] + +RFC 1081 POP3 November 1988 + + + -ERR unable to lock maildrop + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages + (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR unable to lock mrose's maildrop, file + already locked + + QUIT + Arguments: none + Restrictions: none + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + + +The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and burst the appropriate maildrop, + the POP3 session is now in the TRANSACTION state. The client may now + issue any of the following POP3 commands repeatedly. After each + command, the POP3 server issues a response. Eventually, the client + issues the QUIT command and the POP3 session enters the UPDATE state. + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + Arguments: none + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing information for the maildrop. This line is + called a "drop listing" for that maildrop. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for drop listings. + The first octets present must indicate the number of + messages in the maildrop. Following this is the size + + + +Rose [Page 5] + +RFC 1081 POP3 November 1988 + + + of the maildrop in octets. This memo makes no + requirement on what follows the maildrop size. + Minimal implementations should just end that line of + the response with a CRLF pair. More advanced + implementations may include other information. + + NOTE: This memo STRONGLY discourages + implementations from supplying additional + information in the drop listing. Other, + optional, facilities are discussed later on + which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not counted in + either total. + + Possible Responses: + +OK nn mm + Examples: + C: STAT + S: +OK 2 320 + + LIST [msg] + Arguments: a message-id (optionally) If a message-id is + given, it may NOT refer to a message marked as + deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If an argument was given and the POP3 server issues a + positive response with a line containing information + for that message. This line is called a "scan listing" + for that message. + + If no argument was given and the POP3 server issues a + positive response, then the response given is + multi-line. After the initial +OK, for each message + in the maildrop, the POP3 server responds with a line + containing information for that message. This line + is called a "scan listing" for that message. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. + The first octets present must be the message-id of + the message. Following the message-id is the size of + the message in octets. This memo makes no requirement + on what follows the message size in the scan listing. + Minimal implementations should just end that line of + + + +Rose [Page 6] + +RFC 1081 POP3 November 1988 + + + the response with a CRLF pair. More advanced + implementations may include other information, as + parsed from the message. + + NOTE: This memo STRONGLY discourages + implementations from supplying additional + information in the scan listing. Other, optional, + facilities are discussed later on which permit + the client to parse the messages in the maildrop. + + Note that messages marked as deleted are not listed. + + Possible Responses: + +OK scan listing follows + -ERR no such message + Examples: + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + ... + C: LIST 2 + S: +OK 2 200 + ... + C: LIST 3 + S: -ERR no such message, only 2 messages in + maildrop + + RETR msg + Arguments: a message-id (required) This message-id may + NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, + the POP3 server sends the message corresponding to the + given message-id, being careful to byte-stuff the + termination character (as with all multi-line + responses). + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, the + POP3 server updates the "highest number accessed" to + the number associated with this message. + + + + + +Rose [Page 7] + +RFC 1081 POP3 November 1988 + + + Possible Responses: + +OK message follows + -ERR no such message + Examples: + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends the entire message here> + S: . + + DELE msg + Arguments: a message-id (required) This message-id + may NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server marks the message as deleted. Any + future reference to the message-id associated with the + message in a POP3 command generates an error. The POP3 + server does not actually delete the message until the + POP3 session enters the UPDATE state. + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, + the POP3 server updates the "highest number accessed" + to the number associated with this message. + + Possible Responses: + +OK message deleted + -ERR no such message + Examples: + C: DELE 1 + S: +OK message 1 deleted + ... + C: DELE 2 + S: -ERR message 2 already deleted + + NOOP + Arguments: none + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server does nothing, it merely replies with a + positive response. + + Possible Responses: + +OK + + + + + +Rose [Page 8] + +RFC 1081 POP3 November 1988 + + + Examples: + C: NOOP + S: +OK + + LAST + Arguments: none + Restrictions: may only be issued in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing the highest message number which accessed. + Zero is returned in case no message in the maildrop has + been accessed during previous transactions. A client + may thereafter infer that messages, if any, numbered + greater than the response to the LAST command are + messages not yet accessed by the client. + + Possible Response: + +OK nn + + Examples: + C: STAT + S: +OK 4 320 + C: LAST + S: +OK 1 + C: RETR 3 + S: +OK 120 octets + S: <the POP3 server sends the entire message + here> + S: . + C: LAST + S: +OK 3 + C: DELE 2 + S: +OK message 2 deleted + C: LAST + S: +OK 3 + C: RSET + S: +OK + C: LAST + S: +OK 1 + + RSET + Arguments: none + Restrictions: may only be given in the TRANSACTION + state. + Discussion: + + If any messages have been marked as deleted by the POP3 + + + +Rose [Page 9] + +RFC 1081 POP3 November 1988 + + + server, they are unmarked. The POP3 server then + replies with a positive response. In addition, the + "highest number accessed" is also reset to the value + determined at the beginning of the POP3 session. + + Possible Responses: + +OK + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + + + +The UPDATE State + + When the client issues the QUIT command from the TRANSACTION state, + the POP3 session enters the UPDATE state. (Note that if the client + issues the QUIT command from the AUTHORIZATION state, the POP3 + session terminates but does NOT enter the UPDATE state.) + + QUIT + Arguments: none + Restrictions: none + Discussion: + + The POP3 server removes all messages marked as deleted + from the maildrop. It then releases the + exclusive-access lock on the maildrop and replies as + to the success of + these operations. The TCP connection is then closed. + + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop + empty) + ... + C: QUIT + S: +OK dewey POP3 server signing off (2 messages + left) + ... + + +Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + implementations of POP3 servers. + + + +Rose [Page 10] + +RFC 1081 POP3 November 1988 + + + The optional POP3 commands described below permit a POP3 client + greater freedom in message handling, while preserving a simple POP3 + server implementation. + + NOTE: This memo STRONGLY encourages implementations to + support these commands in lieu of developing augmented + drop and scan listings. In short, the philosophy of + this memo is to put intelligence in the part of the + POP3 client and not the POP3 server. + + TOP msg n + Arguments: a message-id (required) and a number. This + message-id may NOT refer to a message marked as + deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If the POP3 server issues a positive response, then + the response given is multi-line. After the initial + +OK, the POP3 server sends the headers of the message, + the blank line separating the headers from the body, + and then the number of lines indicated message's body, + being careful to byte-stuff the termination character + (as with all multi-line responses). + + Note that if the number of lines requested by the POP3 + client is greater than than the number of lines in the + body, then the POP3 server sends the entire message. + + Possible Responses: + +OK top of message follows + -ERR no such message + Examples: + C: TOP 10 + S: +OK + S: <the POP3 server sends the headers of the + message, a blank line, and the first 10 lines + of the body of the message> + S: . + ... + C: TOP 100 + S: -ERR no such message + + RPOP user + Arguments: a client specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command; in addition, + may only be given if the client used a reserved + + + +Rose [Page 11] + +RFC 1081 POP3 November 1988 + + + (privileged) TCP port to connect to the server. + Discussion: + + The RPOP command may be used instead of the PASS + command to authenticate access to the maildrop. In + order for this command to be successful, the POP3 + client must use a reserved TCP port (port < 1024) to + connect tothe server. The POP3 server uses the + argument pair from the USER and RPOP commands to + determine if the client should be given access to + the appropriate maildrop. Unlike the PASS command + however, the POP3 server considers if the remote user + specified by the RPOP command who resides on the POP3 + client host is allowed to access the maildrop for the + user specified by the USER command (e.g., on Berkeley + UNIX, the .rhosts mechanism is used). With the + exception of this differing in authentication, this + command is identical to the PASS command. + + Note that the use of this feature has allowed much wider + penetration into numerous hosts on local networks (and + sometimes remote networks) by those who gain illegal + access to computers by guessing passwords or otherwise + breaking into the system. + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: RPOP mrose + S: +OK mrose's maildrop has 2 messages (320 + octets) + + Minimal POP3 Commands: + USER name valid in the AUTHORIZATION state + PASS string + QUIT + + STAT valid in the TRANSACTION state + LIST [msg] + RETR msg + DELE msg + NOOP + LAST + RSET + + + + +Rose [Page 12] + +RFC 1081 POP3 November 1988 + + + QUIT valid in the UPDATE state + + Optional POP3 Commands: + RPOP user valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + + POP3 Replies: + +OK + -ERR + + Note that with the exception of the STAT command, the reply given + by the POP3 server to any command is significant only to "+OK" + and "-ERR". Any text occurring after this reply may be ignored + by the client. + +Example POP3 Session + + S: <wait for connection on TCP port 110> + ... + C: <open connection> + S: +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages (320 octets) + C: STAT + S: +OK 2 320 + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends message 1> + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: <the POP3 server sends message 2> + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + + + + + +Rose [Page 13] + +RFC 1081 POP3 November 1988 + + + S: +OK dewey POP3 server signing off (maildrop empty) + C: <close connection> + S: <wait for next connection> + +Message Format + + All messages transmitted during a POP3 session are assumed to conform + to the standard for the format of Internet text messages [RFC822]. + + It is important to note that the byte count for a message on the + server host may differ from the octet count assigned to that message + due to local conventions for designating end-of-line. Usually, + during the AUTHORIZATION state of the POP3 session, the POP3 client + can calculate the size of each message in octets when it parses the + maildrop into messages. For example, if the POP3 server host + internally represents end-of-line as a single character, then the + POP3 server simply counts each occurrence of this character in a + message as two octets. Note that lines in the message which start + with the termination octet need not be counted twice, since the POP3 + client will remove all byte-stuffed termination characters when it + receives a multi-line response. + +The POP and the Split-UA model + + The underlying paradigm in which the POP3 functions is that of a + split-UA model. The POP3 client host, being a remote PC based + workstation, acts solely as a client to the message transport system. + It does not provide delivery/authentication services to others. + Hence, it is acting as a UA, on behalf of the person using the + workstation. Furthermore, the workstation uses SMTP to enter mail + into the MTS. + + In this sense, we have two UA functions which interface to the + message transport system: Posting (SMTP) and Retrieval (POP3). The + entity which supports this type of environment is called a split-UA + (since the user agent is split between two hosts which must + interoperate to provide these functions). + + ASIDE: Others might term this a remote-UA instead. + There are arguments supporting the use of both terms. + + This memo has explicitly referenced TCP as the underlying transport + agent for the POP3. This need not be the case. In the MZnet split- + UA, for example, personal micro-computer systems are used which do + not have IP-style networking capability. To connect to the POP3 + server host, a PC establishes a terminal connection using some simple + protocol (PhoneNet). A program on the PC drives the connection, + first establishing a login session as a normal user. The login shell + + + +Rose [Page 14] + +RFC 1081 POP3 November 1988 + + + for this pseudo-user is a program which drives the other half of the + terminal protocol and communicates with one of two servers. Although + MZnet can support several PCs, a single pseudo-user login is present + on the server host. The user-id and password for this pseudo-user + login is known to all members of MZnet. Hence, the first action of + the login shell, after starting the terminal protocol, is to demand a + USER/PASS authorization pair from the PC. This second level of + authorization is used to ascertain who is interacting with the MTS. + Although the server host is deemed to support a "trusted" MTS entity, + PCs in MZnet are not. Naturally, the USER/PASS authorization pair + for a PC is known only to the owner of the PC (in theory, at least). + + After successfully verifying the identity of the client, a modified + SMTP server is started, and the PC posts mail with the server host. + After the QUIT command is given to the SMTP server and it terminates, + a modified POP3 server is started, and the PC retrieves mail from the + server host. After the QUIT command is given to the POP3 server and + it terminates, the login shell for the pseudo-user terminates the + terminal protocol and logs the job out. The PC then closes the + terminal connection to the server host. + + The SMTP server used by MZnet is modified in the sense that it knows + that it's talking to a user agent and not a "trusted" entity in the + message transport system. Hence, it does performs the validation + activities normally performed by an entity in the MTS when it accepts + a message from a UA. + + The POP3 server used by MZnet is modified in the sense that it does + not require a USER/PASS combination before entering the TRANSACTION + state. The reason for this (of course) is that the PC has already + identified itself during the second-level authorization step + described above. + + NOTE: Truth in advertising laws require that the author + of this memo state that MZnet has not actually been + fully implemented. The concepts presented and proven + by the project led to the notion of the MZnet + split-slot model. This notion has inspired the + split-UA concept described in this memo, led to the + author's interest in the POP, and heavily influenced + the the description of the POP3 herein. + + In fact, some UAs present in the Internet already support the notion + of posting directly to an SMTP server and retrieving mail directly + from a POP server, even if the POP server and client resided on the + same host! + + ASIDE: this discussion raises an issue which this memo + + + +Rose [Page 15] + +RFC 1081 POP3 November 1988 + + + purposedly avoids: how does SMTP know that it's talking + to a "trusted" MTS entity? + +References + + [MZnet] Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail + Service for Personal Micro-Computer Systems", + Proceedings, IFIP 6.5 International Conference on + Computer Message Systems, Nottingham, U.K., May 1984. + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", + USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet + Text Messages", University of Delaware, August 1982. + + [RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. + Reynolds, "Post Office Protocol - Version 2", RFC 937, + USC/Information Sciences Institute, February 1985. + + [RFC1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC + 1010, USC/Information Sciences Institute, May 1987. + +Author's Address: + + + Marshall Rose + The Wollongong Group + 1129 San Antonio Rd. + Palo Alto, California 94303 + + Phone: (415) 962-7100 + + Email: MRose@TWG.COM + + + + + + + + + + + + + + + + + +Rose [Page 16] +
\ No newline at end of file diff --git a/RFC/rfc1123.txt b/RFC/rfc1123.txt new file mode 100644 index 00000000..51cdf83c --- /dev/null +++ b/RFC/rfc1123.txt @@ -0,0 +1,5782 @@ + + + + + + +Network Working Group Internet Engineering Task Force +Request for Comments: 1123 R. Braden, Editor + October 1989 + + + Requirements for Internet Hosts -- Application and Support + +Status of This Memo + + This RFC is an official specification for the Internet community. It + incorporates by reference, amends, corrects, and supplements the + primary protocol standards documents relating to hosts. Distribution + of this document is unlimited. + +Summary + + This RFC is one of a pair that defines and discusses the requirements + for Internet host software. This RFC covers the application and + support protocols; its companion RFC-1122 covers the communication + protocol layers: link layer, IP layer, and transport layer. + + + + Table of Contents + + + + + 1. INTRODUCTION ............................................... 5 + 1.1 The Internet Architecture .............................. 6 + 1.2 General Considerations ................................. 6 + 1.2.1 Continuing Internet Evolution ..................... 6 + 1.2.2 Robustness Principle .............................. 7 + 1.2.3 Error Logging ..................................... 8 + 1.2.4 Configuration ..................................... 8 + 1.3 Reading this Document .................................. 10 + 1.3.1 Organization ...................................... 10 + 1.3.2 Requirements ...................................... 10 + 1.3.3 Terminology ....................................... 11 + 1.4 Acknowledgments ........................................ 12 + + 2. GENERAL ISSUES ............................................. 13 + 2.1 Host Names and Numbers ................................. 13 + 2.2 Using Domain Name Service .............................. 13 + 2.3 Applications on Multihomed hosts ....................... 14 + 2.4 Type-of-Service ........................................ 14 + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 + + + + +Internet Engineering Task Force [Page 1] + + + + +RFC1123 INTRODUCTION October 1989 + + + 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 + 3.1 INTRODUCTION ........................................... 16 + 3.2 PROTOCOL WALK-THROUGH .................................. 16 + 3.2.1 Option Negotiation ................................ 16 + 3.2.2 Telnet Go-Ahead Function .......................... 16 + 3.2.3 Control Functions ................................. 17 + 3.2.4 Telnet "Synch" Signal ............................. 18 + 3.2.5 NVT Printer and Keyboard .......................... 19 + 3.2.6 Telnet Command Structure .......................... 20 + 3.2.7 Telnet Binary Option .............................. 20 + 3.2.8 Telnet Terminal-Type Option ....................... 20 + 3.3 SPECIFIC ISSUES ........................................ 21 + 3.3.1 Telnet End-of-Line Convention ..................... 21 + 3.3.2 Data Entry Terminals .............................. 23 + 3.3.3 Option Requirements ............................... 24 + 3.3.4 Option Initiation ................................. 24 + 3.3.5 Telnet Linemode Option ............................ 25 + 3.4 TELNET/USER INTERFACE .................................. 25 + 3.4.1 Character Set Transparency ........................ 25 + 3.4.2 Telnet Commands ................................... 26 + 3.4.3 TCP Connection Errors ............................. 26 + 3.4.4 Non-Default Telnet Contact Port ................... 26 + 3.4.5 Flushing Output ................................... 26 + 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 + + 4. FILE TRANSFER .............................................. 29 + 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 + 4.1.1 INTRODUCTION ...................................... 29 + 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 + 4.1.2.1 LOCAL Type ................................... 29 + 4.1.2.2 Telnet Format Control ........................ 30 + 4.1.2.3 Page Structure ............................... 30 + 4.1.2.4 Data Structure Transformations ............... 30 + 4.1.2.5 Data Connection Management ................... 31 + 4.1.2.6 PASV Command ................................. 31 + 4.1.2.7 LIST and NLST Commands ....................... 31 + 4.1.2.8 SITE Command ................................. 32 + 4.1.2.9 STOU Command ................................. 32 + 4.1.2.10 Telnet End-of-line Code ..................... 32 + 4.1.2.11 FTP Replies ................................. 33 + 4.1.2.12 Connections ................................. 34 + 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 + 4.1.3 SPECIFIC ISSUES ................................... 35 + 4.1.3.1 Non-standard Command Verbs ................... 35 + 4.1.3.2 Idle Timeout ................................. 36 + 4.1.3.3 Concurrency of Data and Control .............. 36 + 4.1.3.4 FTP Restart Mechanism ........................ 36 + 4.1.4 FTP/USER INTERFACE ................................ 39 + + + +Internet Engineering Task Force [Page 2] + + + + +RFC1123 INTRODUCTION October 1989 + + + 4.1.4.1 Pathname Specification ....................... 39 + 4.1.4.2 "QUOTE" Command .............................. 40 + 4.1.4.3 Displaying Replies to User ................... 40 + 4.1.4.4 Maintaining Synchronization .................. 40 + 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 + 4.2.1 INTRODUCTION ...................................... 44 + 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 + 4.2.2.1 Transfer Modes ............................... 44 + 4.2.2.2 UDP Header ................................... 44 + 4.2.3 SPECIFIC ISSUES ................................... 44 + 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 + 4.2.3.2 Timeout Algorithms ........................... 46 + 4.2.3.3 Extensions ................................... 46 + 4.2.3.4 Access Control ............................... 46 + 4.2.3.5 Broadcast Request ............................ 46 + 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 + + 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 + 5.1 INTRODUCTION ........................................... 48 + 5.2 PROTOCOL WALK-THROUGH .................................. 48 + 5.2.1 The SMTP Model .................................... 48 + 5.2.2 Canonicalization .................................. 49 + 5.2.3 VRFY and EXPN Commands ............................ 50 + 5.2.4 SEND, SOML, and SAML Commands ..................... 50 + 5.2.5 HELO Command ...................................... 50 + 5.2.6 Mail Relay ........................................ 51 + 5.2.7 RCPT Command ...................................... 52 + 5.2.8 DATA Command ...................................... 53 + 5.2.9 Command Syntax .................................... 54 + 5.2.10 SMTP Replies ..................................... 54 + 5.2.11 Transparency ..................................... 55 + 5.2.12 WKS Use in MX Processing ......................... 55 + 5.2.13 RFC-822 Message Specification .................... 55 + 5.2.14 RFC-822 Date and Time Specification .............. 55 + 5.2.15 RFC-822 Syntax Change ............................ 56 + 5.2.16 RFC-822 Local-part .............................. 56 + 5.2.17 Domain Literals .................................. 57 + 5.2.18 Common Address Formatting Errors ................. 58 + 5.2.19 Explicit Source Routes ........................... 58 + 5.3 SPECIFIC ISSUES ........................................ 59 + 5.3.1 SMTP Queueing Strategies .......................... 59 + 5.3.1.1 Sending Strategy .............................. 59 + 5.3.1.2 Receiving strategy ........................... 61 + 5.3.2 Timeouts in SMTP .................................. 61 + 5.3.3 Reliable Mail Receipt ............................. 63 + 5.3.4 Reliable Mail Transmission ........................ 63 + 5.3.5 Domain Name Support ............................... 65 + + + +Internet Engineering Task Force [Page 3] + + + + +RFC1123 INTRODUCTION October 1989 + + + 5.3.6 Mailing Lists and Aliases ......................... 65 + 5.3.7 Mail Gatewaying ................................... 66 + 5.3.8 Maximum Message Size .............................. 68 + 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 + + 6. SUPPORT SERVICES ............................................ 72 + 6.1 DOMAIN NAME TRANSLATION ................................. 72 + 6.1.1 INTRODUCTION ....................................... 72 + 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 + 6.1.2.1 Resource Records with Zero TTL ............... 73 + 6.1.2.2 QCLASS Values ................................ 73 + 6.1.2.3 Unused Fields ................................ 73 + 6.1.2.4 Compression .................................. 73 + 6.1.2.5 Misusing Configuration Info .................. 73 + 6.1.3 SPECIFIC ISSUES ................................... 74 + 6.1.3.1 Resolver Implementation ...................... 74 + 6.1.3.2 Transport Protocols .......................... 75 + 6.1.3.3 Efficient Resource Usage ..................... 77 + 6.1.3.4 Multihomed Hosts ............................. 78 + 6.1.3.5 Extensibility ................................ 79 + 6.1.3.6 Status of RR Types ........................... 79 + 6.1.3.7 Robustness ................................... 80 + 6.1.3.8 Local Host Table ............................. 80 + 6.1.4 DNS USER INTERFACE ................................ 81 + 6.1.4.1 DNS Administration ........................... 81 + 6.1.4.2 DNS User Interface ........................... 81 + 6.1.4.3 Interface Abbreviation Facilities ............. 82 + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 + 6.2 HOST INITIALIZATION .................................... 87 + 6.2.1 INTRODUCTION ...................................... 87 + 6.2.2 REQUIREMENTS ...................................... 87 + 6.2.2.1 Dynamic Configuration ........................ 87 + 6.2.2.2 Loading Phase ................................ 89 + 6.3 REMOTE MANAGEMENT ...................................... 90 + 6.3.1 INTRODUCTION ...................................... 90 + 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 + + 7. REFERENCES ................................................. 93 + + + + + + + + + + + + +Internet Engineering Task Force [Page 4] + + + + +RFC1123 INTRODUCTION October 1989 + + +1. INTRODUCTION + + This document is one of a pair that defines and discusses the + requirements for host system implementations of the Internet protocol + suite. This RFC covers the applications layer and support protocols. + Its companion RFC, "Requirements for Internet Hosts -- Communications + Layers" [INTRO:1] covers the lower layer protocols: transport layer, + IP layer, and link layer. + + These documents are intended to provide guidance for vendors, + implementors, and users of Internet communication software. They + represent the consensus of a large body of technical experience and + wisdom, contributed by members of the Internet research and vendor + communities. + + This RFC enumerates standard protocols that a host connected to the + Internet must use, and it incorporates by reference the RFCs and + other documents describing the current specifications for these + protocols. It corrects errors in the referenced documents and adds + additional discussion and guidance for an implementor. + + For each protocol, this document also contains an explicit set of + requirements, recommendations, and options. The reader must + understand that the list of requirements in this document is + incomplete by itself; the complete set of requirements for an + Internet host is primarily defined in the standard protocol + specification documents, with the corrections, amendments, and + supplements contained in this RFC. + + A good-faith implementation of the protocols that was produced after + careful reading of the RFC's and with some interaction with the + Internet technical community, and that followed good communications + software engineering practices, should differ from the requirements + of this document in only minor ways. Thus, in many cases, the + "requirements" in this RFC are already stated or implied in the + standard protocol documents, so that their inclusion here is, in a + sense, redundant. However, they were included because some past + implementation has made the wrong choice, causing problems of + interoperability, performance, and/or robustness. + + This document includes discussion and explanation of many of the + requirements and recommendations. A simple list of requirements + would be dangerous, because: + + o Some required features are more important than others, and some + features are optional. + + o There may be valid reasons why particular vendor products that + + + +Internet Engineering Task Force [Page 5] + + + + +RFC1123 INTRODUCTION October 1989 + + + are designed for restricted contexts might choose to use + different specifications. + + However, the specifications of this document must be followed to meet + the general goal of arbitrary host interoperation across the + diversity and complexity of the Internet system. Although most + current implementations fail to meet these requirements in various + ways, some minor and some major, this specification is the ideal + towards which we need to move. + + These requirements are based on the current level of Internet + architecture. This document will be updated as required to provide + additional clarifications or to include additional information in + those areas in which specifications are still evolving. + + This introductory section begins with general advice to host software + vendors, and then gives some guidance on reading the rest of the + document. Section 2 contains general requirements that may be + applicable to all application and support protocols. Sections 3, 4, + and 5 contain the requirements on protocols for the three major + applications: Telnet, file transfer, and electronic mail, + respectively. Section 6 covers the support applications: the domain + name system, system initialization, and management. Finally, all + references will be found in Section 7. + + 1.1 The Internet Architecture + + For a brief introduction to the Internet architecture from a host + viewpoint, see Section 1.1 of [INTRO:1]. That section also + contains recommended references for general background on the + Internet architecture. + + 1.2 General Considerations + + There are two important lessons that vendors of Internet host + software have learned and which a new vendor should consider + seriously. + + 1.2.1 Continuing Internet Evolution + + The enormous growth of the Internet has revealed problems of + management and scaling in a large datagram-based packet + communication system. These problems are being addressed, and + as a result there will be continuing evolution of the + specifications described in this document. These changes will + be carefully planned and controlled, since there is extensive + participation in this planning by the vendors and by the + organizations responsible for operations of the networks. + + + +Internet Engineering Task Force [Page 6] + + + + +RFC1123 INTRODUCTION October 1989 + + + Development, evolution, and revision are characteristic of + computer network protocols today, and this situation will + persist for some years. A vendor who develops computer + communication software for the Internet protocol suite (or any + other protocol suite!) and then fails to maintain and update + that software for changing specifications is going to leave a + trail of unhappy customers. The Internet is a large + communication network, and the users are in constant contact + through it. Experience has shown that knowledge of + deficiencies in vendor software propagates quickly through the + Internet technical community. + + 1.2.2 Robustness Principle + + At every layer of the protocols, there is a general rule whose + application can lead to enormous benefits in robustness and + interoperability: + + "Be liberal in what you accept, and + conservative in what you send" + + Software should be written to deal with every conceivable + error, no matter how unlikely; sooner or later a packet will + come in with that particular combination of errors and + attributes, and unless the software is prepared, chaos can + ensue. In general, it is best to assume that the network is + filled with malevolent entities that will send in packets + designed to have the worst possible effect. This assumption + will lead to suitable protective design, although the most + serious problems in the Internet have been caused by + unenvisaged mechanisms triggered by low-probability events; + mere human malice would never have taken so devious a course! + + Adaptability to change must be designed into all levels of + Internet host software. As a simple example, consider a + protocol specification that contains an enumeration of values + for a particular header field -- e.g., a type field, a port + number, or an error code; this enumeration must be assumed to + be incomplete. Thus, if a protocol specification defines four + possible error codes, the software must not break when a fifth + code shows up. An undefined code might be logged (see below), + but it must not cause a failure. + + The second part of the principle is almost as important: + software on other hosts may contain deficiencies that make it + unwise to exploit legal but obscure protocol features. It is + unwise to stray far from the obvious and simple, lest untoward + effects result elsewhere. A corollary of this is "watch out + + + +Internet Engineering Task Force [Page 7] + + + + +RFC1123 INTRODUCTION October 1989 + + + for misbehaving hosts"; host software should be prepared, not + just to survive other misbehaving hosts, but also to cooperate + to limit the amount of disruption such hosts can cause to the + shared communication facility. + + 1.2.3 Error Logging + + The Internet includes a great variety of host and gateway + systems, each implementing many protocols and protocol layers, + and some of these contain bugs and mis-features in their + Internet protocol software. As a result of complexity, + diversity, and distribution of function, the diagnosis of user + problems is often very difficult. + + Problem diagnosis will be aided if host implementations include + a carefully designed facility for logging erroneous or + "strange" protocol events. It is important to include as much + diagnostic information as possible when an error is logged. In + particular, it is often useful to record the header(s) of a + packet that caused an error. However, care must be taken to + ensure that error logging does not consume prohibitive amounts + of resources or otherwise interfere with the operation of the + host. + + There is a tendency for abnormal but harmless protocol events + to overflow error logging files; this can be avoided by using a + "circular" log, or by enabling logging only while diagnosing a + known failure. It may be useful to filter and count duplicate + successive messages. One strategy that seems to work well is: + (1) always count abnormalities and make such counts accessible + through the management protocol (see Section 6.3); and (2) + allow the logging of a great variety of events to be + selectively enabled. For example, it might useful to be able + to "log everything" or to "log everything for host X". + + Note that different managements may have differing policies + about the amount of error logging that they want normally + enabled in a host. Some will say, "if it doesn't hurt me, I + don't want to know about it", while others will want to take a + more watchful and aggressive attitude about detecting and + removing protocol abnormalities. + + 1.2.4 Configuration + + It would be ideal if a host implementation of the Internet + protocol suite could be entirely self-configuring. This would + allow the whole suite to be implemented in ROM or cast into + silicon, it would simplify diskless workstations, and it would + + + +Internet Engineering Task Force [Page 8] + + + + +RFC1123 INTRODUCTION October 1989 + + + be an immense boon to harried LAN administrators as well as + system vendors. We have not reached this ideal; in fact, we + are not even close. + + At many points in this document, you will find a requirement + that a parameter be a configurable option. There are several + different reasons behind such requirements. In a few cases, + there is current uncertainty or disagreement about the best + value, and it may be necessary to update the recommended value + in the future. In other cases, the value really depends on + external factors -- e.g., the size of the host and the + distribution of its communication load, or the speeds and + topology of nearby networks -- and self-tuning algorithms are + unavailable and may be insufficient. In some cases, + configurability is needed because of administrative + requirements. + + Finally, some configuration options are required to communicate + with obsolete or incorrect implementations of the protocols, + distributed without sources, that unfortunately persist in many + parts of the Internet. To make correct systems coexist with + these faulty systems, administrators often have to "mis- + configure" the correct systems. This problem will correct + itself gradually as the faulty systems are retired, but it + cannot be ignored by vendors. + + When we say that a parameter must be configurable, we do not + intend to require that its value be explicitly read from a + configuration file at every boot time. We recommend that + implementors set up a default for each parameter, so a + configuration file is only necessary to override those defaults + that are inappropriate in a particular installation. Thus, the + configurability requirement is an assurance that it will be + POSSIBLE to override the default when necessary, even in a + binary-only or ROM-based product. + + This document requires a particular value for such defaults in + some cases. The choice of default is a sensitive issue when + the configuration item controls the accommodation to existing + faulty systems. If the Internet is to converge successfully to + complete interoperability, the default values built into + implementations must implement the official protocol, not + "mis-configurations" to accommodate faulty implementations. + Although marketing considerations have led some vendors to + choose mis-configuration defaults, we urge vendors to choose + defaults that will conform to the standard. + + Finally, we note that a vendor needs to provide adequate + + + +Internet Engineering Task Force [Page 9] + + + + +RFC1123 INTRODUCTION October 1989 + + + documentation on all configuration parameters, their limits and + effects. + + + 1.3 Reading this Document + + 1.3.1 Organization + + In general, each major section is organized into the following + subsections: + + (1) Introduction + + (2) Protocol Walk-Through -- considers the protocol + specification documents section-by-section, correcting + errors, stating requirements that may be ambiguous or + ill-defined, and providing further clarification or + explanation. + + (3) Specific Issues -- discusses protocol design and + implementation issues that were not included in the walk- + through. + + (4) Interfaces -- discusses the service interface to the next + higher layer. + + (5) Summary -- contains a summary of the requirements of the + section. + + Under many of the individual topics in this document, there is + parenthetical material labeled "DISCUSSION" or + "IMPLEMENTATION". This material is intended to give + clarification and explanation of the preceding requirements + text. It also includes some suggestions on possible future + directions or developments. The implementation material + contains suggested approaches that an implementor may want to + consider. + + The summary sections are intended to be guides and indexes to + the text, but are necessarily cryptic and incomplete. The + summaries should never be used or referenced separately from + the complete RFC. + + 1.3.2 Requirements + + In this document, the words that are used to define the + significance of each particular requirement are capitalized. + These words are: + + + +Internet Engineering Task Force [Page 10] + + + + +RFC1123 INTRODUCTION October 1989 + + + * "MUST" + + This word or the adjective "REQUIRED" means that the item + is an absolute requirement of the specification. + + * "SHOULD" + + This word or the adjective "RECOMMENDED" means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications should be + understood and the case carefully weighed before choosing + a different course. + + * "MAY" + + This word or the adjective "OPTIONAL" means that this item + is truly optional. One vendor may choose to include the + item because a particular marketplace requires it or + because it enhances the product, for example; another + vendor may omit the same item. + + + An implementation is not compliant if it fails to satisfy one + or more of the MUST requirements for the protocols it + implements. An implementation that satisfies all the MUST and + all the SHOULD requirements for its protocols is said to be + "unconditionally compliant"; one that satisfies all the MUST + requirements but not all the SHOULD requirements for its + protocols is said to be "conditionally compliant". + + 1.3.3 Terminology + + This document uses the following technical terms: + + Segment + A segment is the unit of end-to-end transmission in the + TCP protocol. A segment consists of a TCP header followed + by application data. A segment is transmitted by + encapsulation in an IP datagram. + + Message + This term is used by some application layer protocols + (particularly SMTP) for an application data unit. + + Datagram + A [UDP] datagram is the unit of end-to-end transmission in + the UDP protocol. + + + + +Internet Engineering Task Force [Page 11] + + + + +RFC1123 INTRODUCTION October 1989 + + + Multihomed + A host is said to be multihomed if it has multiple IP + addresses to connected networks. + + + + 1.4 Acknowledgments + + This document incorporates contributions and comments from a large + group of Internet protocol experts, including representatives of + university and research labs, vendors, and government agencies. + It was assembled primarily by the Host Requirements Working Group + of the Internet Engineering Task Force (IETF). + + The Editor would especially like to acknowledge the tireless + dedication of the following people, who attended many long + meetings and generated 3 million bytes of electronic mail over the + past 18 months in pursuit of this document: Philip Almquist, Dave + Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve + Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), + John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), + Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge + (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). + + In addition, the following people made major contributions to the + effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia + (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), + Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), + John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill + Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul + (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue + Technology), and Mike StJohns (DCA). The following also made + significant contributions to particular areas: Eric Allman + (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic + (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn + (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann + (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun + Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen + (Toronto). + + We are grateful to all, including any contributors who may have + been inadvertently omitted from this list. + + + + + + + + + +Internet Engineering Task Force [Page 12] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + +2. GENERAL ISSUES + + This section contains general requirements that may be applicable to + all application-layer protocols. + + 2.1 Host Names and Numbers + + The syntax of a legal Internet host name was specified in RFC-952 + [DNS:4]. One aspect of host name syntax is hereby changed: the + restriction on the first character is relaxed to allow either a + letter or a digit. Host software MUST support this more liberal + syntax. + + Host software MUST handle host names of up to 63 characters and + SHOULD handle host names of up to 255 characters. + + Whenever a user inputs the identity of an Internet host, it SHOULD + be possible to enter either (1) a host domain name or (2) an IP + address in dotted-decimal ("#.#.#.#") form. The host SHOULD check + the string syntactically for a dotted-decimal number before + looking it up in the Domain Name System. + + DISCUSSION: + This last requirement is not intended to specify the complete + syntactic form for entering a dotted-decimal host number; + that is considered to be a user-interface issue. For + example, a dotted-decimal number must be enclosed within + "[ ]" brackets for SMTP mail (see Section 5.2.17). This + notation could be made universal within a host system, + simplifying the syntactic checking for a dotted-decimal + number. + + If a dotted-decimal number can be entered without such + identifying delimiters, then a full syntactic check must be + made, because a segment of a host domain name is now allowed + to begin with a digit and could legally be entirely numeric + (see Section 6.1.2.4). However, a valid host name can never + have the dotted-decimal form #.#.#.#, since at least the + highest-level component label will be alphabetic. + + 2.2 Using Domain Name Service + + Host domain names MUST be translated to IP addresses as described + in Section 6.1. + + Applications using domain name services MUST be able to cope with + soft error conditions. Applications MUST wait a reasonable + interval between successive retries due to a soft error, and MUST + + + +Internet Engineering Task Force [Page 13] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + allow for the possibility that network problems may deny service + for hours or even days. + + An application SHOULD NOT rely on the ability to locate a WKS + record containing an accurate listing of all services at a + particular host address, since the WKS RR type is not often used + by Internet sites. To confirm that a service is present, simply + attempt to use it. + + 2.3 Applications on Multihomed hosts + + When the remote host is multihomed, the name-to-address + translation will return a list of alternative IP addresses. As + specified in Section 6.1.3.4, this list should be in order of + decreasing preference. Application protocol implementations + SHOULD be prepared to try multiple addresses from the list until + success is obtained. More specific requirements for SMTP are + given in Section 5.3.4. + + When the local host is multihomed, a UDP-based request/response + application SHOULD send the response with an IP source address + that is the same as the specific destination address of the UDP + request datagram. The "specific destination address" is defined + in the "IP Addressing" section of the companion RFC [INTRO:1]. + + Similarly, a server application that opens multiple TCP + connections to the same client SHOULD use the same local IP + address for all. + + 2.4 Type-of-Service + + Applications MUST select appropriate TOS values when they invoke + transport layer services, and these values MUST be configurable. + Note that a TOS value contains 5 bits, of which only the most- + significant 3 bits are currently defined; the other two bits MUST + be zero. + + DISCUSSION: + As gateway algorithms are developed to implement Type-of- + Service, the recommended values for various application + protocols may change. In addition, it is likely that + particular combinations of users and Internet paths will want + non-standard TOS values. For these reasons, the TOS values + must be configurable. + + See the latest version of the "Assigned Numbers" RFC + [INTRO:5] for the recommended TOS values for the major + application protocols. + + + +Internet Engineering Task Force [Page 14] + + + + +RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 + + + 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +User interfaces: | | | | | | | + Allow host name to begin with digit |2.1 |x| | | | | + Host names of up to 635 characters |2.1 |x| | | | | + Host names of up to 255 characters |2.1 | |x| | | | + Support dotted-decimal host numbers |2.1 | |x| | | | + Check syntactically for dotted-dec first |2.1 | |x| | | | + | | | | | | | +Map domain names per Section 6.1 |2.2 |x| | | | | +Cope with soft DNS errors |2.2 |x| | | | | + Reasonable interval between retries |2.2 |x| | | | | + Allow for long outages |2.2 |x| | | | | +Expect WKS records to be available |2.2 | | | |x| | + | | | | | | | +Try multiple addr's for remote multihomed host |2.3 | |x| | | | +UDP reply src addr is specific dest of request |2.3 | |x| | | | +Use same IP addr for related TCP connections |2.3 | |x| | | | +Specify appropriate TOS values |2.4 |x| | | | | + TOS values configurable |2.4 |x| | | | | + Unused TOS bits zero |2.4 |x| | | | | + | | | | | | | + | | | | | | | + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 15] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + +3. REMOTE LOGIN -- TELNET PROTOCOL + + 3.1 INTRODUCTION + + Telnet is the standard Internet application protocol for remote + login. It provides the encoding rules to link a user's + keyboard/display on a client ("user") system with a command + interpreter on a remote server system. A subset of the Telnet + protocol is also incorporated within other application protocols, + e.g., FTP and SMTP. + + Telnet uses a single TCP connection, and its normal data stream + ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with + escape sequences to embed control functions. Telnet also allows + the negotiation of many optional modes and functions. + + The primary Telnet specification is to be found in RFC-854 + [TELNET:1], while the options are defined in many other RFCs; see + Section 7 for references. + + 3.2 PROTOCOL WALK-THROUGH + + 3.2.1 Option Negotiation: RFC-854, pp. 2-3 + + Every Telnet implementation MUST include option negotiation and + subnegotiation machinery [TELNET:2]. + + A host MUST carefully follow the rules of RFC-854 to avoid + option-negotiation loops. A host MUST refuse (i.e, reply + WONT/DONT to a DO/WILL) an unsupported option. Option + negotiation SHOULD continue to function (even if all requests + are refused) throughout the lifetime of a Telnet connection. + + If all option negotiations fail, a Telnet implementation MUST + default to, and support, an NVT. + + DISCUSSION: + Even though more sophisticated "terminals" and supporting + option negotiations are becoming the norm, all + implementations must be prepared to support an NVT for any + user-server communication. + + 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 + + On a host that never sends the Telnet command Go Ahead (GA), + the Telnet Server MUST attempt to negotiate the Suppress Go + Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or + Server Telnet MUST always accept negotiation of the Suppress Go + + + +Internet Engineering Task Force [Page 16] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Ahead option. + + When it is driving a full-duplex terminal for which GA has no + meaning, a User Telnet implementation MAY ignore GA commands. + + DISCUSSION: + Half-duplex ("locked-keyboard") line-at-a-time terminals + for which the Go-Ahead mechanism was designed have largely + disappeared from the scene. It turned out to be difficult + to implement sending the Go-Ahead signal in many operating + systems, even some systems that support native half-duplex + terminals. The difficulty is typically that the Telnet + server code does not have access to information about + whether the user process is blocked awaiting input from + the Telnet connection, i.e., it cannot reliably determine + when to send a GA command. Therefore, most Telnet Server + hosts do not send GA commands. + + The effect of the rules in this section is to allow either + end of a Telnet connection to veto the use of GA commands. + + There is a class of half-duplex terminals that is still + commercially important: "data entry terminals," which + interact in a full-screen manner. However, supporting + data entry terminals using the Telnet protocol does not + require the Go Ahead signal; see Section 3.3.2. + + 3.2.3 Control Functions: RFC-854, pp. 7-8 + + The list of Telnet commands has been extended to include EOR + (End-of-Record), with code 239 [TELNET:9]. + + Both User and Server Telnets MAY support the control functions + EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, + SB, and SE. + + A host MUST be able to receive and ignore any Telnet control + functions that it does not support. + + DISCUSSION: + Note that a Server Telnet is required to support the + Telnet IP (Interrupt Process) function, even if the server + host has an equivalent in-stream function (e.g., Control-C + in many systems). The Telnet IP function may be stronger + than an in-stream interrupt command, because of the out- + of-band effect of TCP urgent data. + + The EOR control function may be used to delimit the + + + +Internet Engineering Task Force [Page 17] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + stream. An important application is data entry terminal + support (see Section 3.3.2). There was concern that since + EOR had not been defined in RFC-854, a host that was not + prepared to correctly ignore unknown Telnet commands might + crash if it received an EOR. To protect such hosts, the + End-of-Record option [TELNET:9] was introduced; however, a + properly implemented Telnet program will not require this + protection. + + 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 + + When it receives "urgent" TCP data, a User or Server Telnet + MUST discard all data except Telnet commands until the DM (and + end of urgent) is reached. + + When it sends Telnet IP (Interrupt Process), a User Telnet + SHOULD follow it by the Telnet "Synch" sequence, i.e., send as + TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent + pointer points to the DM octet. + + When it receives a Telnet IP command, a Server Telnet MAY send + a Telnet "Synch" sequence back to the user, to flush the output + stream. The choice ought to be consistent with the way the + server operating system behaves when a local user interrupts a + process. + + When it receives a Telnet AO command, a Server Telnet MUST send + a Telnet "Synch" sequence back to the user, to flush the output + stream. + + A User Telnet SHOULD have the capability of flushing output + when it sends a Telnet IP; see also Section 3.4.5. + + DISCUSSION: + There are three possible ways for a User Telnet to flush + the stream of server output data: + + (1) Send AO after IP. + + This will cause the server host to send a "flush- + buffered-output" signal to its operating system. + However, the AO may not take effect locally, i.e., + stop terminal output at the User Telnet end, until + the Server Telnet has received and processed the AO + and has sent back a "Synch". + + (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard + all output locally until a WILL/WONT TIMING-MARK is + + + +Internet Engineering Task Force [Page 18] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + received from the Server Telnet. + + Since the DO TIMING-MARK will be processed after the + IP at the server, the reply to it should be in the + right place in the output data stream. However, the + TIMING-MARK will not send a "flush buffered output" + signal to the server operating system. Whether or + not this is needed is dependent upon the server + system. + + (3) Do both. + + The best method is not entirely clear, since it must + accommodate a number of existing server hosts that do not + follow the Telnet standards in various ways. The safest + approach is probably to provide a user-controllable option + to select (1), (2), or (3). + + 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 + + In NVT mode, a Telnet SHOULD NOT send characters with the + high-order bit 1, and MUST NOT send it as a parity bit. + Implementations that pass the high-order bit to applications + SHOULD negotiate binary mode (see Section 3.2.6). + + + DISCUSSION: + Implementors should be aware that a strict reading of + RFC-854 allows a client or server expecting NVT ASCII to + ignore characters with the high-order bit set. In + general, binary mode is expected to be used for + transmission of an extended (beyond 7-bit) character set + with Telnet. + + However, there exist applications that really need an 8- + bit NVT mode, which is currently not defined, and these + existing applications do set the high-order bit during + part or all of the life of a Telnet connection. Note that + binary mode is not the same as 8-bit NVT mode, since + binary mode turns off end-of-line processing. For this + reason, the requirements on the high-order bit are stated + as SHOULD, not MUST. + + RFC-854 defines a minimal set of properties of a "network + virtual terminal" or NVT; this is not meant to preclude + additional features in a real terminal. A Telnet + connection is fully transparent to all 7-bit ASCII + characters, including arbitrary ASCII control characters. + + + +Internet Engineering Task Force [Page 19] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + For example, a terminal might support full-screen commands + coded as ASCII escape sequences; a Telnet implementation + would pass these sequences as uninterpreted data. Thus, + an NVT should not be conceived as a terminal type of a + highly-restricted device. + + 3.2.6 Telnet Command Structure: RFC-854, p. 13 + + Since options may appear at any point in the data stream, a + Telnet escape character (known as IAC, with the value 255) to + be sent as data MUST be doubled. + + 3.2.7 Telnet Binary Option: RFC-856 + + When the Binary option has been successfully negotiated, + arbitrary 8-bit characters are allowed. However, the data + stream MUST still be scanned for IAC characters, any embedded + Telnet commands MUST be obeyed, and data bytes equal to IAC + MUST be doubled. Other character processing (e.g., replacing + CR by CR NUL or by CR LF) MUST NOT be done. In particular, + there is no end-of-line convention (see Section 3.3.1) in + binary mode. + + DISCUSSION: + The Binary option is normally negotiated in both + directions, to change the Telnet connection from NVT mode + to "binary mode". + + The sequence IAC EOR can be used to delimit blocks of data + within a binary-mode Telnet stream. + + 3.2.8 Telnet Terminal-Type Option: RFC-1091 + + The Terminal-Type option MUST use the terminal type names + officially defined in the Assigned Numbers RFC [INTRO:5], when + they are available for the particular terminal. However, the + receiver of a Terminal-Type option MUST accept any name. + + DISCUSSION: + RFC-1091 [TELNET:10] updates an earlier version of the + Terminal-Type option defined in RFC-930. The earlier + version allowed a server host capable of supporting + multiple terminal types to learn the type of a particular + client's terminal, assuming that each physical terminal + had an intrinsic type. However, today a "terminal" is + often really a terminal emulator program running in a PC, + perhaps capable of emulating a range of terminal types. + Therefore, RFC-1091 extends the specification to allow a + + + +Internet Engineering Task Force [Page 20] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + more general terminal-type negotiation between User and + Server Telnets. + + 3.3 SPECIFIC ISSUES + + 3.3.1 Telnet End-of-Line Convention + + The Telnet protocol defines the sequence CR LF to mean "end- + of-line". For terminal input, this corresponds to a command- + completion or "end-of-line" key being pressed on a user + terminal; on an ASCII terminal, this is the CR key, but it may + also be labelled "Return" or "Enter". + + When a Server Telnet receives the Telnet end-of-line sequence + CR LF as input from a remote terminal, the effect MUST be the + same as if the user had pressed the "end-of-line" key on a + local terminal. On server hosts that use ASCII, in particular, + receipt of the Telnet sequence CR LF must cause the same effect + as a local user pressing the CR key on a local terminal. Thus, + CR LF and CR NUL MUST have the same effect on an ASCII server + host when received as input over a Telnet connection. + + A User Telnet MUST be able to send any of the forms: CR LF, CR + NUL, and LF. A User Telnet on an ASCII host SHOULD have a + user-controllable mode to send either CR LF or CR NUL when the + user presses the "end-of-line" key, and CR LF SHOULD be the + default. + + The Telnet end-of-line sequence CR LF MUST be used to send + Telnet data that is not terminal-to-computer (e.g., for Server + Telnet sending output, or the Telnet protocol incorporated + another application protocol). + + DISCUSSION: + To allow interoperability between arbitrary Telnet clients + and servers, the Telnet protocol defined a standard + representation for a line terminator. Since the ASCII + character set includes no explicit end-of-line character, + systems have chosen various representations, e.g., CR, LF, + and the sequence CR LF. The Telnet protocol chose the CR + LF sequence as the standard for network transmission. + + Unfortunately, the Telnet protocol specification in RFC- + 854 [TELNET:1] has turned out to be somewhat ambiguous on + what character(s) should be sent from client to server for + the "end-of-line" key. The result has been a massive and + continuing interoperability headache, made worse by + various faulty implementations of both User and Server + + + +Internet Engineering Task Force [Page 21] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Telnets. + + Although the Telnet protocol is based on a perfectly + symmetric model, in a remote login session the role of the + user at a terminal differs from the role of the server + host. For example, RFC-854 defines the meaning of CR, LF, + and CR LF as output from the server, but does not specify + what the User Telnet should send when the user presses the + "end-of-line" key on the terminal; this turns out to be + the point at issue. + + When a user presses the "end-of-line" key, some User + Telnet implementations send CR LF, while others send CR + NUL (based on a different interpretation of the same + sentence in RFC-854). These will be equivalent for a + correctly-implemented ASCII server host, as discussed + above. For other servers, a mode in the User Telnet is + needed. + + The existence of User Telnets that send only CR NUL when + CR is pressed creates a dilemma for non-ASCII hosts: they + can either treat CR NUL as equivalent to CR LF in input, + thus precluding the possibility of entering a "bare" CR, + or else lose complete interworking. + + Suppose a user on host A uses Telnet to log into a server + host B, and then execute B's User Telnet program to log + into server host C. It is desirable for the Server/User + Telnet combination on B to be as transparent as possible, + i.e., to appear as if A were connected directly to C. In + particular, correct implementation will make B transparent + to Telnet end-of-line sequences, except that CR LF may be + translated to CR NUL or vice versa. + + IMPLEMENTATION: + To understand Telnet end-of-line issues, one must have at + least a general model of the relationship of Telnet to the + local operating system. The Server Telnet process is + typically coupled into the terminal driver software of the + operating system as a pseudo-terminal. A Telnet end-of- + line sequence received by the Server Telnet must have the + same effect as pressing the end-of-line key on a real + locally-connected terminal. + + Operating systems that support interactive character-at- + a-time applications (e.g., editors) typically have two + internal modes for their terminal I/O: a formatted mode, + in which local conventions for end-of-line and other + + + +Internet Engineering Task Force [Page 22] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + formatting rules have been applied to the data stream, and + a "raw" mode, in which the application has direct access + to every character as it was entered. A Server Telnet + must be implemented in such a way that these modes have + the same effect for remote as for local terminals. For + example, suppose a CR LF or CR NUL is received by the + Server Telnet on an ASCII host. In raw mode, a CR + character is passed to the application; in formatted mode, + the local system's end-of-line convention is used. + + 3.3.2 Data Entry Terminals + + DISCUSSION: + In addition to the line-oriented and character-oriented + ASCII terminals for which Telnet was designed, there are + several families of video display terminals that are + sometimes known as "data entry terminals" or DETs. The + IBM 3270 family is a well-known example. + + Two Internet protocols have been designed to support + generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET + option [TELNET:18, TELNET:19]. The DET option drives a + data entry terminal over a Telnet connection using (sub-) + negotiation. SUPDUP is a completely separate terminal + protocol, which can be entered from Telnet by negotiation. + Although both SUPDUP and the DET option have been used + successfully in particular environments, neither has + gained general acceptance or wide implementation. + + A different approach to DET interaction has been developed + for supporting the IBM 3270 family through Telnet, + although the same approach would be applicable to any DET. + The idea is to enter a "native DET" mode, in which the + native DET input/output stream is sent as binary data. + The Telnet EOR command is used to delimit logical records + (e.g., "screens") within this binary stream. + + IMPLEMENTATION: + The rules for entering and leaving native DET mode are as + follows: + + o The Server uses the Terminal-Type option [TELNET:10] + to learn that the client is a DET. + + o It is conventional, but not required, that both ends + negotiate the EOR option [TELNET:9]. + + o Both ends negotiate the Binary option [TELNET:3] to + + + +Internet Engineering Task Force [Page 23] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + enter native DET mode. + + o When either end negotiates out of binary mode, the + other end does too, and the mode then reverts to + normal NVT. + + + 3.3.3 Option Requirements + + Every Telnet implementation MUST support the Binary option + [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and + SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- + Record [TELNET:9], and Extended Options List [TELNET:8] + options. + + A User or Server Telnet SHOULD support the Window Size Option + [TELNET:12] if the local operating system provides the + corresponding capability. + + DISCUSSION: + Note that the End-of-Record option only signifies that a + Telnet can receive a Telnet EOR without crashing; + therefore, every Telnet ought to be willing to accept + negotiation of the End-of-Record option. See also the + discussion in Section 3.2.3. + + 3.3.4 Option Initiation + + When the Telnet protocol is used in a client/server situation, + the server SHOULD initiate negotiation of the terminal + interaction mode it expects. + + DISCUSSION: + The Telnet protocol was defined to be perfectly + symmetrical, but its application is generally asymmetric. + Remote login has been known to fail because NEITHER side + initiated negotiation of the required non-default terminal + modes. It is generally the server that determines the + preferred mode, so the server needs to initiate the + negotiation; since the negotiation is symmetric, the user + can also initiate it. + + A client (User Telnet) SHOULD provide a means for users to + enable and disable the initiation of option negotiation. + + DISCUSSION: + A user sometimes needs to connect to an application + service (e.g., FTP or SMTP) that uses Telnet for its + + + +Internet Engineering Task Force [Page 24] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + control stream but does not support Telnet options. User + Telnet may be used for this purpose if initiation of + option negotiation is disabled. + + 3.3.5 Telnet Linemode Option + + DISCUSSION: + An important new Telnet option, LINEMODE [TELNET:12], has + been proposed. The LINEMODE option provides a standard + way for a User Telnet and a Server Telnet to agree that + the client rather than the server will perform terminal + character processing. When the client has prepared a + complete line of text, it will send it to the server in + (usually) one TCP packet. This option will greatly + decrease the packet cost of Telnet sessions and will also + give much better user response over congested or long- + delay networks. + + The LINEMODE option allows dynamic switching between local + and remote character processing. For example, the Telnet + connection will automatically negotiate into single- + character mode while a full screen editor is running, and + then return to linemode when the editor is finished. + + We expect that when this RFC is released, hosts should + implement the client side of this option, and may + implement the server side of this option. To properly + implement the server side, the server needs to be able to + tell the local system not to do any input character + processing, but to remember its current terminal state and + notify the Server Telnet process whenever the state + changes. This will allow password echoing and full screen + editors to be handled properly, for example. + + 3.4 TELNET/USER INTERFACE + + 3.4.1 Character Set Transparency + + User Telnet implementations SHOULD be able to send or receive + any 7-bit ASCII character. Where possible, any special + character interpretations by the user host's operating system + SHOULD be bypassed so that these characters can conveniently be + sent and received on the connection. + + Some character value MUST be reserved as "escape to command + mode"; conventionally, doubling this character allows it to be + entered as data. The specific character used SHOULD be user + selectable. + + + +Internet Engineering Task Force [Page 25] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + On binary-mode connections, a User Telnet program MAY provide + an escape mechanism for entering arbitrary 8-bit values, if the + host operating system doesn't allow them to be entered directly + from the keyboard. + + IMPLEMENTATION: + The transparency issues are less pressing on servers, but + implementors should take care in dealing with issues like: + masking off parity bits (sent by an older, non-conforming + client) before they reach programs that expect only NVT + ASCII, and properly handling programs that request 8-bit + data streams. + + 3.4.2 Telnet Commands + + A User Telnet program MUST provide a user the capability of + entering any of the Telnet control functions IP, AO, or AYT, + and SHOULD provide the capability of entering EC, EL, and + Break. + + 3.4.3 TCP Connection Errors + + A User Telnet program SHOULD report to the user any TCP errors + that are reported by the transport layer (see "TCP/Application + Layer Interface" section in [INTRO:1]). + + 3.4.4 Non-Default Telnet Contact Port + + A User Telnet program SHOULD allow the user to optionally + specify a non-standard contact port number at the Server Telnet + host. + + 3.4.5 Flushing Output + + A User Telnet program SHOULD provide the user the ability to + specify whether or not output should be flushed when an IP is + sent; see Section 3.2.4. + + For any output flushing scheme that causes the User Telnet to + flush output locally until a Telnet signal is received from the + Server, there SHOULD be a way for the user to manually restore + normal output, in case the Server fails to send the expected + signal. + + + + + + + + +Internet Engineering Task Force [Page 26] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + 3.5. TELNET REQUIREMENTS SUMMARY + + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- + | | | | | | | +Option Negotiation |3.2.1 |x| | | | | + Avoid negotiation loops |3.2.1 |x| | | | | + Refuse unsupported options |3.2.1 |x| | | | | + Negotiation OK anytime on connection |3.2.1 | |x| | | | + Default to NVT |3.2.1 |x| | | | | + Send official name in Term-Type option |3.2.8 |x| | | | | + Accept any name in Term-Type option |3.2.8 |x| | | | | + Implement Binary, Suppress-GA options |3.3.3 |x| | | | | + Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | + Implement Window-Size option if appropriate |3.3.3 | |x| | | | + Server initiate mode negotiations |3.3.4 | |x| | | | + User can enable/disable init negotiations |3.3.4 | |x| | | | + | | | | | | | +Go-Aheads | | | | | | | + Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | + User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | + User Telnet ignore GA's |3.2.2 | | |x| | | + | | | | | | | +Control Functions | | | | | | | + Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | + Support EOR EC EL Break |3.2.3 | | |x| | | + Ignore unsupported control functions |3.2.3 |x| | | | | + User, Server discard urgent data up to DM |3.2.4 |x| | | | | + User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | + Server Telnet reply Synch to IP |3.2.4 | | |x| | | + Server Telnet reply Synch to AO |3.2.4 |x| | | | | + User Telnet can flush output when send IP |3.2.4 | |x| | | | + | | | | | | | +Encoding | | | | | | | + Send high-order bit in NVT mode |3.2.5 | | | |x| | + Send high-order bit as parity bit |3.2.5 | | | | |x| + Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | + Always double IAC data byte |3.2.6 |x| | | | | + + + +Internet Engineering Task Force [Page 27] + + + + +RFC1123 REMOTE LOGIN -- TELNET October 1989 + + + Double IAC data byte in binary mode |3.2.7 |x| | | | | + Obey Telnet cmds in binary mode |3.2.7 |x| | | | | + End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| + | | | | | | | +End-of-Line | | | | | | | + EOL at Server same as local end-of-line |3.3.1 |x| | | | | + ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | + User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | + ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | + User Telnet default mode is CR LF |3.3.1 | |x| | | | + Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | + | | | | | | | +User Telnet interface | | | | | | | + Input & output all 7-bit characters |3.4.1 | |x| | | | + Bypass local op sys interpretation |3.4.1 | |x| | | | + Escape character |3.4.1 |x| | | | | + User-settable escape character |3.4.1 | |x| | | | + Escape to enter 8-bit values |3.4.1 | | |x| | | + Can input IP, AO, AYT |3.4.2 |x| | | | | + Can input EC, EL, Break |3.4.2 | |x| | | | + Report TCP connection errors to user |3.4.3 | |x| | | | + Optional non-default contact port |3.4.4 | |x| | | | + Can spec: output flushed when IP sent |3.4.5 | |x| | | | + Can manually restore output mode |3.4.5 | |x| | | | + | | | | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 28] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +4. FILE TRANSFER + + 4.1 FILE TRANSFER PROTOCOL -- FTP + + 4.1.1 INTRODUCTION + + The File Transfer Protocol FTP is the primary Internet standard + for file transfer. The current specification is contained in + RFC-959 [FTP:1]. + + FTP uses separate simultaneous TCP connections for control and + for data transfer. The FTP protocol includes many features, + some of which are not commonly implemented. However, for every + feature in FTP, there exists at least one implementation. The + minimum implementation defined in RFC-959 was too small, so a + somewhat larger minimum implementation is defined here. + + Internet users have been unnecessarily burdened for years by + deficient FTP implementations. Protocol implementors have + suffered from the erroneous opinion that implementing FTP ought + to be a small and trivial task. This is wrong, because FTP has + a user interface, because it has to deal (correctly) with the + whole variety of communication and operating system errors that + may occur, and because it has to handle the great diversity of + real file systems in the world. + + 4.1.2. PROTOCOL WALK-THROUGH + + 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 + + An FTP program MUST support TYPE I ("IMAGE" or binary type) + as well as TYPE L 8 ("LOCAL" type with logical byte size 8). + A machine whose memory is organized into m-bit words, where + m is not a multiple of 8, MAY also support TYPE L m. + + DISCUSSION: + The command "TYPE L 8" is often required to transfer + binary data between a machine whose memory is organized + into (e.g.) 36-bit words and a machine with an 8-bit + byte organization. For an 8-bit byte machine, TYPE L 8 + is equivalent to IMAGE. + + "TYPE L m" is sometimes specified to the FTP programs + on two m-bit word machines to ensure the correct + transfer of a native-mode binary file from one machine + to the other. However, this command should have the + same effect on these machines as "TYPE I". + + + + +Internet Engineering Task Force [Page 29] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 + + A host that makes no distinction between TYPE N and TYPE T + SHOULD implement TYPE T to be identical to TYPE N. + + DISCUSSION: + This provision should ease interoperation with hosts + that do make this distinction. + + Many hosts represent text files internally as strings + of ASCII characters, using the embedded ASCII format + effector characters (LF, BS, FF, ...) to control the + format when a file is printed. For such hosts, there + is no distinction between "print" files and other + files. However, systems that use record structured + files typically need a special format for printable + files (e.g., ASA carriage control). For the latter + hosts, FTP allows a choice of TYPE N or TYPE T. + + 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I + + Implementation of page structure is NOT RECOMMENDED in + general. However, if a host system does need to implement + FTP for "random access" or "holey" files, it MUST use the + defined page structure format rather than define a new + private FTP format. + + 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 + + An FTP transformation between record-structure and file- + structure SHOULD be invertible, to the extent possible while + making the result useful on the target host. + + DISCUSSION: + RFC-959 required strict invertibility between record- + structure and file-structure, but in practice, + efficiency and convenience often preclude it. + Therefore, the requirement is being relaxed. There are + two different objectives for transferring a file: + processing it on the target host, or just storage. For + storage, strict invertibility is important. For + processing, the file created on the target host needs + to be in the format expected by application programs on + that host. + + As an example of the conflict, imagine a record- + oriented operating system that requires some data files + to have exactly 80 bytes in each record. While STORing + + + +Internet Engineering Task Force [Page 30] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + a file on such a host, an FTP Server must be able to + pad each line or record to 80 bytes; a later retrieval + of such a file cannot be strictly invertible. + + 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 + + A User-FTP that uses STREAM mode SHOULD send a PORT command + to assign a non-default data port before each transfer + command is issued. + + DISCUSSION: + This is required because of the long delay after a TCP + connection is closed until its socket pair can be + reused, to allow multiple transfers during a single FTP + session. Sending a port command can avoided if a + transfer mode other than stream is used, by leaving the + data transfer connection open between transfers. + + 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 + + A server-FTP MUST implement the PASV command. + + If multiple third-party transfers are to be executed during + the same session, a new PASV command MUST be issued before + each transfer command, to obtain a unique port pair. + + IMPLEMENTATION: + The format of the 227 reply to a PASV command is not + well standardized. In particular, an FTP client cannot + assume that the parentheses shown on page 40 of RFC-959 + will be present (and in fact, Figure 3 on page 43 omits + them). Therefore, a User-FTP program that interprets + the PASV reply must scan the reply for the first digit + of the host and port numbers. + + Note that the host number h1,h2,h3,h4 is the IP address + of the server host that is sending the reply, and that + p1,p2 is a non-default data transfer port that PASV has + assigned. + + 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 + + The data returned by an NLST command MUST contain only a + simple list of legal pathnames, such that the server can use + them directly as the arguments of subsequent data transfer + commands for the individual files. + + The data returned by a LIST or NLST command SHOULD use an + + + +Internet Engineering Task Force [Page 31] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + implied TYPE AN, unless the current type is EBCDIC, in which + case an implied TYPE EN SHOULD be used. + + DISCUSSION: + Many FTP clients support macro-commands that will get + or put files matching a wildcard specification, using + NLST to obtain a list of pathnames. The expansion of + "multiple-put" is local to the client, but "multiple- + get" requires cooperation by the server. + + The implied type for LIST and NLST is designed to + provide compatibility with existing User-FTPs, and in + particular with multiple-get commands. + + 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 + + A Server-FTP SHOULD use the SITE command for non-standard + features, rather than invent new private commands or + unstandardized extensions to existing commands. + + 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 + + The STOU command stores into a uniquely named file. When it + receives an STOU command, a Server-FTP MUST return the + actual file name in the "125 Transfer Starting" or the "150 + Opening Data Connection" message that precedes the transfer + (the 250 reply code mentioned in RFC-959 is incorrect). The + exact format of these messages is hereby defined to be as + follows: + + 125 FILE: pppp + 150 FILE: pppp + + where pppp represents the unique pathname of the file that + will be written. + + 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 + + Implementors MUST NOT assume any correspondence between READ + boundaries on the control connection and the Telnet EOL + sequences (CR LF). + + DISCUSSION: + Thus, a server-FTP (or User-FTP) must continue reading + characters from the control connection until a complete + Telnet EOL sequence is encountered, before processing + the command (or response, respectively). Conversely, a + single READ from the control connection may include + + + +Internet Engineering Task Force [Page 32] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + more than one FTP command. + + 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 + + A Server-FTP MUST send only correctly formatted replies on + the control connection. Note that RFC-959 (unlike earlier + versions of the FTP spec) contains no provision for a + "spontaneous" reply message. + + A Server-FTP SHOULD use the reply codes defined in RFC-959 + whenever they apply. However, a server-FTP MAY use a + different reply code when needed, as long as the general + rules of Section 4.2 are followed. When the implementor has + a choice between a 4xx and 5xx reply code, a Server-FTP + SHOULD send a 4xx (temporary failure) code when there is any + reasonable possibility that a failed FTP will succeed a few + hours later. + + A User-FTP SHOULD generally use only the highest-order digit + of a 3-digit reply code for making a procedural decision, to + prevent difficulties when a Server-FTP uses non-standard + reply codes. + + A User-FTP MUST be able to handle multi-line replies. If + the implementation imposes a limit on the number of lines + and if this limit is exceeded, the User-FTP MUST recover, + e.g., by ignoring the excess lines until the end of the + multi-line reply is reached. + + A User-FTP SHOULD NOT interpret a 421 reply code ("Service + not available, closing control connection") specially, but + SHOULD detect closing of the control connection by the + server. + + DISCUSSION: + Server implementations that fail to strictly follow the + reply rules often cause FTP user programs to hang. + Note that RFC-959 resolved ambiguities in the reply + rules found in earlier FTP specifications and must be + followed. + + It is important to choose FTP reply codes that properly + distinguish between temporary and permanent failures, + to allow the successful use of file transfer client + daemons. These programs depend on the reply codes to + decide whether or not to retry a failed transfer; using + a permanent failure code (5xx) for a temporary error + will cause these programs to give up unnecessarily. + + + +Internet Engineering Task Force [Page 33] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + When the meaning of a reply matches exactly the text + shown in RFC-959, uniformity will be enhanced by using + the RFC-959 text verbatim. However, a Server-FTP + implementor is encouraged to choose reply text that + conveys specific system-dependent information, when + appropriate. + + 4.1.2.12 Connections: RFC-959 Section 5.2 + + The words "and the port used" in the second paragraph of + this section of RFC-959 are erroneous (historical), and they + should be ignored. + + On a multihomed server host, the default data transfer port + (L-1) MUST be associated with the same local IP address as + the corresponding control connection to port L. + + A user-FTP MUST NOT send any Telnet controls other than + SYNCH and IP on an FTP control connection. In particular, it + MUST NOT attempt to negotiate Telnet options on the control + connection. However, a server-FTP MUST be capable of + accepting and refusing Telnet negotiations (i.e., sending + DONT/WONT). + + DISCUSSION: + Although the RFC says: "Server- and User- processes + should follow the conventions for the Telnet + protocol...[on the control connection]", it is not the + intent that Telnet option negotiation is to be + employed. + + 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 + + The following commands and options MUST be supported by + every server-FTP and user-FTP, except in cases where the + underlying file system or operating system does not allow or + support a particular command. + + Type: ASCII Non-print, IMAGE, LOCAL 8 + Mode: Stream + Structure: File, Record* + Commands: + USER, PASS, ACCT, + PORT, PASV, + TYPE, MODE, STRU, + RETR, STOR, APPE, + RNFR, RNTO, DELE, + CWD, CDUP, RMD, MKD, PWD, + + + +Internet Engineering Task Force [Page 34] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LIST, NLST, + SYST, STAT, + HELP, NOOP, QUIT. + + *Record structure is REQUIRED only for hosts whose file + systems support record structure. + + DISCUSSION: + Vendors are encouraged to implement a larger subset of + the protocol. For example, there are important + robustness features in the protocol (e.g., Restart, + ABOR, block mode) that would be an aid to some Internet + users but are not widely implemented. + + A host that does not have record structures in its file + system may still accept files with STRU R, recording + the byte stream literally. + + 4.1.3 SPECIFIC ISSUES + + 4.1.3.1 Non-standard Command Verbs + + FTP allows "experimental" commands, whose names begin with + "X". If these commands are subsequently adopted as + standards, there may still be existing implementations using + the "X" form. At present, this is true for the directory + commands: + + RFC-959 "Experimental" + + MKD XMKD + RMD XRMD + PWD XPWD + CDUP XCUP + CWD XCWD + + All FTP implementations SHOULD recognize both forms of these + commands, by simply equating them with extra entries in the + command lookup table. + + IMPLEMENTATION: + A User-FTP can access a server that supports only the + "X" forms by implementing a mode switch, or + automatically using the following procedure: if the + RFC-959 form of one of the above commands is rejected + with a 500 or 502 response code, then try the + experimental form; any other response would be passed + to the user. + + + +Internet Engineering Task Force [Page 35] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.3.2 Idle Timeout + + A Server-FTP process SHOULD have an idle timeout, which will + terminate the process and close the control connection if + the server is inactive (i.e., no command or data transfer in + progress) for a long period of time. The idle timeout time + SHOULD be configurable, and the default should be at least 5 + minutes. + + A client FTP process ("User-PI" in RFC-959) will need + timeouts on responses only if it is invoked from a program. + + DISCUSSION: + Without a timeout, a Server-FTP process may be left + pending indefinitely if the corresponding client + crashes without closing the control connection. + + 4.1.3.3 Concurrency of Data and Control + + DISCUSSION: + The intent of the designers of FTP was that a user + should be able to send a STAT command at any time while + data transfer was in progress and that the server-FTP + would reply immediately with status -- e.g., the number + of bytes transferred so far. Similarly, an ABOR + command should be possible at any time during a data + transfer. + + Unfortunately, some small-machine operating systems + make such concurrent programming difficult, and some + other implementers seek minimal solutions, so some FTP + implementations do not allow concurrent use of the data + and control connections. Even such a minimal server + must be prepared to accept and defer a STAT or ABOR + command that arrives during data transfer. + + 4.1.3.4 FTP Restart Mechanism + + The description of the 110 reply on pp. 40-41 of RFC-959 is + incorrect; the correct description is as follows. A restart + reply message, sent over the control connection from the + receiving FTP to the User-FTP, has the format: + + 110 MARK ssss = rrrr + + Here: + + * ssss is a text string that appeared in a Restart Marker + + + +Internet Engineering Task Force [Page 36] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + in the data stream and encodes a position in the + sender's file system; + + * rrrr encodes the corresponding position in the + receiver's file system. + + The encoding, which is specific to a particular file system + and network implementation, is always generated and + interpreted by the same system, either sender or receiver. + + When an FTP that implements restart receives a Restart + Marker in the data stream, it SHOULD force the data to that + point to be written to stable storage before encoding the + corresponding position rrrr. An FTP sending Restart Markers + MUST NOT assume that 110 replies will be returned + synchronously with the data, i.e., it must not await a 110 + reply before sending more data. + + Two new reply codes are hereby defined for errors + encountered in restarting a transfer: + + 554 Requested action not taken: invalid REST parameter. + + A 554 reply may result from a FTP service command that + follows a REST command. The reply indicates that the + existing file at the Server-FTP cannot be repositioned + as specified in the REST. + + 555 Requested action not taken: type or stru mismatch. + + A 555 reply may result from an APPE command or from any + FTP service command following a REST command. The + reply indicates that there is some mismatch between the + current transfer parameters (type and stru) and the + attributes of the existing file. + + DISCUSSION: + Note that the FTP Restart mechanism requires that Block + or Compressed mode be used for data transfer, to allow + the Restart Markers to be included within the data + stream. The frequency of Restart Markers can be low. + + Restart Markers mark a place in the data stream, but + the receiver may be performing some transformation on + the data as it is stored into stable storage. In + general, the receiver's encoding must include any state + information necessary to restart this transformation at + any point of the FTP data stream. For example, in TYPE + + + +Internet Engineering Task Force [Page 37] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + A transfers, some receiver hosts transform CR LF + sequences into a single LF character on disk. If a + Restart Marker happens to fall between CR and LF, the + receiver must encode in rrrr that the transfer must be + restarted in a "CR has been seen and discarded" state. + + Note that the Restart Marker is required to be encoded + as a string of printable ASCII characters, regardless + of the type of the data. + + RFC-959 says that restart information is to be returned + "to the user". This should not be taken literally. In + general, the User-FTP should save the restart + information (ssss,rrrr) in stable storage, e.g., append + it to a restart control file. An empty restart control + file should be created when the transfer first starts + and deleted automatically when the transfer completes + successfully. It is suggested that this file have a + name derived in an easily-identifiable manner from the + name of the file being transferred and the remote host + name; this is analogous to the means used by many text + editors for naming "backup" files. + + There are three cases for FTP restart. + + (1) User-to-Server Transfer + + The User-FTP puts Restart Markers <ssss> at + convenient places in the data stream. When the + Server-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + transformation state as rrrr, and returns a "110 + MARK ssss = rrrr" reply over the control + connection. The User-FTP appends the pair + (ssss,rrrr) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, repositions its local file system and + transformation state using ssss, and sends the + command "REST rrrr" to the Server-FTP. + + (2) Server-to-User Transfer + + The Server-FTP puts Restart Markers <ssss> at + convenient places in the data stream. When the + User-FTP receives a Marker, it writes all prior + data to disk, encodes its file system position and + + + +Internet Engineering Task Force [Page 38] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + transformation state as rrrr, and appends the pair + (rrrr,ssss) to its restart control file. + + To restart the transfer, the User-FTP fetches the + last (rrrr,ssss) pair from the restart control + file, repositions its local file system and + transformation state using rrrr, and sends the + command "REST ssss" to the Server-FTP. + + (3) Server-to-Server ("Third-Party") Transfer + + The sending Server-FTP puts Restart Markers <ssss> + at convenient places in the data stream. When it + receives a Marker, the receiving Server-FTP writes + all prior data to disk, encodes its file system + position and transformation state as rrrr, and + sends a "110 MARK ssss = rrrr" reply over the + control connection to the User. The User-FTP + appends the pair (ssss,rrrr) to its restart + control file. + + To restart the transfer, the User-FTP fetches the + last (ssss,rrrr) pair from the restart control + file, sends "REST ssss" to the sending Server-FTP, + and sends "REST rrrr" to the receiving Server-FTP. + + + 4.1.4 FTP/USER INTERFACE + + This section discusses the user interface for a User-FTP + program. + + 4.1.4.1 Pathname Specification + + Since FTP is intended for use in a heterogeneous + environment, User-FTP implementations MUST support remote + pathnames as arbitrary character strings, so that their form + and content are not limited by the conventions of the local + operating system. + + DISCUSSION: + In particular, remote pathnames can be of arbitrary + length, and all the printing ASCII characters as well + as space (0x20) must be allowed. RFC-959 allows a + pathname to contain any 7-bit ASCII character except CR + or LF. + + + + + +Internet Engineering Task Force [Page 39] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.4.2 "QUOTE" Command + + A User-FTP program MUST implement a "QUOTE" command that + will pass an arbitrary character string to the server and + display all resulting response messages to the user. + + To make the "QUOTE" command useful, a User-FTP SHOULD send + transfer control commands to the server as the user enters + them, rather than saving all the commands and sending them + to the server only when a data transfer is started. + + DISCUSSION: + The "QUOTE" command is essential to allow the user to + access servers that require system-specific commands + (e.g., SITE or ALLO), or to invoke new or optional + features that are not implemented by the User-FTP. For + example, "QUOTE" may be used to specify "TYPE A T" to + send a print file to hosts that require the + distinction, even if the User-FTP does not recognize + that TYPE. + + 4.1.4.3 Displaying Replies to User + + A User-FTP SHOULD display to the user the full text of all + error reply messages it receives. It SHOULD have a + "verbose" mode in which all commands it sends and the full + text and reply codes it receives are displayed, for + diagnosis of problems. + + 4.1.4.4 Maintaining Synchronization + + The state machine in a User-FTP SHOULD be forgiving of + missing and unexpected reply messages, in order to maintain + command synchronization with the server. + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 40] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + 4.1.5 FTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------|---------------|-|-|-|-|-|-- +Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | +File/Record transform invertible if poss. |4.1.2.4 | |x| | | | +User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | +Server-FTP implement PASV |4.1.2.6 |x| | | | | + PASV is per-transfer |4.1.2.6 |x| | | | | +NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | +Implied type for LIST and NLST |4.1.2.7 | |x| | | | +SITE cmd for non-standard features |4.1.2.8 | |x| | | | +STOU cmd return pathname as specified |4.1.2.9 |x| | | | | +Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| + | | | | | | | +Server-FTP send only correct reply format |4.1.2.11 |x| | | | | +Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | + New reply code following Section 4.2 |4.1.2.11 | | |x| | | +User-FTP use only high digit of reply |4.1.2.11 | |x| | | | +User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | +User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | + | | | | | | | +Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | +User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| +User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| +Server-FTP handle Telnet options |4.1.2.12 |x| | | | | +Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | +Idle timeout in server-FTP |4.1.3.2 | |x| | | | + Configurable idle timeout |4.1.3.2 | |x| | | | +Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | +Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| + | | | | | | | +Support TYPE: | | | | | | | + ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | + ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | + ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | + EBCDIC - (any form) |959 3.1.1.2 | | |x| | | + IMAGE |4.1.2.1 |x| | | | | + LOCAL 8 |4.1.2.1 |x| | | | | + + + +Internet Engineering Task Force [Page 41] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + + LOCAL m |4.1.2.1 | | |x| | |2 + | | | | | | | +Support MODE: | | | | | | | + Stream |4.1.2.13 |x| | | | | + Block |959 3.4.2 | | |x| | | + | | | | | | | +Support STRUCTURE: | | | | | | | + File |4.1.2.13 |x| | | | | + Record |4.1.2.13 |x| | | | |3 + Page |4.1.2.3 | | | |x| | + | | | | | | | +Support commands: | | | | | | | + USER |4.1.2.13 |x| | | | | + PASS |4.1.2.13 |x| | | | | + ACCT |4.1.2.13 |x| | | | | + CWD |4.1.2.13 |x| | | | | + CDUP |4.1.2.13 |x| | | | | + SMNT |959 5.3.1 | | |x| | | + REIN |959 5.3.1 | | |x| | | + QUIT |4.1.2.13 |x| | | | | + | | | | | | | + PORT |4.1.2.13 |x| | | | | + PASV |4.1.2.6 |x| | | | | + TYPE |4.1.2.13 |x| | | | |1 + STRU |4.1.2.13 |x| | | | |1 + MODE |4.1.2.13 |x| | | | |1 + | | | | | | | + RETR |4.1.2.13 |x| | | | | + STOR |4.1.2.13 |x| | | | | + STOU |959 5.3.1 | | |x| | | + APPE |4.1.2.13 |x| | | | | + ALLO |959 5.3.1 | | |x| | | + REST |959 5.3.1 | | |x| | | + RNFR |4.1.2.13 |x| | | | | + RNTO |4.1.2.13 |x| | | | | + ABOR |959 5.3.1 | | |x| | | + DELE |4.1.2.13 |x| | | | | + RMD |4.1.2.13 |x| | | | | + MKD |4.1.2.13 |x| | | | | + PWD |4.1.2.13 |x| | | | | + LIST |4.1.2.13 |x| | | | | + NLST |4.1.2.13 |x| | | | | + SITE |4.1.2.8 | | |x| | | + STAT |4.1.2.13 |x| | | | | + SYST |4.1.2.13 |x| | | | | + HELP |4.1.2.13 |x| | | | | + NOOP |4.1.2.13 |x| | | | | + | | | | | | | + + + +Internet Engineering Task Force [Page 42] + + + + +RFC1123 FILE TRANSFER -- FTP October 1989 + + +User Interface: | | | | | | | + Arbitrary pathnames |4.1.4.1 |x| | | | | + Implement "QUOTE" command |4.1.4.2 |x| | | | | + Transfer control commands immediately |4.1.4.2 | |x| | | | + Display error messages to user |4.1.4.3 | |x| | | | + Verbose mode |4.1.4.3 | |x| | | | + Maintain synchronization with server |4.1.4.4 | |x| | | | + +Footnotes: + +(1) For the values shown earlier. + +(2) Here m is number of bits in a memory word. + +(3) Required for host with record-structured file system, optional + otherwise. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 43] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP + + 4.2.1 INTRODUCTION + + The Trivial File Transfer Protocol TFTP is defined in RFC-783 + [TFTP:1]. + + TFTP provides its own reliable delivery with UDP as its + transport protocol, using a simple stop-and-wait acknowledgment + system. Since TFTP has an effective window of only one 512 + octet segment, it can provide good performance only over paths + that have a small delay*bandwidth product. The TFTP file + interface is very simple, providing no access control or + security. + + TFTP's most important application is bootstrapping a host over + a local network, since it is simple and small enough to be + easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are + urged to support TFTP for booting. + + 4.2.2 PROTOCOL WALK-THROUGH + + The TFTP specification [TFTP:1] is written in an open style, + and does not fully specify many parts of the protocol. + + 4.2.2.1 Transfer Modes: RFC-783, Page 3 + + The transfer mode "mail" SHOULD NOT be supported. + + 4.2.2.2 UDP Header: RFC-783, Page 17 + + The Length field of a UDP header is incorrectly defined; it + includes the UDP header length (8). + + 4.2.3 SPECIFIC ISSUES + + 4.2.3.1 Sorcerer's Apprentice Syndrome + + There is a serious bug, known as the "Sorcerer's Apprentice + Syndrome," in the protocol specification. While it does not + cause incorrect operation of the transfer (the file will + always be transferred correctly if the transfer completes), + this bug may cause excessive retransmission, which may cause + the transfer to time out. + + Implementations MUST contain the fix for this problem: the + sender (i.e., the side originating the DATA packets) must + never resend the current DATA packet on receipt of a + + + +Internet Engineering Task Force [Page 44] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + duplicate ACK. + + DISCUSSION: + The bug is caused by the protocol rule that either + side, on receiving an old duplicate datagram, may + resend the current datagram. If a packet is delayed in + the network but later successfully delivered after + either side has timed out and retransmitted a packet, a + duplicate copy of the response may be generated. If + the other side responds to this duplicate with a + duplicate of its own, then every datagram will be sent + in duplicate for the remainder of the transfer (unless + a datagram is lost, breaking the repetition). Worse + yet, since the delay is often caused by congestion, + this duplicate transmission will usually causes more + congestion, leading to more delayed packets, etc. + + The following example may help to clarify this problem. + + TFTP A TFTP B + + (1) Receive ACK X-1 + Send DATA X + (2) Receive DATA X + Send ACK X + (ACK X is delayed in network, + and A times out): + (3) Retransmit DATA X + + (4) Receive DATA X again + Send ACK X again + (5) Receive (delayed) ACK X + Send DATA X+1 + (6) Receive DATA X+1 + Send ACK X+1 + (7) Receive ACK X again + Send DATA X+1 again + (8) Receive DATA X+1 again + Send ACK X+1 again + (9) Receive ACK X+1 + Send DATA X+2 + (10) Receive DATA X+2 + Send ACK X+3 + (11) Receive ACK X+1 again + Send DATA X+2 again + (12) Receive DATA X+2 again + Send ACK X+3 again + + + + +Internet Engineering Task Force [Page 45] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + Notice that once the delayed ACK arrives, the protocol + settles down to duplicate all further packets + (sequences 5-8 and 9-12). The problem is caused not by + either side timing out, but by both sides + retransmitting the current packet when they receive a + duplicate. + + The fix is to break the retransmission loop, as + indicated above. This is analogous to the behavior of + TCP. It is then possible to remove the retransmission + timer on the receiver, since the resent ACK will never + cause any action; this is a useful simplification where + TFTP is used in a bootstrap program. It is OK to allow + the timer to remain, and it may be helpful if the + retransmitted ACK replaces one that was genuinely lost + in the network. The sender still requires a retransmit + timer, of course. + + 4.2.3.2 Timeout Algorithms + + A TFTP implementation MUST use an adaptive timeout. + + IMPLEMENTATION: + TCP retransmission algorithms provide a useful base to + work from. At least an exponential backoff of + retransmission timeout is necessary. + + 4.2.3.3 Extensions + + A variety of non-standard extensions have been made to TFTP, + including additional transfer modes and a secure operation + mode (with passwords). None of these have been + standardized. + + 4.2.3.4 Access Control + + A server TFTP implementation SHOULD include some + configurable access control over what pathnames are allowed + in TFTP operations. + + 4.2.3.5 Broadcast Request + + A TFTP request directed to a broadcast address SHOULD be + silently ignored. + + DISCUSSION: + Due to the weak access control capability of TFTP, + directed broadcasts of TFTP requests to random networks + + + +Internet Engineering Task Force [Page 46] + + + + +RFC1123 FILE TRANSFER -- TFTP October 1989 + + + could create a significant security hole. + + 4.2.4 TFTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-------------------------------------------------|--------|-|-|-|-|-|-- +Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | +Transfer modes: | | | | | | | + netascii |RFC-783 |x| | | | | + octet |RFC-783 |x| | | | | + mail |4.2.2.1 | | | |x| | + extensions |4.2.3.3 | | |x| | | +Use adaptive timeout |4.2.3.2 |x| | | | | +Configurable access control |4.2.3.4 | |x| | | | +Silently ignore broadcast request |4.2.3.5 | |x| | | | +-------------------------------------------------|--------|-|-|-|-|-|-- +-------------------------------------------------|--------|-|-|-|-|-|-- + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 47] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + +5. ELECTRONIC MAIL -- SMTP and RFC-822 + + 5.1 INTRODUCTION + + In the TCP/IP protocol suite, electronic mail in a format + specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail + Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. + + While SMTP has remained unchanged over the years, the Internet + community has made several changes in the way SMTP is used. In + particular, the conversion to the Domain Name System (DNS) has + caused changes in address formats and in mail routing. In this + section, we assume familiarity with the concepts and terminology + of the DNS, whose requirements are given in Section 6.1. + + RFC-822 specifies the Internet standard format for electronic mail + messages. RFC-822 supercedes an older standard, RFC-733, that may + still be in use in a few places, although it is obsolete. The two + formats are sometimes referred to simply by number ("822" and + "733"). + + RFC-822 is used in some non-Internet mail environments with + different mail transfer protocols than SMTP, and SMTP has also + been adapted for use in some non-Internet environments. Note that + this document presents the rules for the use of SMTP and RFC-822 + for the Internet environment only; other mail environments that + use these protocols may be expected to have their own rules. + + 5.2 PROTOCOL WALK-THROUGH + + This section covers both RFC-821 and RFC-822. + + The SMTP specification in RFC-821 is clear and contains numerous + examples, so implementors should not find it difficult to + understand. This section simply updates or annotates portions of + RFC-821 to conform with current usage. + + RFC-822 is a long and dense document, defining a rich syntax. + Unfortunately, incomplete or defective implementations of RFC-822 + are common. In fact, nearly all of the many formats of RFC-822 + are actually used, so an implementation generally needs to + recognize and correctly interpret all of the RFC-822 syntax. + + 5.2.1 The SMTP Model: RFC-821 Section 2 + + DISCUSSION: + Mail is sent by a series of request/response transactions + between a client, the "sender-SMTP," and a server, the + + + +Internet Engineering Task Force [Page 48] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "receiver-SMTP". These transactions pass (1) the message + proper, which is composed of header and body, and (2) SMTP + source and destination addresses, referred to as the + "envelope". + + The SMTP programs are analogous to Message Transfer Agents + (MTAs) of X.400. There will be another level of protocol + software, closer to the end user, that is responsible for + composing and analyzing RFC-822 message headers; this + component is known as the "User Agent" in X.400, and we + use that term in this document. There is a clear logical + distinction between the User Agent and the SMTP + implementation, since they operate on different levels of + protocol. Note, however, that this distinction is may not + be exactly reflected the structure of typical + implementations of Internet mail. Often there is a + program known as the "mailer" that implements SMTP and + also some of the User Agent functions; the rest of the + User Agent functions are included in a user interface used + for entering and reading mail. + + The SMTP envelope is constructed at the originating site, + typically by the User Agent when the message is first + queued for the Sender-SMTP program. The envelope + addresses may be derived from information in the message + header, supplied by the user interface (e.g., to implement + a bcc: request), or derived from local configuration + information (e.g., expansion of a mailing list). The SMTP + envelope cannot in general be re-derived from the header + at a later stage in message delivery, so the envelope is + transmitted separately from the message itself using the + MAIL and RCPT commands of SMTP. + + The text of RFC-821 suggests that mail is to be delivered + to an individual user at a host. With the advent of the + domain system and of mail routing using mail-exchange (MX) + resource records, implementors should now think of + delivering mail to a user at a domain, which may or may + not be a particular host. This DOES NOT change the fact + that SMTP is a host-to-host mail exchange protocol. + + 5.2.2 Canonicalization: RFC-821 Section 3.1 + + The domain names that a Sender-SMTP sends in MAIL and RCPT + commands MUST have been "canonicalized," i.e., they must be + fully-qualified principal names or domain literals, not + nicknames or domain abbreviations. A canonicalized name either + identifies a host directly or is an MX name; it cannot be a + + + +Internet Engineering Task Force [Page 49] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + CNAME. + + 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 + + A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN + (this requirement overrides RFC-821). However, there MAY be + configuration information to disable VRFY and EXPN in a + particular installation; this might even allow EXPN to be + disabled for selected lists. + + A new reply code is defined for the VRFY command: + + 252 Cannot VRFY user (e.g., info is not local), but will + take message for this user and attempt delivery. + + DISCUSSION: + SMTP users and administrators make regular use of these + commands for diagnosing mail delivery problems. With the + increasing use of multi-level mailing list expansion + (sometimes more than two levels), EXPN has been + increasingly important for diagnosing inadvertent mail + loops. On the other hand, some feel that EXPN represents + a significant privacy, and perhaps even a security, + exposure. + + 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 + + An SMTP MAY implement the commands to send a message to a + user's terminal: SEND, SOML, and SAML. + + DISCUSSION: + It has been suggested that the use of mail relaying + through an MX record is inconsistent with the intent of + SEND to deliver a message immediately and directly to a + user's terminal. However, an SMTP receiver that is unable + to write directly to the user terminal can return a "251 + User Not Local" reply to the RCPT following a SEND, to + inform the originator of possibly deferred delivery. + + 5.2.5 HELO Command: RFC-821 Section 3.5 + + The sender-SMTP MUST ensure that the <domain> parameter in a + HELO command is a valid principal host domain name for the + client host. As a result, the receiver-SMTP will not have to + perform MX resolution on this name in order to validate the + HELO parameter. + + The HELO receiver MAY verify that the HELO parameter really + + + +Internet Engineering Task Force [Page 50] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + corresponds to the IP address of the sender. However, the + receiver MUST NOT refuse to accept a message, even if the + sender's HELO command fails verification. + + DISCUSSION: + Verifying the HELO parameter requires a domain name lookup + and may therefore take considerable time. An alternative + tool for tracking bogus mail sources is suggested below + (see "DATA Command"). + + Note also that the HELO argument is still required to have + valid <domain> syntax, since it will appear in a Received: + line; otherwise, a 501 error is to be sent. + + IMPLEMENTATION: + When HELO parameter validation fails, a suggested + procedure is to insert a note about the unknown + authenticity of the sender into the message header (e.g., + in the "Received:" line). + + 5.2.6 Mail Relay: RFC-821 Section 3.6 + + We distinguish three types of mail (store-and-) forwarding: + + (1) A simple forwarder or "mail exchanger" forwards a message + using private knowledge about the recipient; see section + 3.2 of RFC-821. + + (2) An SMTP mail "relay" forwards a message within an SMTP + mail environment as the result of an explicit source route + (as defined in section 3.6 of RFC-821). The SMTP relay + function uses the "@...:" form of source route from RFC- + 822 (see Section 5.2.19 below). + + (3) A mail "gateway" passes a message between different + environments. The rules for mail gateways are discussed + below in Section 5.3.7. + + An Internet host that is forwarding a message but is not a + gateway to a different mail environment (i.e., it falls under + (1) or (2)) SHOULD NOT alter any existing header fields, + although the host will add an appropriate Received: line as + required in Section 5.2.8. + + A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an + explicit source route using the "@...:" address form. Thus, + the relay function defined in section 3.6 of RFC-821 should + not be used. + + + +Internet Engineering Task Force [Page 51] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + The intent is to discourage all source routing and to + abolish explicit source routing for mail delivery within + the Internet environment. Source-routing is unnecessary; + the simple target address "user@domain" should always + suffice. This is the result of an explicit architectural + decision to use universal naming rather than source + routing for mail. Thus, SMTP provides end-to-end + connectivity, and the DNS provides globally-unique, + location-independent names. MX records handle the major + case where source routing might otherwise be needed. + + A receiver-SMTP MUST accept the explicit source route syntax in + the envelope, but it MAY implement the relay function as + defined in section 3.6 of RFC-821. If it does not implement + the relay function, it SHOULD attempt to deliver the message + directly to the host to the right of the right-most "@" sign. + + DISCUSSION: + For example, suppose a host that does not implement the + relay function receives a message with the SMTP command: + "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and + GAMMA represent domain names. Rather than immediately + refusing the message with a 550 error reply as suggested + on page 20 of RFC-821, the host should try to forward the + message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>". + Since this host does not support relaying, it is not + required to update the reverse path. + + Some have suggested that source routing may be needed + occasionally for manually routing mail around failures; + however, the reality and importance of this need is + controversial. The use of explicit SMTP mail relaying for + this purpose is discouraged, and in fact it may not be + successful, as many host systems do not support it. Some + have used the "%-hack" (see Section 5.2.16) for this + purpose. + + 5.2.7 RCPT Command: RFC-821 Section 4.1.1 + + A host that supports a receiver-SMTP MUST support the reserved + mailbox "Postmaster". + + The receiver-SMTP MAY verify RCPT parameters as they arrive; + however, RCPT responses MUST NOT be delayed beyond a reasonable + time (see Section 5.3.2). + + Therefore, a "250 OK" response to a RCPT does not necessarily + + + +Internet Engineering Task Force [Page 52] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + imply that the delivery address(es) are valid. Errors found + after message acceptance will be reported by mailing a + notification message to an appropriate address (see Section + 5.3.3). + + DISCUSSION: + The set of conditions under which a RCPT parameter can be + validated immediately is an engineering design choice. + Reporting destination mailbox errors to the Sender-SMTP + before mail is transferred is generally desirable to save + time and network bandwidth, but this advantage is lost if + RCPT verification is lengthy. + + For example, the receiver can verify immediately any + simple local reference, such as a single locally- + registered mailbox. On the other hand, the "reasonable + time" limitation generally implies deferring verification + of a mailing list until after the message has been + transferred and accepted, since verifying a large mailing + list can take a very long time. An implementation might + or might not choose to defer validation of addresses that + are non-local and therefore require a DNS lookup. If a + DNS lookup is performed but a soft domain system error + (e.g., timeout) occurs, validity must be assumed. + + 5.2.8 DATA Command: RFC-821 Section 4.1.1 + + Every receiver-SMTP (not just one that "accepts a message for + relaying or for final delivery" [SMTP:1]) MUST insert a + "Received:" line at the beginning of a message. In this line, + called a "time stamp line" in RFC-821: + + * The FROM field SHOULD contain both (1) the name of the + source host as presented in the HELO command and (2) a + domain literal containing the IP address of the source, + determined from the TCP connection. + + * The ID field MAY contain an "@" as suggested in RFC-822, + but this is not required. + + * The FOR field MAY contain a list of <path> entries when + multiple RCPT commands have been given. + + + An Internet mail program MUST NOT change a Received: line that + was previously added to the message header. + + + + + +Internet Engineering Task Force [Page 53] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Including both the source host and the IP source address + in the Received: line may provide enough information for + tracking illicit mail sources and eliminate a need to + explicitly verify the HELO parameter. + + Received: lines are primarily intended for humans tracing + mail routes, primarily of diagnosis of faults. See also + the discussion under 5.3.7. + + When the receiver-SMTP makes "final delivery" of a message, + then it MUST pass the MAIL FROM: address from the SMTP envelope + with the message, for use if an error notification message must + be sent later (see Section 5.3.3). There is an analogous + requirement when gatewaying from the Internet into a different + mail environment; see Section 5.3.7. + + DISCUSSION: + Note that the final reply to the DATA command depends only + upon the successful transfer and storage of the message. + Any problem with the destination address(es) must either + (1) have been reported in an SMTP error reply to the RCPT + command(s), or (2) be reported in a later error message + mailed to the originator. + + IMPLEMENTATION: + The MAIL FROM: information may be passed as a parameter or + in a Return-Path: line inserted at the beginning of the + message. + + 5.2.9 Command Syntax: RFC-821 Section 4.1.2 + + The syntax shown in RFC-821 for the MAIL FROM: command omits + the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page + 15). An empty reverse path MUST be supported. + + 5.2.10 SMTP Replies: RFC-821 Section 4.2 + + A receiver-SMTP SHOULD send only the reply codes listed in + section 4.2.2 of RFC-821 or in this document. A receiver-SMTP + SHOULD use the text shown in examples in RFC-821 whenever + appropriate. + + A sender-SMTP MUST determine its actions only by the reply + code, not by the text (except for 251 and 551 replies); any + text, including no text at all, must be acceptable. The space + (blank) following the reply code is considered part of the + text. Whenever possible, a sender-SMTP SHOULD test only the + + + +Internet Engineering Task Force [Page 54] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + first digit of the reply code, as specified in Appendix E of + RFC-821. + + DISCUSSION: + Interoperability problems have arisen with SMTP systems + using reply codes that are not listed explicitly in RFC- + 821 Section 4.3 but are legal according to the theory of + reply codes explained in Appendix E. + + 5.2.11 Transparency: RFC-821 Section 4.5.2 + + Implementors MUST be sure that their mail systems always add + and delete periods to ensure message transparency. + + 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 + + RFC-974 [SMTP:3] recommended that the domain system be queried + for WKS ("Well-Known Service") records, to verify that each + proposed mail target does support SMTP. Later experience has + shown that WKS is not widely supported, so the WKS step in MX + processing SHOULD NOT be used. + + The following are notes on RFC-822, organized by section of that + document. + + 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 + + The syntax shown for the Return-path line omits the possibility + of a null return path, which is used to prevent looping of + error notifications (see Section 5.3.3). The complete syntax + is: + + return = "Return-path" ":" route-addr + / "Return-path" ":" "<" ">" + + The set of optional header fields is hereby expanded to include + the Content-Type field defined in RFC-1049 [SMTP:7]. This + field "allows mail reading systems to automatically identify + the type of a structured message body and to process it for + display accordingly". [SMTP:7] A User Agent MAY support this + field. + + 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 + + The syntax for the date is hereby changed to: + + date = 1*2DIGIT month 2*4DIGIT + + + + +Internet Engineering Task Force [Page 55] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + All mail software SHOULD use 4-digit years in dates, to ease + the transition to the next century. + + There is a strong trend towards the use of numeric timezone + indicators, and implementations SHOULD use numeric timezones + instead of timezone names. However, all implementations MUST + accept either notation. If timezone names are used, they MUST + be exactly as defined in RFC-822. + + The military time zones are specified incorrectly in RFC-822: + they count the wrong way from UT (the signs are reversed). As + a result, military time zones in RFC-822 headers carry no + information. + + Finally, note that there is a typo in the definition of "zone" + in the syntax summary of appendix D; the correct definition + occurs in Section 3 of RFC-822. + + 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 + + The syntactic definition of "mailbox" in RFC-822 is hereby + changed to: + + mailbox = addr-spec ; simple address + / [phrase] route-addr ; name & addr-spec + + That is, the phrase preceding a route address is now OPTIONAL. + This change makes the following header field legal, for + example: + + From: <craig@nnsc.nsf.net> + + 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 + + The basic mailbox address specification has the form: "local- + part@domain". Here "local-part", sometimes called the "left- + hand side" of the address, is domain-dependent. + + A host that is forwarding the message but is not the + destination host implied by the right-hand side "domain" MUST + NOT interpret or modify the "local-part" of the address. + + When mail is to be gatewayed from the Internet mail environment + into a foreign mail environment (see Section 5.3.7), routing + information for that foreign environment MAY be embedded within + the "local-part" of the address. The gateway will then + interpret this local part appropriately for the foreign mail + environment. + + + +Internet Engineering Task Force [Page 56] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + DISCUSSION: + Although source routes are discouraged within the Internet + (see Section 5.2.6), there are non-Internet mail + environments whose delivery mechanisms do depend upon + source routes. Source routes for extra-Internet + environments can generally be buried in the "local-part" + of the address (see Section 5.2.16) while mail traverses + the Internet. When the mail reaches the appropriate + Internet mail gateway, the gateway will interpret the + local-part and build the necessary address or route for + the target mail environment. + + For example, an Internet host might send mail to: + "a!b!c!user@gateway-domain". The complex local part + "a!b!c!user" would be uninterpreted within the Internet + domain, but could be parsed and understood by the + specified mail gateway. + + An embedded source route is sometimes encoded in the + "local-part" using "%" as a right-binding routing + operator. For example, in: + + user%domain%relay3%relay2@relay1 + + the "%" convention implies that the mail is to be routed + from "relay1" through "relay2", "relay3", and finally to + "user" at "domain". This is commonly known as the "%- + hack". It is suggested that "%" have lower precedence + than any other routing operator (e.g., "!") hidden in the + local-part; for example, "a!b%c" would be interpreted as + "(a!b)%c". + + Only the target host (in this case, "relay1") is permitted + to analyze the local-part "user%domain%relay3%relay2". + + 5.2.17 Domain Literals: RFC-822 Section 6.2.3 + + A mailer MUST be able to accept and parse an Internet domain + literal whose content ("dtext"; see RFC-822) is a dotted- + decimal host address. This satisfies the requirement of + Section 2.1 for the case of mail. + + An SMTP MUST accept and recognize a domain literal for any of + its own IP addresses. + + + + + + + +Internet Engineering Task Force [Page 57] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 + + Errors in formatting or parsing 822 addresses are unfortunately + common. This section mentions only the most common errors. A + User Agent MUST accept all valid RFC-822 address formats, and + MUST NOT generate illegal address syntax. + + o A common error is to leave out the semicolon after a group + identifier. + + o Some systems fail to fully-qualify domain names in + messages they generate. The right-hand side of an "@" + sign in a header address field MUST be a fully-qualified + domain name. + + For example, some systems fail to fully-qualify the From: + address; this prevents a "reply" command in the user + interface from automatically constructing a return + address. + + DISCUSSION: + Although RFC-822 allows the local use of abbreviated + domain names within a domain, the application of + RFC-822 in Internet mail does not allow this. The + intent is that an Internet host must not send an SMTP + message header containing an abbreviated domain name + in an address field. This allows the address fields + of the header to be passed without alteration across + the Internet, as required in Section 5.2.6. + + o Some systems mis-parse multiple-hop explicit source routes + such as: + + @relay1,@relay2,@relay3:user@domain. + + + o Some systems over-qualify domain names by adding a + trailing dot to some or all domain names in addresses or + message-ids. This violates RFC-822 syntax. + + + 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 + + Internet host software SHOULD NOT create an RFC-822 header + containing an address with an explicit source route, but MUST + accept such headers for compatibility with earlier systems. + + DISCUSSION: + + + +Internet Engineering Task Force [Page 58] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + In an understatement, RFC-822 says "The use of explicit + source routing is discouraged". Many hosts implemented + RFC-822 source routes incorrectly, so the syntax cannot be + used unambiguously in practice. Many users feel the + syntax is ugly. Explicit source routes are not needed in + the mail envelope for delivery; see Section 5.2.6. For + all these reasons, explicit source routes using the RFC- + 822 notations are not to be used in Internet mail headers. + + As stated in Section 5.2.16, it is necessary to allow an + explicit source route to be buried in the local-part of an + address, e.g., using the "%-hack", in order to allow mail + to be gatewayed into another environment in which explicit + source routing is necessary. The vigilant will observe + that there is no way for a User Agent to detect and + prevent the use of such implicit source routing when the + destination is within the Internet. We can only + discourage source routing of any kind within the Internet, + as unnecessary and undesirable. + + 5.3 SPECIFIC ISSUES + + 5.3.1 SMTP Queueing Strategies + + The common structure of a host SMTP implementation includes + user mailboxes, one or more areas for queueing messages in + transit, and one or more daemon processes for sending and + receiving mail. The exact structure will vary depending on the + needs of the users on the host and the number and size of + mailing lists supported by the host. We describe several + optimizations that have proved helpful, particularly for + mailers supporting high traffic levels. + + Any queueing strategy MUST include: + + o Timeouts on all activities. See Section 5.3.2. + + o Never sending error messages in response to error + messages. + + + 5.3.1.1 Sending Strategy + + The general model of a sender-SMTP is one or more processes + that periodically attempt to transmit outgoing mail. In a + typical system, the program that composes a message has some + method for requesting immediate attention for a new piece of + outgoing mail, while mail that cannot be transmitted + + + +Internet Engineering Task Force [Page 59] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + immediately MUST be queued and periodically retried by the + sender. A mail queue entry will include not only the + message itself but also the envelope information. + + The sender MUST delay retrying a particular destination + after one attempt has failed. In general, the retry + interval SHOULD be at least 30 minutes; however, more + sophisticated and variable strategies will be beneficial + when the sender-SMTP can determine the reason for non- + delivery. + + Retries continue until the message is transmitted or the + sender gives up; the give-up time generally needs to be at + least 4-5 days. The parameters to the retry algorithm MUST + be configurable. + + A sender SHOULD keep a list of hosts it cannot reach and + corresponding timeouts, rather than just retrying queued + mail items. + + DISCUSSION: + Experience suggests that failures are typically + transient (the target system has crashed), favoring a + policy of two connection attempts in the first hour the + message is in the queue, and then backing off to once + every two or three hours. + + The sender-SMTP can shorten the queueing delay by + cooperation with the receiver-SMTP. In particular, if + mail is received from a particular address, it is good + evidence that any mail queued for that host can now be + sent. + + The strategy may be further modified as a result of + multiple addresses per host (see Section 5.3.4), to + optimize delivery time vs. resource usage. + + A sender-SMTP may have a large queue of messages for + each unavailable destination host, and if it retried + all these messages in every retry cycle, there would be + excessive Internet overhead and the daemon would be + blocked for a long period. Note that an SMTP can + generally determine that a delivery attempt has failed + only after a timeout of a minute or more; a one minute + timeout per connection will result in a very large + delay if it is repeated for dozens or even hundreds of + queued messages. + + + + +Internet Engineering Task Force [Page 60] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + When the same message is to be delivered to several users on + the same host, only one copy of the message SHOULD be + transmitted. That is, the sender-SMTP should use the + command sequence: RCPT, RCPT,... RCPT, DATA instead of the + sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. + Implementation of this efficiency feature is strongly urged. + + Similarly, the sender-SMTP MAY support multiple concurrent + outgoing mail transactions to achieve timely delivery. + However, some limit SHOULD be imposed to protect the host + from devoting all its resources to mail. + + The use of the different addresses of a multihomed host is + discussed below. + + 5.3.1.2 Receiving strategy + + The receiver-SMTP SHOULD attempt to keep a pending listen on + the SMTP port at all times. This will require the support + of multiple incoming TCP connections for SMTP. Some limit + MAY be imposed. + + IMPLEMENTATION: + When the receiver-SMTP receives mail from a particular + host address, it could notify the sender-SMTP to retry + any mail pending for that host address. + + 5.3.2 Timeouts in SMTP + + There are two approaches to timeouts in the sender-SMTP: (a) + limit the time for each SMTP command separately, or (b) limit + the time for the entire SMTP dialogue for a single mail + message. A sender-SMTP SHOULD use option (a), per-command + timeouts. Timeouts SHOULD be easily reconfigurable, preferably + without recompiling the SMTP code. + + DISCUSSION: + Timeouts are an essential feature of an SMTP + implementation. If the timeouts are too long (or worse, + there are no timeouts), Internet communication failures or + software bugs in receiver-SMTP programs can tie up SMTP + processes indefinitely. If the timeouts are too short, + resources will be wasted with attempts that time out part + way through message delivery. + + If option (b) is used, the timeout has to be very large, + e.g., an hour, to allow time to expand very large mailing + lists. The timeout may also need to increase linearly + + + +Internet Engineering Task Force [Page 61] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + with the size of the message, to account for the time to + transmit a very large message. A large fixed timeout + leads to two problems: a failure can still tie up the + sender for a very long time, and very large messages may + still spuriously time out (which is a wasteful failure!). + + Using the recommended option (a), a timer is set for each + SMTP command and for each buffer of the data transfer. + The latter means that the overall timeout is inherently + proportional to the size of the message. + + Based on extensive experience with busy mail-relay hosts, the + minimum per-command timeout values SHOULD be as follows: + + o Initial 220 Message: 5 minutes + + A Sender-SMTP process needs to distinguish between a + failed TCP connection and a delay in receiving the initial + 220 greeting message. Many receiver-SMTPs will accept a + TCP connection but delay delivery of the 220 message until + their system load will permit more mail to be processed. + + o MAIL Command: 5 minutes + + + o RCPT Command: 5 minutes + + A longer timeout would be required if processing of + mailing lists and aliases were not deferred until after + the message was accepted. + + o DATA Initiation: 2 minutes + + This is while awaiting the "354 Start Input" reply to a + DATA command. + + o Data Block: 3 minutes + + This is while awaiting the completion of each TCP SEND + call transmitting a chunk of data. + + o DATA Termination: 10 minutes. + + This is while awaiting the "250 OK" reply. When the + receiver gets the final period terminating the message + data, it typically performs processing to deliver the + message to a user mailbox. A spurious timeout at this + point would be very wasteful, since the message has been + + + +Internet Engineering Task Force [Page 62] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + successfully sent. + + A receiver-SMTP SHOULD have a timeout of at least 5 minutes + while it is awaiting the next command from the sender. + + 5.3.3 Reliable Mail Receipt + + When the receiver-SMTP accepts a piece of mail (by sending a + "250 OK" message in response to DATA), it is accepting + responsibility for delivering or relaying the message. It must + take this responsibility seriously, i.e., it MUST NOT lose the + message for frivolous reasons, e.g., because the host later + crashes or because of a predictable resource shortage. + + If there is a delivery failure after acceptance of a message, + the receiver-SMTP MUST formulate and mail a notification + message. This notification MUST be sent using a null ("<>") + reverse path in the envelope; see Section 3.6 of RFC-821. The + recipient of this notification SHOULD be the address from the + envelope return path (or the Return-Path: line). However, if + this address is null ("<>"), the receiver-SMTP MUST NOT send a + notification. If the address is an explicit source route, it + SHOULD be stripped down to its final hop. + + DISCUSSION: + For example, suppose that an error notification must be + sent for a message that arrived with: + "MAIL FROM:<@a,@b:user@d>". The notification message + should be sent to: "RCPT TO:<user@d>". + + Some delivery failures after the message is accepted by + SMTP will be unavoidable. For example, it may be + impossible for the receiver-SMTP to validate all the + delivery addresses in RCPT command(s) due to a "soft" + domain system error or because the target is a mailing + list (see earlier discussion of RCPT). + + To avoid receiving duplicate messages as the result of + timeouts, a receiver-SMTP MUST seek to minimize the time + required to respond to the final "." that ends a message + transfer. See RFC-1047 [SMTP:4] for a discussion of this + problem. + + 5.3.4 Reliable Mail Transmission + + To transmit a message, a sender-SMTP determines the IP address + of the target host from the destination address in the + envelope. Specifically, it maps the string to the right of the + + + +Internet Engineering Task Force [Page 63] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + "@" sign into an IP address. This mapping or the transfer + itself may fail with a soft error, in which case the sender- + SMTP will requeue the outgoing mail for a later retry, as + required in Section 5.3.1.1. + + When it succeeds, the mapping can result in a list of + alternative delivery addresses rather than a single address, + because of (a) multiple MX records, (b) multihoming, or both. + To provide reliable mail transmission, the sender-SMTP MUST be + able to try (and retry) each of the addresses in this list in + order, until a delivery attempt succeeds. However, there MAY + also be a configurable limit on the number of alternate + addresses that can be tried. In any case, a host SHOULD try at + least two addresses. + + The following information is to be used to rank the host + addresses: + + (1) Multiple MX Records -- these contain a preference + indication that should be used in sorting. If there are + multiple destinations with the same preference and there + is no clear reason to favor one (e.g., by address + preference), then the sender-SMTP SHOULD pick one at + random to spread the load across multiple mail exchanges + for a specific organization; note that this is a + refinement of the procedure in [DNS:3]. + + (2) Multihomed host -- The destination host (perhaps taken + from the preferred MX record) may be multihomed, in which + case the domain name resolver will return a list of + alternative IP addresses. It is the responsibility of the + domain name resolver interface (see Section 6.1.3.4 below) + to have ordered this list by decreasing preference, and + SMTP MUST try them in the order presented. + + DISCUSSION: + Although the capability to try multiple alternative + addresses is required, there may be circumstances where + specific installations want to limit or disable the use of + alternative addresses. The question of whether a sender + should attempt retries using the different addresses of a + multihomed host has been controversial. The main argument + for using the multiple addresses is that it maximizes the + probability of timely delivery, and indeed sometimes the + probability of any delivery; the counter argument is that + it may result in unnecessary resource use. + + Note that resource use is also strongly determined by the + + + +Internet Engineering Task Force [Page 64] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + sending strategy discussed in Section 5.3.1. + + 5.3.5 Domain Name Support + + SMTP implementations MUST use the mechanism defined in Section + 6.1 for mapping between domain names and IP addresses. This + means that every Internet SMTP MUST include support for the + Internet DNS. + + In particular, a sender-SMTP MUST support the MX record scheme + [SMTP:3]. See also Section 7.4 of [DNS:2] for information on + domain name support for SMTP. + + 5.3.6 Mailing Lists and Aliases + + An SMTP-capable host SHOULD support both the alias and the list + form of address expansion for multiple delivery. When a + message is delivered or forwarded to each address of an + expanded list form, the return address in the envelope + ("MAIL FROM:") MUST be changed to be the address of a person + who administers the list, but the message header MUST be left + unchanged; in particular, the "From" field of the message is + unaffected. + + DISCUSSION: + An important mail facility is a mechanism for multi- + destination delivery of a single message, by transforming + or "expanding" a pseudo-mailbox address into a list of + destination mailbox addresses. When a message is sent to + such a pseudo-mailbox (sometimes called an "exploder"), + copies are forwarded or redistributed to each mailbox in + the expanded list. We classify such a pseudo-mailbox as + an "alias" or a "list", depending upon the expansion + rules: + + (a) Alias + + To expand an alias, the recipient mailer simply + replaces the pseudo-mailbox address in the envelope + with each of the expanded addresses in turn; the rest + of the envelope and the message body are left + unchanged. The message is then delivered or + forwarded to each expanded address. + + (b) List + + A mailing list may be said to operate by + "redistribution" rather than by "forwarding". To + + + +Internet Engineering Task Force [Page 65] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + expand a list, the recipient mailer replaces the + pseudo-mailbox address in the envelope with each of + the expanded addresses in turn. The return address in + the envelope is changed so that all error messages + generated by the final deliveries will be returned to + a list administrator, not to the message originator, + who generally has no control over the contents of the + list and will typically find error messages annoying. + + + 5.3.7 Mail Gatewaying + + Gatewaying mail between different mail environments, i.e., + different mail formats and protocols, is complex and does not + easily yield to standardization. See for example [SMTP:5a], + [SMTP:5b]. However, some general requirements may be given for + a gateway between the Internet and another mail environment. + + (A) Header fields MAY be rewritten when necessary as messages + are gatewayed across mail environment boundaries. + + DISCUSSION: + This may involve interpreting the local-part of the + destination address, as suggested in Section 5.2.16. + + The other mail systems gatewayed to the Internet + generally use a subset of RFC-822 headers, but some + of them do not have an equivalent to the SMTP + envelope. Therefore, when a message leaves the + Internet environment, it may be necessary to fold the + SMTP envelope information into the message header. A + possible solution would be to create new header + fields to carry the envelope information (e.g., "X- + SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would + require changes in mail programs in the foreign + environment. + + (B) When forwarding a message into or out of the Internet + environment, a gateway MUST prepend a Received: line, but + it MUST NOT alter in any way a Received: line that is + already in the header. + + DISCUSSION: + This requirement is a subset of the general + "Received:" line requirement of Section 5.2.8; it is + restated here for emphasis. + + Received: fields of messages originating from other + + + +Internet Engineering Task Force [Page 66] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + environments may not conform exactly to RFC822. + However, the most important use of Received: lines is + for debugging mail faults, and this debugging can be + severely hampered by well-meaning gateways that try + to "fix" a Received: line. + + The gateway is strongly encouraged to indicate the + environment and protocol in the "via" clauses of + Received field(s) that it supplies. + + (C) From the Internet side, the gateway SHOULD accept all + valid address formats in SMTP commands and in RFC-822 + headers, and all valid RFC-822 messages. Although a + gateway must accept an RFC-822 explicit source route + ("@...:" format) in either the RFC-822 header or in the + envelope, it MAY or may not act on the source route; see + Sections 5.2.6 and 5.2.19. + + DISCUSSION: + It is often tempting to restrict the range of + addresses accepted at the mail gateway to simplify + the translation into addresses for the remote + environment. This practice is based on the + assumption that mail users have control over the + addresses their mailers send to the mail gateway. In + practice, however, users have little control over the + addresses that are finally sent; their mailers are + free to change addresses into any legal RFC-822 + format. + + (D) The gateway MUST ensure that all header fields of a + message that it forwards into the Internet meet the + requirements for Internet mail. In particular, all + addresses in "From:", "To:", "Cc:", etc., fields must be + transformed (if necessary) to satisfy RFC-822 syntax, and + they must be effective and useful for sending replies. + + + (E) The translation algorithm used to convert mail from the + Internet protocols to another environment's protocol + SHOULD try to ensure that error messages from the foreign + mail environment are delivered to the return path from the + SMTP envelope, not to the sender listed in the "From:" + field of the RFC-822 message. + + DISCUSSION: + Internet mail lists usually place the address of the + mail list maintainer in the envelope but leave the + + + +Internet Engineering Task Force [Page 67] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + original message header intact (with the "From:" + field containing the original sender). This yields + the behavior the average recipient expects: a reply + to the header gets sent to the original sender, not + to a mail list maintainer; however, errors get sent + to the maintainer (who can fix the problem) and not + the sender (who probably cannot). + + (F) Similarly, when forwarding a message from another + environment into the Internet, the gateway SHOULD set the + envelope return path in accordance with an error message + return address, if any, supplied by the foreign + environment. + + + 5.3.8 Maximum Message Size + + Mailer software MUST be able to send and receive messages of at + least 64K bytes in length (including header), and a much larger + maximum size is highly desirable. + + DISCUSSION: + Although SMTP does not define the maximum size of a + message, many systems impose implementation limits. + + The current de facto minimum limit in the Internet is 64K + bytes. However, electronic mail is used for a variety of + purposes that create much larger messages. For example, + mail is often used instead of FTP for transmitting ASCII + files, and in particular to transmit entire documents. As + a result, messages can be 1 megabyte or even larger. We + note that the present document together with its lower- + layer companion contains 0.5 megabytes. + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 68] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + 5.4 SMTP REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +RECEIVER-SMTP: | | | | | | | + Implement VRFY |5.2.3 |x| | | | | + Implement EXPN |5.2.3 | |x| | | | + EXPN, VRFY configurable |5.2.3 | | |x| | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Verify HELO parameter |5.2.5 | | |x| | | + Refuse message with bad HELO |5.2.5 | | | | |x| + Accept explicit src-route syntax in env. |5.2.6 |x| | | | | + Support "postmaster" |5.2.7 |x| | | | | + Process RCPT when received (except lists) |5.2.7 | | |x| | | + Long delay of RCPT responses |5.2.7 | | | | |x| + | | | | | | | + Add Received: line |5.2.8 |x| | | | | + Received: line include domain literal |5.2.8 | |x| | | | + Change previous Received: line |5.2.8 | | | | |x| + Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | + Support empty reverse path |5.2.9 |x| | | | | + Send only official reply codes |5.2.10 | |x| | | | + Send text from RFC-821 when appropriate |5.2.10 | |x| | | | + Delete "." for transparency |5.2.11 |x| | | | | + Accept and recognize self domain literal(s) |5.2.17 |x| | | | | + | | | | | | | + Error message about error message |5.3.1 | | | | |x| + Keep pending listen on SMTP port |5.3.1.2 | |x| | | | + Provide limit on recv concurrency |5.3.1.2 | | |x| | | + Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | + Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| + Send error notification msg after accept |5.3.3 |x| | | | | + Send using null return path |5.3.3 |x| | | | | + Send to envelope return path |5.3.3 | |x| | | | + Send to null address |5.3.3 | | | | |x| + Strip off explicit src route |5.3.3 | |x| | | | + Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | +-----------------------------------------------|----------|-|-|-|-|-|-- + + + +Internet Engineering Task Force [Page 69] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + | | | | | | | +SENDER-SMTP: | | | | | | | + Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | + Implement SEND, SOML, SAML |5.2.4 | | |x| | | + Send valid principal host name in HELO |5.2.5 |x| | | | | + Send explicit source route in RCPT TO: |5.2.6 | | | |x| | + Use only reply code to determine action |5.2.10 |x| | | | | + Use only high digit of reply code when poss. |5.2.10 | |x| | | | + Add "." for transparency |5.2.11 |x| | | | | + | | | | | | | + Retry messages after soft failure |5.3.1.1 |x| | | | | + Delay before retry |5.3.1.1 |x| | | | | + Configurable retry parameters |5.3.1.1 |x| | | | | + Retry once per each queued dest host |5.3.1.1 | |x| | | | + Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | + Support multiple concurrent transactions |5.3.1.1 | | |x| | | + Provide limit on concurrency |5.3.1.1 | |x| | | | + | | | | | | | + Timeouts on all activities |5.3.1 |x| | | | | + Per-command timeouts |5.3.2 | |x| | | | + Timeouts easily reconfigurable |5.3.2 | |x| | | | + Recommended times |5.3.2 | |x| | | | + Try alternate addr's in order |5.3.4 |x| | | | | + Configurable limit on alternate tries |5.3.4 | | |x| | | + Try at least two alternates |5.3.4 | |x| | | | + Load-split across equal MX alternates |5.3.4 | |x| | | | + Use the Domain Name System |5.3.5 |x| | | | | + Support MX records |5.3.5 |x| | | | | + Use WKS records in MX processing |5.2.12 | | | |x| | +-----------------------------------------------|----------|-|-|-|-|-|-- + | | | | | | | +MAIL FORWARDING: | | | | | | | + Alter existing header field(s) |5.2.6 | | | |x| | + Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | + If not, deliver to RHS domain |5.2.6 | |x| | | | + Interpret 'local-part' of addr |5.2.16 | | | | |x| + | | | | | | | +MAILING LISTS AND ALIASES | | | | | | | + Support both |5.3.6 | |x| | | | + Report mail list error to local admin. |5.3.6 |x| | | | | + | | | | | | | +MAIL GATEWAYS: | | | | | | | + Embed foreign mail route in local-part |5.2.16 | | |x| | | + Rewrite header fields when necessary |5.3.7 | | |x| | | + Prepend Received: line |5.3.7 |x| | | | | + Change existing Received: line |5.3.7 | | | | |x| + Accept full RFC-822 on Internet side |5.3.7 | |x| | | | + Act on RFC-822 explicit source route |5.3.7 | | |x| | | + + + +Internet Engineering Task Force [Page 70] + + + + +RFC1123 MAIL -- SMTP & RFC-822 October 1989 + + + Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | + Deliver error msgs to envelope addr |5.3.7 | |x| | | | + Set env return path from err return addr |5.3.7 | |x| | | | + | | | | | | | +USER AGENT -- RFC-822 | | | | | | | + Allow user to enter <route> address |5.2.6 | | | |x| | + Support RFC-1049 Content Type field |5.2.13 | | |x| | | + Use 4-digit years |5.2.14 | |x| | | | + Generate numeric timezones |5.2.14 | |x| | | | + Accept all timezones |5.2.14 |x| | | | | + Use non-num timezones from RFC-822 |5.2.14 |x| | | | | + Omit phrase before route-addr |5.2.15 | | |x| | | + Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | + Accept all RFC-822 address formats |5.2.18 |x| | | | | + Generate invalid RFC-822 address format |5.2.18 | | | | |x| + Fully-qualified domain names in header |5.2.18 |x| | | | | + Create explicit src route in header |5.2.19 | | | |x| | + Accept explicit src route in header |5.2.19 |x| | | | | + | | | | | | | +Send/recv at least 64KB messages |5.3.8 |x| | | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 71] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + +6. SUPPORT SERVICES + + 6.1 DOMAIN NAME TRANSLATION + + 6.1.1 INTRODUCTION + + Every host MUST implement a resolver for the Domain Name System + (DNS), and it MUST implement a mechanism using this DNS + resolver to convert host names to IP addresses and vice-versa + [DNS:1, DNS:2]. + + In addition to the DNS, a host MAY also implement a host name + translation mechanism that searches a local Internet host + table. See Section 6.1.3.8 for more information on this + option. + + DISCUSSION: + Internet host name translation was originally performed by + searching local copies of a table of all hosts. This + table became too large to update and distribute in a + timely manner and too large to fit into many hosts, so the + DNS was invented. + + The DNS creates a distributed database used primarily for + the translation between host names and host addresses. + Implementation of DNS software is required. The DNS + consists of two logically distinct parts: name servers and + resolvers (although implementations often combine these + two logical parts in the interest of efficiency) [DNS:2]. + + Domain name servers store authoritative data about certain + sections of the database and answer queries about the + data. Domain resolvers query domain name servers for data + on behalf of user processes. Every host therefore needs a + DNS resolver; some host machines will also need to run + domain name servers. Since no name server has complete + information, in general it is necessary to obtain + information from more than one name server to resolve a + query. + + 6.1.2 PROTOCOL WALK-THROUGH + + An implementor must study references [DNS:1] and [DNS:2] + carefully. They provide a thorough description of the theory, + protocol, and implementation of the domain name system, and + reflect several years of experience. + + + + + +Internet Engineering Task Force [Page 72] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 + + All DNS name servers and resolvers MUST properly handle RRs + with a zero TTL: return the RR to the client but do not + cache it. + + DISCUSSION: + Zero TTL values are interpreted to mean that the RR can + only be used for the transaction in progress, and + should not be cached; they are useful for extremely + volatile data. + + 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 + + A query with "QCLASS=*" SHOULD NOT be used unless the + requestor is seeking data from more than one class. In + particular, if the requestor is only interested in Internet + data types, QCLASS=IN MUST be used. + + 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 + + Unused fields in a query or response message MUST be zero. + + 6.1.2.4 Compression: RFC-1035 Section 4.1.4 + + Name servers MUST use compression in responses. + + DISCUSSION: + Compression is essential to avoid overflowing UDP + datagrams; see Section 6.1.3.2. + + 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 + + Recursive name servers and full-service resolvers generally + have some configuration information containing hints about + the location of root or local name servers. An + implementation MUST NOT include any of these hints in a + response. + + DISCUSSION: + Many implementors have found it convenient to store + these hints as if they were cached data, but some + neglected to ensure that this "cached data" was not + included in responses. This has caused serious + problems in the Internet when the hints were obsolete + or incorrect. + + + + + +Internet Engineering Task Force [Page 73] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3 SPECIFIC ISSUES + + 6.1.3.1 Resolver Implementation + + A name resolver SHOULD be able to multiplex concurrent + requests if the host supports concurrent processes. + + In implementing a DNS resolver, one of two different models + MAY optionally be chosen: a full-service resolver, or a stub + resolver. + + + (A) Full-Service Resolver + + A full-service resolver is a complete implementation of + the resolver service, and is capable of dealing with + communication failures, failure of individual name + servers, location of the proper name server for a given + name, etc. It must satisfy the following requirements: + + o The resolver MUST implement a local caching + function to avoid repeated remote access for + identical requests, and MUST time out information + in the cache. + + o The resolver SHOULD be configurable with start-up + information pointing to multiple root name servers + and multiple name servers for the local domain. + This insures that the resolver will be able to + access the whole name space in normal cases, and + will be able to access local domain information + should the local network become disconnected from + the rest of the Internet. + + + (B) Stub Resolver + + A "stub resolver" relies on the services of a recursive + name server on the connected network or a "nearby" + network. This scheme allows the host to pass on the + burden of the resolver function to a name server on + another host. This model is often essential for less + capable hosts, such as PCs, and is also recommended + when the host is one of several workstations on a local + network, because it allows all of the workstations to + share the cache of the recursive name server and hence + reduce the number of domain requests exported by the + local network. + + + +Internet Engineering Task Force [Page 74] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + At a minimum, the stub resolver MUST be capable of + directing its requests to redundant recursive name + servers. Note that recursive name servers are allowed + to restrict the sources of requests that they will + honor, so the host administrator must verify that the + service will be provided. Stub resolvers MAY implement + caching if they choose, but if so, MUST timeout cached + information. + + + 6.1.3.2 Transport Protocols + + DNS resolvers and recursive servers MUST support UDP, and + SHOULD support TCP, for sending (non-zone-transfer) queries. + Specifically, a DNS resolver or server that is sending a + non-zone-transfer query MUST send a UDP query first. If the + Answer section of the response is truncated and if the + requester supports TCP, it SHOULD try the query again using + TCP. + + DNS servers MUST be able to service UDP queries and SHOULD + be able to service TCP queries. A name server MAY limit the + resources it devotes to TCP queries, but it SHOULD NOT + refuse to service a TCP query just because it would have + succeeded with UDP. + + Truncated responses MUST NOT be saved (cached) and later + used in such a way that the fact that they are truncated is + lost. + + DISCUSSION: + UDP is preferred over TCP for queries because UDP + queries have much lower overhead, both in packet count + and in connection state. The use of UDP is essential + for heavily-loaded servers, especially the root + servers. UDP also offers additional robustness, since + a resolver can attempt several UDP queries to different + servers for the cost of a single TCP query. + + It is possible for a DNS response to be truncated, + although this is a very rare occurrence in the present + Internet DNS. Practically speaking, truncation cannot + be predicted, since it is data-dependent. The + dependencies include the number of RRs in the answer, + the size of each RR, and the savings in space realized + by the name compression algorithm. As a rule of thumb, + truncation in NS and MX lists should not occur for + answers containing 15 or fewer RRs. + + + +Internet Engineering Task Force [Page 75] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Whether it is possible to use a truncated answer + depends on the application. A mailer must not use a + truncated MX response, since this could lead to mail + loops. + + Responsible practices can make UDP suffice in the vast + majority of cases. Name servers must use compression + in responses. Resolvers must differentiate truncation + of the Additional section of a response (which only + loses extra information) from truncation of the Answer + section (which for MX records renders the response + unusable by mailers). Database administrators should + list only a reasonable number of primary names in lists + of name servers, MX alternatives, etc. + + However, it is also clear that some new DNS record + types defined in the future will contain information + exceeding the 512 byte limit that applies to UDP, and + hence will require TCP. Thus, resolvers and name + servers should implement TCP services as a backup to + UDP today, with the knowledge that they will require + the TCP service in the future. + + By private agreement, name servers and resolvers MAY arrange + to use TCP for all traffic between themselves. TCP MUST be + used for zone transfers. + + A DNS server MUST have sufficient internal concurrency that + it can continue to process UDP queries while awaiting a + response or performing a zone transfer on an open TCP + connection [DNS:2]. + + A server MAY support a UDP query that is delivered using an + IP broadcast or multicast address. However, the Recursion + Desired bit MUST NOT be set in a query that is multicast, + and MUST be ignored by name servers receiving queries via a + broadcast or multicast address. A host that sends broadcast + or multicast DNS queries SHOULD send them only as occasional + probes, caching the IP address(es) it obtains from the + response(s) so it can normally send unicast queries. + + DISCUSSION: + Broadcast or (especially) IP multicast can provide a + way to locate nearby name servers without knowing their + IP addresses in advance. However, general broadcasting + of recursive queries can result in excessive and + unnecessary load on both network and servers. + + + + +Internet Engineering Task Force [Page 76] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.3 Efficient Resource Usage + + The following requirements on servers and resolvers are very + important to the health of the Internet as a whole, + particularly when DNS services are invoked repeatedly by + higher level automatic servers, such as mailers. + + (1) The resolver MUST implement retransmission controls to + insure that it does not waste communication bandwidth, + and MUST impose finite bounds on the resources consumed + to respond to a single request. See [DNS:2] pages 43- + 44 for specific recommendations. + + (2) After a query has been retransmitted several times + without a response, an implementation MUST give up and + return a soft error to the application. + + (3) All DNS name servers and resolvers SHOULD cache + temporary failures, with a timeout period of the order + of minutes. + + DISCUSSION: + This will prevent applications that immediately + retry soft failures (in violation of Section 2.2 + of this document) from generating excessive DNS + traffic. + + (4) All DNS name servers and resolvers SHOULD cache + negative responses that indicate the specified name, or + data of the specified type, does not exist, as + described in [DNS:2]. + + (5) When a DNS server or resolver retries a UDP query, the + retry interval SHOULD be constrained by an exponential + backoff algorithm, and SHOULD also have upper and lower + bounds. + + IMPLEMENTATION: + A measured RTT and variance (if available) should + be used to calculate an initial retransmission + interval. If this information is not available, a + default of no less than 5 seconds should be used. + Implementations may limit the retransmission + interval, but this limit must exceed twice the + Internet maximum segment lifetime plus service + delay at the name server. + + (6) When a resolver or server receives a Source Quench for + + + +Internet Engineering Task Force [Page 77] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query it has issued, it SHOULD take steps to reduce + the rate of querying that server in the near future. A + server MAY ignore a Source Quench that it receives as + the result of sending a response datagram. + + IMPLEMENTATION: + One recommended action to reduce the rate is to + send the next query attempt to an alternate + server, if there is one available. Another is to + backoff the retry interval for the same server. + + + 6.1.3.4 Multihomed Hosts + + When the host name-to-address function encounters a host + with multiple addresses, it SHOULD rank or sort the + addresses using knowledge of the immediately connected + network number(s) and any other applicable performance or + history information. + + DISCUSSION: + The different addresses of a multihomed host generally + imply different Internet paths, and some paths may be + preferable to others in performance, reliability, or + administrative restrictions. There is no general way + for the domain system to determine the best path. A + recommended approach is to base this decision on local + configuration information set by the system + administrator. + + IMPLEMENTATION: + The following scheme has been used successfully: + + (a) Incorporate into the host configuration data a + Network-Preference List, that is simply a list of + networks in preferred order. This list may be + empty if there is no preference. + + (b) When a host name is mapped into a list of IP + addresses, these addresses should be sorted by + network number, into the same order as the + corresponding networks in the Network-Preference + List. IP addresses whose networks do not appear + in the Network-Preference List should be placed at + the end of the list. + + + + + + +Internet Engineering Task Force [Page 78] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + 6.1.3.5 Extensibility + + DNS software MUST support all well-known, class-independent + formats [DNS:2], and SHOULD be written to minimize the + trauma associated with the introduction of new well-known + types and local experimentation with non-standard types. + + DISCUSSION: + The data types and classes used by the DNS are + extensible, and thus new types will be added and old + types deleted or redefined. Introduction of new data + types ought to be dependent only upon the rules for + compression of domain names inside DNS messages, and + the translation between printable (i.e., master file) + and internal formats for Resource Records (RRs). + + Compression relies on knowledge of the format of data + inside a particular RR. Hence compression must only be + used for the contents of well-known, class-independent + RRs, and must never be used for class-specific RRs or + RR types that are not well-known. The owner name of an + RR is always eligible for compression. + + A name server may acquire, via zone transfer, RRs that + the server doesn't know how to convert to printable + format. A resolver can receive similar information as + the result of queries. For proper operation, this data + must be preserved, and hence the implication is that + DNS software cannot use textual formats for internal + storage. + + The DNS defines domain name syntax very generally -- a + string of labels each containing up to 63 8-bit octets, + separated by dots, and with a maximum total of 255 + octets. Particular applications of the DNS are + permitted to further constrain the syntax of the domain + names they use, although the DNS deployment has led to + some applications allowing more general names. In + particular, Section 2.1 of this document liberalizes + slightly the syntax of a legal Internet host name that + was defined in RFC-952 [DNS:4]. + + 6.1.3.6 Status of RR Types + + Name servers MUST be able to load all RR types except MD and + MF from configuration files. The MD and MF types are + obsolete and MUST NOT be implemented; in particular, name + servers MUST NOT load these types from configuration files. + + + +Internet Engineering Task Force [Page 79] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + DISCUSSION: + The RR types MB, MG, MR, NULL, MINFO and RP are + considered experimental, and applications that use the + DNS cannot expect these RR types to be supported by + most domains. Furthermore these types are subject to + redefinition. + + The TXT and WKS RR types have not been widely used by + Internet sites; as a result, an application cannot rely + on the the existence of a TXT or WKS RR in most + domains. + + 6.1.3.7 Robustness + + DNS software may need to operate in environments where the + root servers or other servers are unavailable due to network + connectivity or other problems. In this situation, DNS name + servers and resolvers MUST continue to provide service for + the reachable part of the name space, while giving temporary + failures for the rest. + + DISCUSSION: + Although the DNS is meant to be used primarily in the + connected Internet, it should be possible to use the + system in networks which are unconnected to the + Internet. Hence implementations must not depend on + access to root servers before providing service for + local names. + + 6.1.3.8 Local Host Table + + DISCUSSION: + A host may use a local host table as a backup or + supplement to the DNS. This raises the question of + which takes precedence, the DNS or the host table; the + most flexible approach would make this a configuration + option. + + Typically, the contents of such a supplementary host + table will be determined locally by the site. However, + a publically-available table of Internet hosts is + maintained by the DDN Network Information Center (DDN + NIC), with a format documented in [DNS:4]. This table + can be retrieved from the DDN NIC using a protocol + described in [DNS:5]. It must be noted that this table + contains only a small fraction of all Internet hosts. + Hosts using this protocol to retrieve the DDN NIC host + table should use the VERSION command to check if the + + + +Internet Engineering Task Force [Page 80] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + table has changed before requesting the entire table + with the ALL command. The VERSION identifier should be + treated as an arbitrary string and tested only for + equality; no numerical sequence may be assumed. + + The DDN NIC host table includes administrative + information that is not needed for host operation and + is therefore not currently included in the DNS + database; examples include network and gateway entries. + However, much of this additional information will be + added to the DNS in the future. Conversely, the DNS + provides essential services (in particular, MX records) + that are not available from the DDN NIC host table. + + 6.1.4 DNS USER INTERFACE + + 6.1.4.1 DNS Administration + + This document is concerned with design and implementation + issues in host software, not with administrative or + operational issues. However, administrative issues are of + particular importance in the DNS, since errors in particular + segments of this large distributed database can cause poor + or erroneous performance for many sites. These issues are + discussed in [DNS:6] and [DNS:7]. + + 6.1.4.2 DNS User Interface + + Hosts MUST provide an interface to the DNS for all + application programs running on the host. This interface + will typically direct requests to a system process to + perform the resolver function [DNS:1, 6.1:2]. + + At a minimum, the basic interface MUST support a request for + all information of a specific type and class associated with + a specific name, and it MUST return either all of the + requested information, a hard error code, or a soft error + indication. When there is no error, the basic interface + returns the complete response information without + modification, deletion, or ordering, so that the basic + interface will not need to be changed to accommodate new + data types. + + DISCUSSION: + The soft error indication is an essential part of the + interface, since it may not always be possible to + access particular information from the DNS; see Section + 6.1.3.3. + + + +Internet Engineering Task Force [Page 81] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + A host MAY provide other DNS interfaces tailored to + particular functions, transforming the raw domain data into + formats more suited to these functions. In particular, a + host MUST provide a DNS interface to facilitate translation + between host addresses and host names. + + 6.1.4.3 Interface Abbreviation Facilities + + User interfaces MAY provide a method for users to enter + abbreviations for commonly-used names. Although the + definition of such methods is outside of the scope of the + DNS specification, certain rules are necessary to insure + that these methods allow access to the entire DNS name space + and to prevent excessive use of Internet resources. + + If an abbreviation method is provided, then: + + (a) There MUST be some convention for denoting that a name + is already complete, so that the abbreviation method(s) + are suppressed. A trailing dot is the usual method. + + (b) Abbreviation expansion MUST be done exactly once, and + MUST be done in the context in which the name was + entered. + + + DISCUSSION: + For example, if an abbreviation is used in a mail + program for a destination, the abbreviation should be + expanded into a full domain name and stored in the + queued message with an indication that it is already + complete. Otherwise, the abbreviation might be + expanded with a mail system search list, not the + user's, or a name could grow due to repeated + canonicalizations attempts interacting with wildcards. + + The two most common abbreviation methods are: + + (1) Interface-level aliases + + Interface-level aliases are conceptually implemented as + a list of alias/domain name pairs. The list can be + per-user or per-host, and separate lists can be + associated with different functions, e.g. one list for + host name-to-address translation, and a different list + for mail domains. When the user enters a name, the + interface attempts to match the name to the alias + component of a list entry, and if a matching entry can + + + +Internet Engineering Task Force [Page 82] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + be found, the name is replaced by the domain name found + in the pair. + + Note that interface-level aliases and CNAMEs are + completely separate mechanisms; interface-level aliases + are a local matter while CNAMEs are an Internet-wide + aliasing mechanism which is a required part of any DNS + implementation. + + (2) Search Lists + + A search list is conceptually implemented as an ordered + list of domain names. When the user enters a name, the + domain names in the search list are used as suffixes to + the user-supplied name, one by one, until a domain name + with the desired associated data is found, or the + search list is exhausted. Search lists often contain + the name of the local host's parent domain or other + ancestor domains. Search lists are often per-user or + per-process. + + It SHOULD be possible for an administrator to disable a + DNS search-list facility. Administrative denial may be + warranted in some cases, to prevent abuse of the DNS. + + There is danger that a search-list mechanism will + generate excessive queries to the root servers while + testing whether user input is a complete domain name, + lacking a final period to mark it as complete. A + search-list mechanism MUST have one of, and SHOULD have + both of, the following two provisions to prevent this: + + (a) The local resolver/name server can implement + caching of negative responses (see Section + 6.1.3.3). + + (b) The search list expander can require two or more + interior dots in a generated domain name before it + tries using the name in a query to non-local + domain servers, such as the root. + + DISCUSSION: + The intent of this requirement is to avoid + excessive delay for the user as the search list is + tested, and more importantly to prevent excessive + traffic to the root and other high-level servers. + For example, if the user supplied a name "X" and + the search list contained the root as a component, + + + +Internet Engineering Task Force [Page 83] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + a query would have to consult a root server before + the next search list alternative could be tried. + The resulting load seen by the root servers and + gateways near the root would be multiplied by the + number of hosts in the Internet. + + The negative caching alternative limits the effect + to the first time a name is used. The interior + dot rule is simpler to implement but can prevent + easy use of some top-level names. + + + 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +GENERAL ISSUES | | | | | | | + | | | | | | | +Implement DNS name-to-address conversion |6.1.1 |x| | | | | +Implement DNS address-to-name conversion |6.1.1 |x| | | | | +Support conversions using host table |6.1.1 | | |x| | | +Properly handle RR with zero TTL |6.1.2.1 |x| | | | | +Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | + Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | +Unused fields zero |6.1.2.3 |x| | | | | +Use compression in responses |6.1.2.4 |x| | | | | + | | | | | | | +Include config info in responses |6.1.2.5 | | | | |x| +Support all well-known, class-indep. types |6.1.3.5 |x| | | | | +Easily expand type list |6.1.3.5 | |x| | | | +Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | +Load MD or MF type |6.1.3.6 | | | | |x| +Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOLVER ISSUES: | | | | | | | + | | | | | | | +Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | +Full-service resolver: |6.1.3.1 | | |x| | | + Local caching |6.1.3.1 |x| | | | | + + + +Internet Engineering Task Force [Page 84] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Information in local cache times out |6.1.3.1 |x| | | | | + Configurable with starting info |6.1.3.1 | |x| | | | +Stub resolver: |6.1.3.1 | | |x| | | + Use redundant recursive name servers |6.1.3.1 |x| | | | | + Local caching |6.1.3.1 | | |x| | | + Information in local cache times out |6.1.3.1 |x| | | | | +Support for remote multi-homed hosts: | | | | | | | + Sort multiple addresses by preference list |6.1.3.4 | |x| | | | + | | | | | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +TRANSPORT PROTOCOLS: | | | | | | | + | | | | | | | +Support UDP queries |6.1.3.2 |x| | | | | +Support TCP queries |6.1.3.2 | |x| | | | + Send query using UDP first |6.1.3.2 |x| | | | |1 + Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | +Name server limit TCP query resources |6.1.3.2 | | |x| | | + Punish unnecessary TCP query |6.1.3.2 | | | |x| | +Use truncated data as if it were not |6.1.3.2 | | | | |x| +Private agreement to use only TCP |6.1.3.2 | | |x| | | +Use TCP for zone transfers |6.1.3.2 |x| | | | | +TCP usage not block UDP queries |6.1.3.2 |x| | | | | +Support broadcast or multicast queries |6.1.3.2 | | |x| | | + RD bit set in query |6.1.3.2 | | | | |x| + RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | + Send only as occasional probe for addr's |6.1.3.2 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +RESOURCE USAGE: | | | | | | | + | | | | | | | +Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | + Finite bounds per request |6.1.3.3 |x| | | | | +Failure after retries => soft error |6.1.3.3 |x| | | | | +Cache temporary failures |6.1.3.3 | |x| | | | +Cache negative responses |6.1.3.3 | |x| | | | +Retries use exponential backoff |6.1.3.3 | |x| | | | + Upper, lower bounds |6.1.3.3 | |x| | | | +Client handle Source Quench |6.1.3.3 | |x| | | | +Server ignore Source Quench |6.1.3.3 | | |x| | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +USER INTERFACE: | | | | | | | + | | | | | | | +All programs have access to DNS interface |6.1.4.2 |x| | | | | +Able to request all info for given name |6.1.4.2 |x| | | | | +Returns complete info or error |6.1.4.2 |x| | | | | +Special interfaces |6.1.4.2 | | |x| | | + Name<->Address translation |6.1.4.2 |x| | | | | + | | | | | | | +Abbreviation Facilities: |6.1.4.3 | | |x| | | + + + +Internet Engineering Task Force [Page 85] + + + + +RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 + + + Convention for complete names |6.1.4.3 |x| | | | | + Conversion exactly once |6.1.4.3 |x| | | | | + Conversion in proper context |6.1.4.3 |x| | | | | + Search list: |6.1.4.3 | | |x| | | + Administrator can disable |6.1.4.3 | |x| | | | + Prevention of excessive root queries |6.1.4.3 |x| | | | | + Both methods |6.1.4.3 | |x| | | | +-----------------------------------------------|-----------|-|-|-|-|-|-- +-----------------------------------------------|-----------|-|-|-|-|-|-- + +1. Unless there is private agreement between particular resolver and + particular server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 86] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + 6.2 HOST INITIALIZATION + + 6.2.1 INTRODUCTION + + This section discusses the initialization of host software + across a connected network, or more generally across an + Internet path. This is necessary for a diskless host, and may + optionally be used for a host with disk drives. For a diskless + host, the initialization process is called "network booting" + and is controlled by a bootstrap program located in a boot ROM. + + To initialize a diskless host across the network, there are two + distinct phases: + + (1) Configure the IP layer. + + Diskless machines often have no permanent storage in which + to store network configuration information, so that + sufficient configuration information must be obtained + dynamically to support the loading phase that follows. + This information must include at least the IP addresses of + the host and of the boot server. To support booting + across a gateway, the address mask and a list of default + gateways are also required. + + (2) Load the host system code. + + During the loading phase, an appropriate file transfer + protocol is used to copy the system code across the + network from the boot server. + + A host with a disk may perform the first step, dynamic + configuration. This is important for microcomputers, whose + floppy disks allow network configuration information to be + mistakenly duplicated on more than one host. Also, + installation of new hosts is much simpler if they automatically + obtain their configuration information from a central server, + saving administrator time and decreasing the probability of + mistakes. + + 6.2.2 REQUIREMENTS + + 6.2.2.1 Dynamic Configuration + + A number of protocol provisions have been made for dynamic + configuration. + + o ICMP Information Request/Reply messages + + + +Internet Engineering Task Force [Page 87] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + This obsolete message pair was designed to allow a host + to find the number of the network it is on. + Unfortunately, it was useful only if the host already + knew the host number part of its IP address, + information that hosts requiring dynamic configuration + seldom had. + + o Reverse Address Resolution Protocol (RARP) [BOOT:4] + + RARP is a link-layer protocol for a broadcast medium + that allows a host to find its IP address given its + link layer address. Unfortunately, RARP does not work + across IP gateways and therefore requires a RARP server + on every network. In addition, RARP does not provide + any other configuration information. + + o ICMP Address Mask Request/Reply messages + + These ICMP messages allow a host to learn the address + mask for a particular network interface. + + o BOOTP Protocol [BOOT:2] + + This protocol allows a host to determine the IP + addresses of the local host and the boot server, the + name of an appropriate boot file, and optionally the + address mask and list of default gateways. To locate a + BOOTP server, the host broadcasts a BOOTP request using + UDP. Ad hoc gateway extensions have been used to + transmit the BOOTP broadcast through gateways, and in + the future the IP Multicasting facility will provide a + standard mechanism for this purpose. + + + The suggested approach to dynamic configuration is to use + the BOOTP protocol with the extensions defined in "BOOTP + Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 + defines some important general (not vendor-specific) + extensions. In particular, these extensions allow the + address mask to be supplied in BOOTP; we RECOMMEND that the + address mask be supplied in this manner. + + DISCUSSION: + Historically, subnetting was defined long after IP, and + so a separate mechanism (ICMP Address Mask messages) + was designed to supply the address mask to a host. + However, the IP address mask and the corresponding IP + address conceptually form a pair, and for operational + + + +Internet Engineering Task Force [Page 88] + + + + +RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 + + + simplicity they ought to be defined at the same time + and by the same mechanism, whether a configuration file + or a dynamic mechanism like BOOTP. + + Note that BOOTP is not sufficiently general to specify + the configurations of all interfaces of a multihomed + host. A multihomed host must either use BOOTP + separately for each interface, or configure one + interface using BOOTP to perform the loading, and + perform the complete initialization from a file later. + + Application layer configuration information is expected + to be obtained from files after loading of the system + code. + + 6.2.2.2 Loading Phase + + A suggested approach for the loading phase is to use TFTP + [BOOT:1] between the IP addresses established by BOOTP. + + TFTP to a broadcast address SHOULD NOT be used, for reasons + explained in Section 4.2.3.4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 89] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + 6.3 REMOTE MANAGEMENT + + 6.3.1 INTRODUCTION + + The Internet community has recently put considerable effort + into the development of network management protocols. The + result has been a two-pronged approach [MGT:1, MGT:6]: the + Simple Network Management Protocol (SNMP) [MGT:4] and the + Common Management Information Protocol over TCP (CMOT) [MGT:5]. + + In order to be managed using SNMP or CMOT, a host will need to + implement an appropriate management agent. An Internet host + SHOULD include an agent for either SNMP or CMOT. + + Both SNMP and CMOT operate on a Management Information Base + (MIB) that defines a collection of management values. By + reading and setting these values, a remote application may + query and change the state of the managed system. + + A standard MIB [MGT:3] has been defined for use by both + management protocols, using data types defined by the Structure + of Management Information (SMI) defined in [MGT:2]. Additional + MIB variables can be introduced under the "enterprises" and + "experimental" subtrees of the MIB naming space [MGT:2]. + + Every protocol module in the host SHOULD implement the relevant + MIB variables. A host SHOULD implement the MIB variables as + defined in the most recent standard MIB, and MAY implement + other MIB variables when appropriate and useful. + + 6.3.2 PROTOCOL WALK-THROUGH + + The MIB is intended to cover both hosts and gateways, although + there may be detailed differences in MIB application to the two + cases. This section contains the appropriate interpretation of + the MIB for hosts. It is likely that later versions of the MIB + will include more entries for host management. + + A managed host must implement the following groups of MIB + object definitions: System, Interfaces, Address Translation, + IP, ICMP, TCP, and UDP. + + The following specific interpretations apply to hosts: + + o ipInHdrErrors + + Note that the error "time-to-live exceeded" can occur in a + host only when it is forwarding a source-routed datagram. + + + +Internet Engineering Task Force [Page 90] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + o ipOutNoRoutes + + This object counts datagrams discarded because no route + can be found. This may happen in a host if all the + default gateways in the host's configuration are down. + + o ipFragOKs, ipFragFails, ipFragCreates + + A host that does not implement intentional fragmentation + (see "Fragmentation" section of [INTRO:1]) MUST return the + value zero for these three objects. + + o icmpOutRedirects + + For a host, this object MUST always be zero, since hosts + do not send Redirects. + + o icmpOutAddrMaskReps + + For a host, this object MUST always be zero, unless the + host is an authoritative source of address mask + information. + + o ipAddrTable + + For a host, the "IP Address Table" object is effectively a + table of logical interfaces. + + o ipRoutingTable + + For a host, the "IP Routing Table" object is effectively a + combination of the host's Routing Cache and the static + route table described in "Routing Outbound Datagrams" + section of [INTRO:1]. + + Within each ipRouteEntry, ipRouteMetric1...4 normally will + have no meaning for a host and SHOULD always be -1, while + ipRouteType will normally have the value "remote". + + If destinations on the connected network do not appear in + the Route Cache (see "Routing Outbound Datagrams section + of [INTRO:1]), there will be no entries with ipRouteType + of "direct". + + + DISCUSSION: + The current MIB does not include Type-of-Service in an + ipRouteEntry, but a future revision is expected to make + + + +Internet Engineering Task Force [Page 91] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + this addition. + + We also expect the MIB to be expanded to allow the remote + management of applications (e.g., the ability to partially + reconfigure mail systems). Network service applications + such as mail systems should therefore be written with the + "hooks" for remote management. + + 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY + + | | | | |S| | + | | | | |H| |F + | | | | |O|M|o + | | |S| |U|U|o + | | |H| |L|S|t + | |M|O| |D|T|n + | |U|U|M| | |o + | |S|L|A|N|N|t + | |T|D|Y|O|O|t +FEATURE |SECTION | | | |T|T|e +-----------------------------------------------|-----------|-|-|-|-|-|-- +Support SNMP or CMOT agent |6.3.1 | |x| | | | +Implement specified objects in standard MIB |6.3.1 | |x| | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 92] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +7. REFERENCES + + This section lists the primary references with which every + implementer must be thoroughly familiar. It also lists some + secondary references that are suggested additional reading. + + INTRODUCTORY REFERENCES: + + + [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," + IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, + October 1989. + + [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, + (three volumes), SRI International, December 1985. + + [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, + RFC-1011, May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. + Postel, RFC-980, March 1986. + + [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, + May 1987. + + This document is republished periodically with new RFC numbers; + the latest version must be used. + + + TELNET REFERENCES: + + + [TELNET:1] "Telnet Protocol Specification," J. Postel and J. + Reynolds, RFC-854, May 1983. + + [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, + RFC-855, May 1983. + + [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, + RFC-856, May 1983. + + [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, + May 1983. + + [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. + + + +Internet Engineering Task Force [Page 93] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + Reynolds, RFC-858, May 1983. + + [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- + 859, May 1983. + + [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, + RFC-860, May 1983. + + [TELNET:8] "Telnet Extended Options List," J. Postel and J. + Reynolds, RFC-861, May 1983. + + [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, + December 1983. + + [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, + February 1989. + + This document supercedes RFC-930. + + [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, + October 1988. + + [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August + 1989. + + [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, + December 1988. + + [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- + 1080, November 1988. + + + SECONDARY TELNET REFERENCES: + + + [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of + Defense, May 1984. + + This document is intended to describe the same protocol as RFC- + 854. In case of conflict, RFC-854 takes precedence, and the + present document takes precedence over both. + + [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. + + [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October + 1977. + + [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. + + + +Internet Engineering Task Force [Page 94] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS + Implementation," A. Yasuda and T. Thompson, RFC-1043, February + 1988. + + + FTP REFERENCES: + + + [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- + 959, October 1985. + + [FTP:2] "Document File Format Standards," J. Postel, RFC-678, + December 1974. + + [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of + Defense, May 1984. + + This document is based on an earlier version of the FTP + specification (RFC-765) and is obsolete. + + + TFTP REFERENCES: + + + [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June + 1981. + + + MAIL REFERENCES: + + + [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August + 1982. + + [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," + D. Crocker, RFC-822, August 1982. + + This document obsoleted an earlier specification, RFC-733. + + [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- + 974, January 1986. + + This RFC describes the use of MX records, a mandatory extension + to the mail delivery process. + + [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, + February 1988. + + + + +Internet Engineering Task Force [Page 95] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, + June 1986. + + [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. + + The two preceding RFC's define a proposed standard for + gatewaying mail between the Internet and the X.400 environments. + + [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. + Department of Defense, May 1984. + + This specification is intended to describe the same protocol as + does RFC-821. However, MIL-STD-1781 is incomplete; in + particular, it does not include MX records [SMTP:3]. + + [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, + RFC-1049, March 1988. + + + DOMAIN NAME SYSTEM REFERENCES: + + + [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, + RFC-1034, November 1987. + + This document and the following one obsolete RFC-882, RFC-883, + and RFC-973. + + [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, + P. Mockapetris, November 1987. + + + [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, + January 1986. + + + [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, + RFC-952, M. Stahl, E. Feinler, October 1985. + + SECONDARY DNS REFERENCES: + + + [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, + RFC-953, October 1985. + + [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November + 1987. + + + + +Internet Engineering Task Force [Page 96] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + + [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- + 1033, November 1987. + + [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet + Protocol Handbook, NIC 50007, SRI Network Information Center, + August 1989. + + + SYSTEM INITIALIZATION REFERENCES: + + + [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June + 1984. + + [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- + 951, September 1985. + + [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- + 1084, December 1988. + + Note: this RFC revised and obsoleted RFC-1048. + + [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. + Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. + + + MANAGEMENT REFERENCES: + + + [MGT:1] "IAB Recommendations for the Development of Internet Network + Management Standards," V. Cerf, RFC-1052, April 1988. + + [MGT:2] "Structure and Identification of Management Information for + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, + August 1988. + + [MGT:3] "Management Information Base for Network Management of + TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, + August 1988. + + [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, + M. Schoffstall, and C. Davin, RFC-1098, April 1989. + + [MGT:5] "The Common Management Information Services and Protocol + over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. + + [MGT:6] "Report of the Second Ad Hoc Network Management Review + Group," V. Cerf, RFC-1109, August 1989. + + + +Internet Engineering Task Force [Page 97] + + + + +RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 + + +Security Considerations + + There are many security issues in the application and support + programs of host software, but a full discussion is beyond the scope + of this RFC. Security-related issues are mentioned in sections + concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and + EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the + SMTP DATA command (Section 5.2.8). + +Author's Address + + Robert Braden + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292-6695 + + Phone: (213) 822 1511 + + EMail: Braden@ISI.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Internet Engineering Task Force [Page 98] + diff --git a/RFC/rfc1176.txt b/RFC/rfc1176.txt new file mode 100644 index 00000000..1ea72a11 --- /dev/null +++ b/RFC/rfc1176.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 1176 Washington +Obsoletes: RFC 1064 August 1990 + + + INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2 + + +Status of this Memo + + This RFC suggests a method for personal computers and workstations to + dynamically access mail from a mailbox server ("repository"). It + obosoletes RFC 1064. This RFC specifies an Experimental Protocol for + the Internet community. Discussion and suggestions for improvement + are requested. Please refer to the current edition of the "IAB + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Introduction + + The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2) + is to allow a workstation, personal computer, or similar small + machine to access electronic mail from a mailbox server. Since the + distinction between personal computers and workstations is blurring + over time, it is desirable to have a single solution that addresses + the need in a general fashion. IMAP2 is the "glue" of a distributed + electronic mail system consisting of a family of client and server + implementations on a wide variety of platforms, from small single- + tasking personal computing engines to complex multi-user timesharing + systems. + + Although different in many ways from the Post Office Protocols (POP2 + and POP3, hereafter referred to collectively as "POP") described in + RFC 937 and RFC 1081, IMAP2 may be thought of as a functional + superset of these. RFC 937 was used as a model for this RFC. There + was a cognizant reason for this; POP deals with a similar problem, + albeit with a less comprehensive solution, and it was desirable to + offer a basis for comparison. + + Like POP, IMAP2 specifies a means of accessing stored mail and not of + posting mail; this function is handled by a mail transfer protocol + such as SMTP (RFC 821). + + This protocol assumes a reliable data stream such as provided by TCP + or any similar protocol. When TCP is used, the IMAP2 server listens + on port 143. + + + + + +Crispin [Page 1] + +RFC 1176 IMAP2 August 1990 + + +System Model and Philosophy + + Electronic mail is a primary means of communication for the widely + spread Internet community. The advent of distributed personal + computers and workstations has forced a significant rethinking of the + mechanisms employed to manage electronic mail. With mainframes, each + user tends to receive and process mail at the computer he uses most + of the time, his "primary host". The first inclination of many users + when an independent workstation is placed in front of them is to + begin receiving mail at the workstation, and many vendors have + implemented facilities to do this. However, this approach has + several disadvantages: + + (1) Personal computers and many workstations have a software + design that gives full control of all aspects of the system to the + user at the console. As a result, background tasks such as + receiving mail may not run for long periods of time; either + because the user is asking to use all the machine's resources, or + because the user has (perhaps accidentally) manipulated the + environment in such a way that it prevents mail reception. In + many personal computers, the operating system is single-tasking + and this is the only mode of operation. Any of these conditions + could lead to repeated failed delivery attempts by outside agents. + + (2) The hardware failure of a single machine can keep its user + "off the air" for a considerable time, since repair of individual + units may be delayed. Given the growing number of personal + computers and workstations spread throughout office environments, + quick repair of such systems is not assured. On the other hand, a + central mainframe is generally repaired soon after failure. + + (3) Personal computers and workstations are often not backed up + with as much diligence as a central mainframe, if at all. + + (4) It is more difficult to keep track of mailing addresses when + each person is associated with a distinct machine. Consider the + difficulty in keeping track of many postal addresses or phone + numbers, particularly if there was no single address or phone + number for an organization through which you could reach any + person in that organization. Traditionally, electronic mail on + the ARPANET involved remembering a name and one of several "hosts" + (machines) whose name reflected the organization in which the + individual worked. This was suitable at a time when most + organizations had only one central host. It is less satisfactory + today unless the concept of a host is changed to refer to an + organizational entity and not a particular machine. + + (5) It is difficult to keep a multitude of heterogeneous machines + + + +Crispin [Page 2] + +RFC 1176 IMAP2 August 1990 + + + working properly with complex mailing protocols, making it + difficult to move forward as progress is made in electronic + communication and as new standards emerge. Each system has to + worry about receiving incoming mail, routing and delivering + outgoing mail, formatting, storing, and providing for the + stability of mailboxes over a variety of possible filing and + mailing protocols. + + Consequently, while a personal computer or workstation may be viewed + as an Internet host in the sense that it implements TCP/IP, it should + not be viewed as the entity that contains the user's mailbox. + Instead, a mail server machine ("server", sometimes called a + "repository") should hold the mailbox, and the personal computer or + workstation (hereafter referred to as a "client") should access the + mailbox via mail transactions. + + Because the mail server machine is isolated from direct user + manipulation, it should achieve high software reliability easily, + and, as a shared resource, it should also achieve high hardware + reliability, perhaps through redundancy. The mail server may be + accessed from arbitrary locations, allowing users to read mail across + campus, town, or country using commonly available clients. + Furthermore, the same user may access his mailbox from different + clients at different times, and multiple users may access the same + mailbox simultaneously. + + The mail server acts an an interface among users, data storage, and + other mailers. A mail access protocol retrieves messages, accesss + and changes properties of messages, and otherwise manages mailboxes. + This differs from some approaches (e.g., Unix mail via NFS) in that + the mail access protocol is used for all message manipulations, + isolating the user and the client from all knowledge of how the data + storage is used. This means that the mail server can use the data + storage in whatever way is most efficient to organize the mail in + that particular environment, without having to worry about storage + representation compatibility across different machines. + + A mail access protocol further differs in that it transmits + information only on demand. A well-designed mail access protocol + requires considerably less network traffic than Unix mail via NFS, + particularly when the mail file is large. The result is that a mail + access protocol can scale well to situations of large mailboxes or + networks with high latency or low speed. + + In defining a mail access protocol, it is important to keep in mind + that the client and server form a macrosystem, in which it should be + possible to exploit the strong points of both while compensating for + each other's weaknesses. Furthermore, it is desirable to allow for a + + + +Crispin [Page 3] + +RFC 1176 IMAP2 August 1990 + + + growth path beyond the hoary text-only RFC 822 protocol, specifically + in the area of attachments and multi-media mail, to ease the eventual + transition to ISO solutions. + + Unlike POP, IMAP2 has extensive features for remote searching and + parsing of messages on the server. A free text search (optionally + with other searching) can be made in the entire mailbox by the server + and the results made available to the client without the client + having to transfer the entire mailbox and searching itself. Since + remote parsing of a message into a structured (and standard format) + "envelope" is available, a client can display envelope information + and implement commands such as REPLY without having any understanding + of how to parse RFC 822, etc. headers. The effect of this is + twofold: it further improves the ability to scale well in instances + where network traffic must be reduced, and it reduces the complexity + of the client program. + + Additionally, IMAP2 offers several facilities for managing individual + message state and the mailbox as a whole beyond the simple "delete + message" functionality of POP. Another benefit of IMAP2 is the use + of tagged responses to reduce the possibility of synchronization + errors and the concept of state on the client (a "local cache") that + the server may update without explicit request by the client. These + concepts and how they are used are explained under "Implementation + Discussion" below. + + In spite of this functional richness, IMAP2 is a small protocol. + Although servers should implement the full set of IMAP2 functions, a + simple client can be written that uses IMAP2 in much the way as a POP + client. + + A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL + (RFC 1056). IMAP2 differs from DMSP more fundamentally, reflecting a + differing architecture from PCMAIL. PCMAIL is either an online + ("interactive mode"), or offline ("batch mode") system with long-term + shared state. Some POP based systems are also offline; in such + systems, since there is no long-term shared state POP is little more + than a download mechanism of the "mail file" to the client. IMAP2- + based software is primarily an online system in which real-time and + simultaneous mail access were considered important. + + In PCMAIL, there is a long-term client/server relationship in which + some mailbox state is preserved on the client. There is a + registration of clients used by a particular user, and the client + keeps a set of "descriptors" for each message that summarize the + message. The server and client synchronize their states when the + DMSP connection starts up, and, if a client has not accessed the + server for a while, the client does a complete reset (reload) of its + + + +Crispin [Page 4] + +RFC 1176 IMAP2 August 1990 + + + state from the server. + + In IMAP2-based software, the client/server relationship lasts only + for the duration of the TCP connection. All mailbox state is + maintained on the server. There is no registration of clients. The + function of a descriptor is handled by a structured representation of + the message "envelope" as noted above. There is no client/server + synchronization since the client does not remember state between + IMAP2 connections. This is not a problem since in general the client + never needs the entire state of the mailbox in a single session, + therefore there isn't much overhead in fetching the state information + that is needed as it is needed. + + There are also some functional differences between IMAP2 and DMSP. + DMSP has functions for sending messages, printing messages, listing + mailboxes, and changing passwords; these are done outside IMAP2. + DMSP has 16 binary flags of which 8 are defined by the system. IMAP2 + has flag names; there are currently 5 defined system flag names and a + facility for some number (30 in the current implementations) of user + flag names. IMAP2 has a sophisticated message search facility in the + server to identify interesting messages based on dates, addresses, + flag status, or textual contents without compelling the client to + fetch this data for every message. + + It was felt that maintaining state on the client is advantageous only + in those cases where the client is only used by a single user, or if + there is some means on the client to restrict access to another + user's data. It can be a serious disadvantage in an environment in + which multiple users routinely use the same client, the same user + routinely uses different clients, and where there are no access + restrictions on the client. It was also observed that most user mail + access is to a small set of "interesting" messages, which were either + new mail or mail based on some user-selected criteria. Consequently, + IMAP2 was designed to easily identify those "interesting" messages so + that the client could fetch the state of those messages and not those + that were not "interesting". + +The Protocol + + The IMAP2 protocol consists of a sequence of client commands and + server responses, with server data interspersed between the + responses. Unlike most Internet protocols, commands and responses + are tagged. That is, a command begins with a unique identifier + (typically a short alphanumeric sequence such as a Lisp "gensym" + function would generate e.g., A0001, A0002, etc.), called a tag. The + response to this command is given the same tag from the server. + Additionally, the server may send an arbitrary amount of "unsolicited + data", which is identified by the special reserved tag of "*". There + + + +Crispin [Page 5] + +RFC 1176 IMAP2 August 1990 + + + is another special reserved tag, "+", discussed below. + + The server must be listening for a connection. When a connection is + opened the server sends an unsolicited OK response as a greeting + message and then waits for commands. + + The client opens a connection and waits for the greeting. The client + must not send any commands until it has received the greeting from + the server. + + Once the greeting has been received, the client may begin sending + commands and is not under any obligation to wait for a server + response to this command before sending another command, within the + constraints of TCP flow control. When commands are received the + server acts on them and responds with command responses, often + interspersed with data. The effect of a command can not be + considered complete until a command response with a tag matching the + command is received from the server. + + Although all known IMAP2 servers at the time of this writing process + commands to completion before processing the next command, it is not + required that a server do so. However, many commands can affect the + results of other commands, creating processing-order dependencies + (or, for SEARCH and FIND, ambiguities about which data is associated + with which command). All implementations that operate in a non- + lockstep fashion must recognize such dependencies and defer or + synchronize execution as necessary. In general, such multi- + processing is limited to consecutive FETCH commands. + + Generally, the first command from the client is a LOGIN command with + user name and password arguments to establish identity and access + authorization, unless this has already been accomplished through + other means, e.g. Kerberos. Until identity and access authorization + have been established, no operations other than LOGIN or LOGOUT are + permitted. + + Once identity and authorization have been established, the client + must send a SELECT command to access the desired mailbox; no mailbox + is selected by default. SELECT's argument is implementation- + dependent; however the word "INBOX" must be implemented to mean the + primary or default mailbox for this user, independent of any other + server semantics. On a successful SELECT, the server will send a + list of valid flags, number of messages, and number of messages + arrived since last access for this mailbox as unsolicited data, + followed by an OK response. The client may terminate access to this + mailbox and access a different one with another SELECT command. + + The client reads mailbox information with FETCH commands. The actual + + + +Crispin [Page 6] + +RFC 1176 IMAP2 August 1990 + + + data is transmitted via the unsolicited data mechanism (that is, + FETCH should be viewed as instructing the server to include the + desired data along with any other data it wishes to transmit to the + client). There are three major categories of data that may be + fetched. + + The first category is data that is associated with a message as an + entity in the mailbox. There are now three such items of data: the + "internal date", the "RFC 822 size", and the "flags". The internal + date is the date and time that the message was placed in the mailbox. + The RFC 822 size is subject to deletion in the future; it is the size + in bytes of the message, expressed as an RFC 822 text string. + Current clients only use it as part of a status display line. The + flags are a list of status flags associated with the message (see + below). All the first category data can be fetched by using the + macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS + INTERNALDATE RFC822.SIZE)". + + The second category is that data that describes the composition and + delivery information of a message; that is, information such as the + message sender, recipient lists, message-ID, subject, etc. This is + the information that is stored in the message header in RFC 822 + format message and is traditionally called the "envelope". [Note: + this should not be confused with the SMTP (RFC 821) envelope, which + is strictly limited to delivery information.] IMAP2 defines a + structured and unambiguous representation for the envelope that is + particularly suited for Lisp-based parsers. A client can use the + envelope for operations such as replying and not worry about RFC 822 + at all. Envelopes are discussed in more detail below. The first two + categories of data can be fetched together by using the macro-fetch + word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE)". + + The third category is that data that is intended for direct human + viewing. The present RFC 822 based IMAP2 defines three such items: + RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two + former appended together in a single text string). RFC822.HEADER is + the "raw", unprocessed RFC 822 format header of the message. + Fetching "RFC822" is equivalent to fetching the RFC 822 + representation of the message as stored on the mailbox without any + filtering or processing. + + An intelligent client will "FETCH ALL" for some (or all) of the + messages in the mailbox for use as a presentation menu, and when the + user wishes to read a particular message will "FETCH RFC822.TEXT" to + get the message body. A more primitive client could, of course, + simply "FETCH RFC822" a`la POP-type functionality. + + + + +Crispin [Page 7] + +RFC 1176 IMAP2 August 1990 + + + The client can alter certain data (currently only the flags) by a + STORE command. As an example, a message is deleted from a mailbox by + a STORE command that includes the \DELETED flag as a flag being set. + + Other client operations include copying a message to another mailbox + (COPY command), permanently removing deleted messages (EXPUNGE + command), checking for new messages (CHECK command), and searching + for messages that match certain criteria (SEARCH command). + + The client terminates the session with the LOGOUT command. The + server returns a "BYE" followed by an "OK". + + A Typical Scenario + + Client Server + ------ ------ + {Wait for Connection} + {Open Connection} --> + <-- * OK IMAP2 Server Ready + {Wait for command} + A001 LOGIN Fred Secret --> + <-- A001 OK User Fred logged in + {Wait for command} + A002 SELECT INBOX --> + <-- * FLAGS (Meeting Notice \Answered + \Flagged \Deleted \Seen) + <-- * 19 EXISTS + <-- * 2 RECENT + <-- A0002 OK Select complete + {Wait for command} + A003 FETCH 1:19 ALL --> + <-- * 1 Fetch (......) + ... + <-- * 18 Fetch (......) + <-- * 19 Fetch (......) + <-- A003 OK Fetch complete + {Wait for command} + A004 FETCH 8 RFC822.TEXT --> + <-- * 8 Fetch (RFC822.TEXT {893} + ...893 characters of text... + <-- ) + <-- A004 OK Fetch complete + {Wait for command} + + + + + + + + +Crispin [Page 8] + +RFC 1176 IMAP2 August 1990 + + + A005 STORE 8 +Flags \Deleted --> + <-- * 8 Store (Flags (\Deleted + \Seen)) + <-- A005 OK Store complete + {Wait for command} + A006 EXPUNGE --> + <-- * 19 EXISTS + <-- * 8 EXPUNGE + <-- * 18 EXISTS + <-- A006 Expunge complete + {Wait for command} + A007 LOGOUT --> + <-- * BYE IMAP2 server quitting + <-- A007 OK Logout complete + {Close Connection} --><-- {Close connection} + {Go back to start} +Conventions + + The following terms are used in a meta-sense in the syntax + specification below: + + An ASCII-STRING is a sequence of arbitrary ASCII characters. + + An ATOM is a sequence of ASCII characters delimited by SP or CRLF. + + A CHARACTER is any ASCII character except """", "{", CR, LF, "%", + or "\". + + A CRLF is an ASCII carriage-return character followed immediately + by an ASCII linefeed character. + + A NUMBER is a sequence of the ASCII characters that represent + decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or + ":". + + A SP is the ASCII space character. + + A TEXT_LINE is a human-readable sequence of ASCII characters up to + but not including a terminating CRLF. + + A common field in the IMAP2 protocol is a STRING, which may be an + ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), + or a LITERAL. A literal consists of an open brace ("{"), a number, a + close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, + where n is the value of the number inside the brace. In general, a + string should be represented as an ATOM or QUOTED-STRING if at all + possible. The semantics for QUOTED-STRING or LITERAL are checked + before those for ATOM; therefore an ATOM used in a STRING may only + + + +Crispin [Page 9] + +RFC 1176 IMAP2 August 1990 + + + contain CHARACTERs. Literals are most often sent from the server to + the client; in the rare case of a client to server literal there is a + special consideration (see the "+ text" response below). + + Another important field is the SEQUENCE, which identifies a set of + messages by consecutive numbers from 1 to n where n is the number of + messages in the mailbox. A sequence may consist of a single number, + a pair of numbers delimited by colon (equivalent to all numbers + between those two numbers), or a list of single numbers or number + pairs. For example, the sequence 2,4:7,9,12:15 is equivalent to + 2,4,5,6,7,9,12,13,14,15 and identifies all those messages. + +Definitions of Commands and Responses + + Summary of Commands and Responses + + Commands || Responses + -------- || ------- + tag NOOP || tag OK text + tag LOGIN user password || tag NO text + tag LOGOUT || tag BAD text + tag SELECT mailbox || * number message_data + tag BBOARD bulletin_board || * FLAGS flag_list + tag FIND MAILBOXES pattern || * SEARCH sequence + tag FIND BBOARDS pattern || * BBOARD string + tag CHECK || * MAILBOX string + tag EXPUNGE || * BYE text + tag COPY sequence mailbox || * OK text + tag FETCH sequence data || * NO text + tag STORE sequence data value || * BAD text + tag SEARCH search_program || + text + +Commands + + tag NOOP + + The NOOP command returns an OK to the client. By itself, it does + nothing, but certain things may happen as side effects. For + example, server implementations that implicitly check the mailbox + for new mail may do so as a result of this command. The primary + use of this command is to for the client to see if the server is + still alive (and notify the server that the client is still alive, + for those servers that have inactivity autologout timers). + + tag LOGIN user password + + The LOGIN command identifies the user to the server and carries + the password authenticating this user. This information is used + + + +Crispin [Page 10] + +RFC 1176 IMAP2 August 1990 + + + by the server to control access to the mailboxes. + + EXAMPLE: A001 LOGIN SMITH SESAME + logs in as user SMITH with password SESAME. + + tag LOGOUT + + The LOGOUT command informs the server that the client is done with + the session. The server should send an unsolicited BYE response + before the (tagged) OK response, and then close the network + connection. + + tag SELECT mailbox + + The SELECT command selects a particular mailbox. The server must + check that the user is permitted read access to this mailbox. + Before returning an OK to the client, the server must send the + following unsolicited data to the client: + FLAGS mailbox's defined flags + <n> EXISTS the number of messages in the mailbox + <n> RECENT the number of new messages in the mailbox + in order to define the initial state of the mailbox at the client. + + Multiple SELECT commands are permitted in a session, in which case + the previous mailbox is automatically deselected when a new SELECT + is made. + + The default mailbox for the SELECT command is INBOX, which is a + special name reserved to mean "the primary mailbox for this user + on this server". The format of other mailbox names is operating + system dependent (as of this writing, it reflects the filename + path of the mailbox file on the current servers). + + It is customary, although not required, for the text of an OK + response to the SELECT command to begin with either "[READ-ONLY]" + or "[READ-WRITE]" to show the mailbox's access status. + + EXAMPLE: A002 SELECT INBOX + selects the default mailbox. + + tag BBOARD bulletin_board + + The BBOARD command is equivalent to SELECT, and returns the same + output. However, it differs from SELECT in that its argument is a + shared mailbox (bulletin board) name instead of an ordinary + mailbox. The format of a bulletin name is implementation + specific, although it is strongly encouraged to use something that + resembles a name in a generic sense and not a file or mailbox name + + + +Crispin [Page 11] + +RFC 1176 IMAP2 August 1990 + + + on the particular system. There is no requirement that a bulletin + board name be a mailbox name or a file name (in particular, Unix + netnews has a completely different namespace from mailbox or file + names). + + Support for BBOARD is optional. + + tag FIND MAILBOXES pattern + + The FIND MAILBOXES command accepts as an argument a pattern + (including wildcards) that specifies some set of mailbox names + that are usable by the SELECT command. The format of mailboxes is + implementation dependent. The special mailbox name INBOX is not + included in the output. + + Two wildcard characters are defined; "*" specifies any number + (including zero) characters may match at this position and "%" + specifies a single character may match at this position. For + example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, + whereas FOO%BAR will match only FOO.BAR. "*" will match all + mailboxes. + + The FIND MAILBOXES command will return some set of unsolicited + MAILBOX replies that have as their value a single mailbox name. + + EXAMPLE: A002 FIND MAILBOXES * + * MAILBOX FOOBAR + * MAILBOX GENERAL + A002 FIND completed + + Although the use of explicit file or path names for mailboxes is + discouraged by this standard, it may be unavoidable. It is + important that the value returned in the MAILBOX unsolicited reply + be usable in the SELECT command without remembering any path + specification that may have been used in the FIND MAILBOXES + pattern. + + Support for FIND MAILBOXES is optional. If a client's attempt + returns BAD as a response then the client can make no assumptions + about what mailboxes exist on the server other than INBOX. + + tag FIND BBOARDS pattern + + The FIND BBOARDS command accepts as an argument a pattern that + specifies some set of bulletin board names that are usable by the + BBOARD command. Wildcards are permitted as in FIND MAILBOXES. + + The FIND BBOARDS command will return some set of unsolicited + + + +Crispin [Page 12] + +RFC 1176 IMAP2 August 1990 + + + BBOARD replies that have as their value a single bulletin board + name. + + EXAMPLE: A002 FIND BBOARDS * + * BBOARD FOOBAR + * BBOARD GENERAL + A002 FIND completed + + Support for FIND BBOARDS is optional. If a client's attempt + returns BAD as a response then the client can make no assumptions + about what bulletin boards exist on the server, or that they exist + at all. + + tag CHECK + + The CHECK command forces a check for new messages and a rescan of + the mailbox for internal change for those implementations that + allow multiple simultaneous read/write access to the same mailbox. + It is recommend that periodic implicit checks for new mail be done + by servers as well. The server should send unsolicited EXISTS and + RECENT responses with the current status before returning an OK to + the client. + + tag EXPUNGE + + The EXPUNGE command permanently removes all messages with the + \DELETED flag set in its flags from the mailbox. Before returning + an OK to the client, for each message that is removed, an + unsolicited EXPUNGE response is sent. The message number for each + successive message in the mailbox is immediately decremented by 1; + this means that if the last 5 messages in a 9-message mail file + are expunged you will receive 5 unsolicited EXPUNGE responses for + message 5. To ensure mailbox integrity and server/client + synchronization, it is recommended that the server do an implicit + check before commencing the expunge and again when the expunge is + completed. Furthermore, if the server allows multiple + simultaneous access to the same mail file the server must lock the + mail file for exclusive access while an expunge is taking place. + + EXPUNGE is not allowed if the user does not have write access to + this mailbox. + + tag COPY sequence mailbox + + The COPY command copies the specified message(s) to the specified + destination mailbox. If the destination mailbox does not exist, + the server should create it. Before returning an OK to the + client, the server should return an unsolicited <n> COPY response + + + +Crispin [Page 13] + +RFC 1176 IMAP2 August 1990 + + + for each message copied. A copy should set the \SEEN flag for all + messages that were successfully copied (provided, of course, that + the user has write access to this mailbox). + + EXAMPLE: A003 COPY 2:4 MEETING + copies messages 2, 3, and 4 to mailbox "MEETING". + + COPY is not allowed if the user does not have write access to the + destination mailbox. + + tag FETCH sequence data + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched may be either a single atom + or an S-expression list. The currently defined data items that + can be fetched are: + + ALL Macro equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) + + ENVELOPE The envelope of the message. The envelope is + computed by the server by parsing the RFC 822 + header into the component parts, defaulting + various fields as necessary. + + FAST Macro equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE) + + FLAGS The flags that are set for this message. + This may include the following system flags: + + \RECENT Message arrived since the + previous time this mailbox + was read + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE The date and time the message was written to + the mailbox. + + + + + + + + +Crispin [Page 14] + +RFC 1176 IMAP2 August 1990 + + + RFC822 The message in RFC 822 format. The \SEEN + flag is implicitly set; if this causes the + flags to change they should be included as + part of the fetch results. This is the + concatenation of RFC822.HEADER and RFC822.TEXT. + + RFC822.HEADER The "raw" RFC 822 format header of the message + as stored on the server. + + RFC822.SIZE The number of characters in the message as + expressed in RFC 822 format. + + RFC822.TEXT The text body of the message, omitting the + RFC 822 header. The \SEEN flag is implicitly + set as with RFC822 above. + + EXAMPLES: + + A003 FETCH 2:4 ALL + fetches the flags, internal date, RFC 822 size, and envelope + for messages 2, 3, and 4. + + A004 FETCH 3 RFC822 + fetches the RFC 822 representation for message 3. + + A005 FETCH 4 (FLAGS RFC822.HEADER) + fetches the flags and RFC 822 format header for message 4. + + Note: An attempt to FETCH already-transmitted data may have no + result. See the Implementation Discussion below. + + tag STORE sequence data value + + The STORE command alters data associated with a message in the + mailbox. The currently defined data items that can be stored are: + + FLAGS Replace the flags for the message with the + argument (in flag list format). + + +FLAGS Add the flags in the argument to the + message's flag list. + + -FLAGS Remove the flags in the argument from the + message's flag list. + + STORE is not allowed if the user does not have write access to + this mailbox. + + + + +Crispin [Page 15] + +RFC 1176 IMAP2 August 1990 + + + EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) + marks messages 2, 3, and 4 for deletion. + + tag SEARCH search_criteria + + The SEARCH command searches the mailbox for messages that match + the given set of criteria. The unsolicited SEARCH <1#number> + response from the server is a list of messages that express the + intersection (AND function) of all the messages which match that + criteria. For example, + A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 + returns the message numbers for all deleted messages from Smith + that were placed in the mail file since October 1, 1987. + + In all search criteria which use strings, a message matches the + criteria if the string is a case-independent substring of that + field. The currently defined criteria are: + + ALL All messages in the mailbox; the default + initial criterion for ANDing. + + ANSWERED Messages with the \ANSWERED flag set. + + BCC string Messages which contain the specified string + in the envelope's BCC field. + + BEFORE date Messages whose internal date is earlier than + the specified date. + + BODY string Messages which contain the specified string + in the body of the message. + + CC string Messages which contain the specified string + in the envelope's CC field. + + DELETED Messages with the \DELETED flag set. + + FLAGGED Messages with the \FLAGGED flag set. + + FROM string Messages which contain the specified string + in the envelope's FROM field. + + KEYWORD flag Messages with the specified flag set. + + NEW Messages which have the \RECENT flag set but + not the \SEEN flag. This is functionally + equivalent to "RECENT UNSEEN". + + + + +Crispin [Page 16] + +RFC 1176 IMAP2 August 1990 + + + OLD Messages which do not have the \RECENT flag + set. + + ON date Messages whose internal date is the same as + the specified date. + + RECENT Messages which have the \RECENT flag set. + + SEEN Messages which have the \SEEN flag set. + + SINCE date Messages whose internal date is later than + the specified date. + + SUBJECT string Messages which contain the specified string + in the envelope's SUBJECT field. + + TEXT string Messages which contain the specified string. + + TO string Messages which contain the specified string in + the envelope's TO field. + + UNANSWERED Messages which do not have the \ANSWERED flag + set. + + UNDELETED Messages which do not have the \DELETED flag + set. + + UNFLAGGED Messages which do not have the \FLAGGED flag + set. + + UNKEYWORD flag Messages which do not have the specified flag + set. + + UNSEEN Messages which do not have the \SEEN flag set. + + + + + + + + + + + + + + + + + +Crispin [Page 17] + +RFC 1176 IMAP2 August 1990 + + +Responses + + tag OK text + + This response identifies successful completion of the command with + that tag. The text is a line of human-readable text that may be + useful in a protocol telemetry log for debugging purposes. + + tag NO text + + This response identifies unsuccessful completion of the command + with that tag. The text is a line of human-readable text that + probably should be displayed to the user in an error report by the + client. + + tag BAD text + + This response identifies faulty protocol received from the client; + The text is a line of human-readable text that should be recorded + in any telemetry as part of a bug report to the maintainer of the + client. + + * number message_data + + This response occurs as a result of several different commands. + The message_data is one of the following: + + EXISTS The specified number of messages exists in the mailbox. + + RECENT The specified number of messages have arrived since the + previous time this mailbox was read. + + EXPUNGE The specified message number has been permanently + removed from the mailbox, and the next message in the + mailbox (if any) becomes that message number. + + STORE data + Obsolete and functionally equivalent to FETCH. + + FETCH data + This is the principle means by which data about a + message is returned to the client. The data is in a + Lisp-like S-expression property list form. The current + properties are: + + ENVELOPE An S-expression format list that describes the + envelope of a message. The envelope is computed + by the server by parsing the RFC 822 header into + + + +Crispin [Page 18] + +RFC 1176 IMAP2 August 1990 + + + the component parts, defaulting various fields + as necessary. + + The fields of the envelope are in the following + order: date, subject, from, sender, reply-to, to, + cc, bcc, in-reply-to, and message-id. The date, + subject, in-reply-to, and message-id fields are + strings. The from, sender, reply-to, to, cc, + and bcc fields are lists of addresses. + + An address is an S-expression format list that + describes an electronic mail address. The fields + of an address are in the following order: + personal name, source-route (a.k.a. the + at-domain-list in SMTP), mailbox name, and + host name. + + Any field of an envelope or address that is + not applicable is presented as the atom NIL. + Note that the server must default the reply-to + and sender fields from the from field; a client is + not expected to know to do this. + + FLAGS An S-expression format list of flags that are set + for this message. This may include the following + system flags: + + \RECENT Message arrived since the + previous time this mailbox + was read + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE A string containing the date and time the + message was written to the mailbox. + + RFC822 A string expressing the message in RFC 822 + format. + + RFC822.HEADER A string expressing the RFC 822 format + header of the message + + RFC822.SIZE A number indicating the number of + characters in the message as expressed + + + +Crispin [Page 19] + +RFC 1176 IMAP2 August 1990 + + + in RFC 822 format. + + RFC822.TEXT A string expressing the text body of the + message, omitting the RFC 822 header. + + * FLAGS flag_list + + This response occurs as a result of a SELECT command. The flag + list are the list of flags (at a minimum, the system-defined + flags) that are applicable for this mailbox. Flags other than the + system flags are a function of the server implementation. + + * SEARCH number(s) + + This response occurs as a result of a SEARCH command. The + number(s) refer to those messages that match the search criteria. + Each number is delimited by a space, e.g., "SEARCH 2 3 6". + + * BBOARD string + + This response occurs as a result of a FIND BBOARDS command. The + string is a bulletin board name that matches the pattern in the + command. + + * MAILBOX string + + This response occurs as a result of a FIND MAILBOXES command. The + string is a mailbox name that matches the pattern in the command. + + * BYE text + + This response identifies that the server is about to close the + connection. The text is a line of human-readable text that should + be displayed to the user in a status report by the client. This + may be sent as part of a normal logout sequence, or as a panic + shutdown announcement by the server. It is also used by some + servers as an announcement of an inactivity autologout. + + * OK text + + This response identifies normal operation on the server. No + special action by the client is called for, however, the text + should be displayed to the user in some fashion. This is + currently only used by servers at startup as a greeting message to + show they are ready to accept the first command. + + + + + + +Crispin [Page 20] + +RFC 1176 IMAP2 August 1990 + + + * NO text + + This response identifies a warning from the server that does not + affect the overall results of any particular request. The text is + a line of human-readable text that should be presented to the user + as a warning of improper operation. + + * BAD text + + This response identifies a serious error at the server; it may + also indicate faulty protocol from the client in which a tag could + not be parsed. The text is a line of human-readable text that + should be presented to the user as a serious or possibly fatal + error. It should also be recorded in any telemetry as part of a + bug report to the maintainer of the client and server. + + + text + + This response identifies that the server is ready to accept the + text of a literal from the client. Normally, a command from the + client is a single text line. If the server detects an error in + the command, it can simply discard the remainder of the line. It + cannot do this for commands that contain literals, since a literal + can be an arbitrarily long amount of text, and the server may not + even be expecting a literal. This mechanism is provided so the + client knows not to send a literal until the server expects it, + preserving client/server synchronization. + + In practice, this condition is rarely encountered. In the current + protocol, the only client command likely to contain a literal is + the LOGIN command. Consider a server that validates the user + before checking the password. If the password contains "funny" + characters and hence is sent as a literal, then if the user is + invalid an error would occur before the password is parsed. + + No such synchronization protection is provided for literals sent + from the server to the client, for performance reasons. Any + synchronization problems in this direction would be caused by a + bug in the client or server. + + + + + + + + + + + + +Crispin [Page 21] + +RFC 1176 IMAP2 August 1990 + + +Sample IMAP2 session + + The following is a transcript of an IMAP2 session. Server output is + identified by "S:" and client output by "U:". In cases where lines + are too long to fit within the boundaries of this document, the line + is continued on the next line. + + S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service + 6.1(349) at Thu, 9 Jun 88 14:58:30 PDT + U: a001 login crispin secret + S: a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76 + U: a002 select inbox + S: * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question + Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen) + S: * 16 EXISTS + S: * 0 RECENT + S: a002 OK Select complete + U: a003 fetch 16 all + S: * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT" + RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT" + "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH" + "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL + "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) + S: a003 OK Fetch completed + U: a004 fetch 16 rfc822 + S: * 16 Fetch (RFC822 {637} + S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43 + S: Mail-From: FAGAN created at 4-Jun-88 13:27:12 + S: Date: Sat, 4 Jun 88 13:27:11 PDT + S: From: Larry Fagan <FAGAN@SUMEX-AIM.Stanford.EDU> + S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU + S: Subject: INFO-MAC Mail Message + S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> + S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT + S: ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU> + S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, + Crispin@SUMEX-AIM.Stanford.EDU + S: ReSent-Message-ID: + <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> + S: + S: The file is <info-mac>usenetv4-55.arc ... + S: Larry + S: ------- + S: ) + S: a004 OK Fetch completed + + + +Crispin [Page 22] + +RFC 1176 IMAP2 August 1990 + + + U: a005 logout + S: * BYE DEC-20 IMAP II server terminating connection + S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol + Service logout + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 23] + +RFC 1176 IMAP2 August 1990 + + +Implementation Discussion + + There are several advantages to the scheme of tags and unsolicited + responses. First, the infamous synchronization problems of SMTP and + similar protocols do not happen with tagged commands; a command is + not considered satisfied until a response with the same tag is seen. + Tagging allows an arbitrary amount of other responses ("unsolicited" + data) to be sent by the server with no possibility of the client + losing synchronization. Compare this with the problems that FTP or + SMTP clients have with continuation, partial completion, and + commentary reply codes. + + Another advantage is that a non-lockstep client implementation is + possible. The client could send a command, and entrust the handling + of the server responses to a different process that would signal the + client when the tagged response comes in. Under certain + circumstances, the client may have more than one command outstanding. + + It was observed that synchronization problems can occur with literals + if the literal is not recognized as such. Fortunately, the cases in + which this can happen are rare; a mechanism (the special "+" tag + response) was introduced to handle those few cases. The proper way + to address this problem is probably to move towards a record-oriented + architecture instead of the text stream model provided by TCP. + + An IMAP2 client must maintain a local cache of data from the mailbox. + This cache is an incomplete model of the mailbox, and at startup is + empty. A listener processes all unsolicited data, and updates the + cache based on this data. If a tagged response arrives, the listener + unblocks the process that sent the tagged request. + + Unsolicited data needs some discussion. Unlike most protocols, in + which the server merely does the client's bidding, an IMAP2 server + has a semi-autonomous role. By sending "unsolicited data", the + server is in effect sending a command to the client -- to update or + extend the client's cache with new information from the server. In + other words, a "fetch" command is merely a request to the server to + ensure that the client's cache has the most up-to-date version of the + requested information. A server acknowledgement to the "fetch" is a + statement that all the requested data has been sent. + + Although no current server does this, a server is not obliged by the + protocol to send data that it has already sent and is unchanged. An + exception to this is the actual message text fetching operations + (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly + excessive resource consumption of maintaining this data in a cache. + It can not be assumed that a FETCH will transmit any data; only that + an OK to the FETCH means that the client's cache has the most up-to- + + + +Crispin [Page 24] + +RFC 1176 IMAP2 August 1990 + + + date information. + + When a mailbox is selected, the initial unsolicited data from the + server arrives. The first piece of data is the number of messages. + By sending a new EXISTS unsolicited data message the server causes + the client to resize its cache (this is how newly arrived mail is + handled). If the client attempts to access information from the + cache, it will encounter empty spots that will trigger "fetch" + requests. The request would be sent, some unsolicited data including + the answer to the fetch will flow back, and then the "fetch" response + will unblock the client. + + People familiar with demand-paged virtual memory operating system + design will recognize this model as being similar to page-fault + handling on a demand-paged system. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 25] + +RFC 1176 IMAP2 August 1990 + + +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 + a comma. + + address ::= "(" addr_name SP addr_adl SP addr_mailbox SP + addr_host ")" + + addr_adl ::= nil / string + + addr_host ::= nil / string + + addr_mailbox ::= nil / string + + addr_name ::= nil / string + + bboard ::= "BBOARD" SP string + + check ::= "CHECK" + + copy ::= "COPY" SP sequence SP mailbox + + data ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number / + "BYE" SP text_line / "OK" SP text_line / + "NO" SP text_line / "BAD" SP text_line) + + date ::= string in form "dd-mmm-yy hh:mm:ss-zzz" + + envelope ::= "(" env_date SP env_subject SP env_from SP + env_sender SP env_reply-to SP env_to SP + env_cc SP env_bcc SP env_in-reply-to SP + env_message-id ")" + + env_bcc ::= nil / "(" 1*address ")" + + env_cc ::= nil / "(" 1*address ")" + + env_date ::= string + + env_from ::= nil / "(" 1*address ")" + + env_in-reply-to ::= nil / string + + env_message-id ::= nil / string + + env_reply-to ::= nil / "(" 1*address ")" + + + +Crispin [Page 26] + +RFC 1176 IMAP2 August 1990 + + + env_sender ::= nil / "(" 1*address ")" + + env_subject ::= nil / string + + env_to ::= nil / "(" 1*address ")" + + expunge ::= "EXPUNGE" + + fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / + fetch_att / "(" 1#fetch_att ")") + + fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / + "RFC822.TEXT" + + find ::= "FIND" SP find_option SP string + + find_option ::= "MAILBOXES" / "BBOARDS" + + flag_list ::= ATOM / "(" 1#ATOM ")" + + literal ::= "{" NUMBER "}" CRLF ASCII-STRING + + login ::= "LOGIN" SP userid SP password + + logout ::= "LOGOUT" + + mailbox ::= "INBOX" / string + + msg_copy ::= "COPY" + + msg_data ::= (msg_exists / msg_recent / msg_expunge / + msg_fetch / msg_copy) + + msg_exists ::= "EXISTS" + + msg_expunge ::= "EXPUNGE" + + msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP + envelope / "FLAGS" SP "(" 1#(recent_flag + flag_list) ")" / "INTERNALDATE" SP date / + "RFC822" SP string / "RFC822.HEADER" SP string / + "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP + string) ")" + + msg_recent ::= "RECENT" + + msg_num ::= NUMBER + + + +Crispin [Page 27] + +RFC 1176 IMAP2 August 1990 + + + nil ::= "NIL" + + noop ::= "NOOP" + + password ::= string + + recent_flag ::= "\RECENT" + + ready ::= "+" SP text_line + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / find / + bboard) CRLF + + response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF + + search ::= "SEARCH" SP 1#("ALL" / "ANSWERED" / + "BCC" SP string / "BEFORE" SP string / + "BODY" SP string / "CC" SP string / "DELETED" / + "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / + "ON" SP string / "RECENT" / "SEEN" / + "SINCE" SP string / "TEXT" SP string / + "TO" SP string / "UNANSWERED" / "UNDELETED" / + "UNFLAGGED" / "UNKEYWORD" / "UNSEEN") + + select ::= "SELECT" SP mailbox + + sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" + sequence) + + store ::= "STORE" SP sequence SP store_att + + store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / + "FLAGS" SP flag_list) + + string ::= atom / """" 1*character """" / literal + + system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP + "\SEEN" + + tag ::= atom + + unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF + + userid ::= string + + + + + + +Crispin [Page 28] + +RFC 1176 IMAP2 August 1990 + + +Implementation Status + + This information is current as of this writing. + + The University of Washington has developed an electronic mail client + library called the "C-Client". It provides complete IMAP2, SMTP, and + local mailbox (both /usr/spool/mail and mail.txt formats) services in + a well-defined way to a user interface main program. Using the C- + Client, the University of Washington has created an operational + client for BSD Unix and two operational clients (one basic, one + advanced) for the NeXT. + + Stanford University/SUMEX has developed operational IMAP2 clients for + Xerox Lisp machines, Texas Instruments Explorers, and the Apple + Macintosh. The core of the Macintosh client is an early version of + the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20 and + BSD Unix. + + All of the above software is in production use, with enthusiastic + local user communities. Active development continues on the + Macintosh and C-Client based clients and the BSD Unix server. This + software is freely available from the University of Washington and + SUMEX. + + IMAP2 software exists for other platforms; for example Nippon + Telephone and Telegraph (NTT) has developed an operational IMAP2 + client for the NTT ELIS. Several organizations are working on a PC + client. + + IMAP2 can be used to access mailboxes at very remote sites, where + echo delays and frequent outages make TELNET and running a local mail + reader intolerable. For example, from a desktop workstation on the + University of Washington local network the author routinely uses + IMAP2 to read and manage mailboxes on various University of + Washington local servers, at two systems at Stanford University, at a + Milnet site, and at a site in Tokyo, Japan. + + This specification does not make any formal definition of size + restrictions, but the DEC-20 server has the following limitations: + + . length of a mailbox: 7,077,888 characters + . maximum number of messages: 18,432 messages + . length of a command line: 10,000 characters + . length of the local host name: 64 characters + . length of a "short" argument: 39 characters + . length of a "long" argument: 491,520 characters + . maximum amount of data output in a single fetch: + 655,360 characters + + + +Crispin [Page 29] + +RFC 1176 IMAP2 August 1990 + + + To date, nobody has run up against any of these limitations, many of + which are substantially larger than most current user mail reading + programs. + +Acknowledgements + + Bill Yeager and Rich Acuff both contributed invaluable suggestions in + the evolution of IMAP2 from the original IMAP. James Rice pointed + out several ambiguities in the previous IMAP2 specification and + otherwise would not allow me to leave bad enough along. Laurence + Lundblade reviewed a draft of this version and made several helpful + suggestions. + + Many dedicated individuals have worked on IMAP2 software, including: + Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno, + Christopher Schmidt, and Bill Yeager. + + Any mistakes, flaws, or sins of omission in this IMAP2 protocol + specification are, however, strictly my own; and the mention of any + name above does not imply an endorsement. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Mark R. Crispin + Panda Programming + 6158 Lariat Loop NE + Bainbridge Island, WA 98110-2020 + + Phone: (206) 842-2385 + + EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU + + + + + + + + + + + + + + + + +Crispin [Page 30] +
\ No newline at end of file diff --git a/RFC/rfc1203.txt b/RFC/rfc1203.txt new file mode 100644 index 00000000..a362ca88 --- /dev/null +++ b/RFC/rfc1203.txt @@ -0,0 +1,2747 @@ + + + + + + +Network Working Group J. Rice +Request for Comments: 1203 Stanford +Obsoletes: RFC 1064 February 1991 + + + INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3 + +Status of this Memo + + This RFC suggests a method for workstations to access mail + dynamically from a mailbox server ("repository"). This RFC specifies + a standard for the SUMEX-AIM community and an Experimental Protocol + for the Internet community. Discussion and suggestions for + improvement are requested. Please refer to the current edition of + the "IAB Official Protocol Standards" for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Scope + + The following document is a modified version of RFC 1064, the + definition of the IMAP2 protocol. This RFC has been written + specifically as a counter proposal to RFC 1176, which itself proposes + modifications to IMAP2. Sadly, RFC 1176 was made without internal + consultation with the IMAP community, so we are in a position of + feeling we have to present a counter proposal to what, if we do not + act, will become a de facto standard. The reasons for this counter + proposal are numerous but fall mostly into the following categories: + + - IMAP2 is insufficiently powerful for a number of server/client + interactions which we believe to be important. RFC 1176 + negligibly enhances the functionality of IMAP2. + + - IMAP2 makes what we believe to be an erroneous definition for + unsolicited vs. solicited data. IMAP3 as specified herein + attempts to correct this. RFC 1176 makes no effort to remedy + these problems. + + - RFC 1176 has explicitly modified the intent of RFC 1064 by + allowing the server to make assumptions about the client's + caching architecture. We believe this to be a grave error + and do not support it in this proposal. + + - RFC 1176 specifies a number of "optional" features in the + protocol without specifying a suitable metaprotocol by which + servers and clients can adequately negotiate over the set of + implemented features. This proposal specifies a mechanism + by which servers and clients can come to an unambiguous + understanding about which features are usable by each party. + + + +Rice [Page 1] + +RFC 1203 IMAP3 February 1991 + + + + - RFC 1176 pays only lip-service to being network protocol + independent and, in fact assumes the use of TCP/IP. Neither + RFC 1064 nor this proposal make any such assumption. + + Although there are numerous other detailed objections to RFC 1176, we + believe that the above will serve to show that we believe strongly in + the importance of mailbox abstraction level mail protocols and, after + a couple of years of use of IMAP2 under RFC 1064 we believe that we + have a good enough understanding of the issues involved to be able to + take the next step. + + It is important to take this next step because of the rapid pace of + both mail system and user interface development. We believe that, + for IMAP not to die in its infancy, IMAP must be ready to respond to + emerging ISO and RFC standards in mail, such as for multi-media mail. + We believe that RFC 1176 not only provides a very small increment in + functionality over RFC 1064 but also adds a number of bugs, which + would be detrimental to the IMAP cause. Thus we propose the + following definition for IMAP3. + +Compatibility notes: + + In revising the IMAP2 protocol it has been our intent, wherever + possible to make upwards compatible changes to produce IMAP3. There + were, however, some places that had to be changed incompatibly in + order to compensate for either ambiguities in the IMAP2 protocol as + defined by RFC 1064 or behavior that proved undesirable in the light + of experience. + + It is our goal, however, that existing IMAP2 clients should still be + supported and that, at least for the foreseeable future, all IMAP3 + servers will support IMAP2 behavior as their default mode. + + The following are the major differences between this proposal, RFC + 1176 and RFC 1064: + + - In this proposal we specify a difference between "solicited" and + "unsolicited" data sent from the server. It is generally the + case that data sent by the server can be sent either in response + to an explicit request by the client or by the server of its own + volition. Any data that the server is required to sent to the + client as the result of a request is said to be solicited and + carries the same tag as the request that provoked it. Any data + sent by the server to the client that is not required by the + protocol is said to be unsolicited and carries the special "*" + tag. RFC 1176 preserves the original RFC 1064 terminology that + calls all such data sent by the server "unsolicited" even when + + + +Rice [Page 2] + +RFC 1203 IMAP3 February 1991 + + + it is, in fact, solicited. + + - This proposal introduces the experimental concept of + distinguishing between Generic, Canonical and Concrete keys, + allowing the mailbox to be viewed as a relational database + indexed by these keys. This should allow the IMAP protocol + to evolve away from its current reliance on RFC 822. RFC 1176 + does not have such a unifying model. + + - The SEARCH command has been changed so as to allow multiple + simultaneous searches to be made and to allow unsolicited + search messages to be sent by the server. Such a change is + essential to allow more sophisticated servers that can process + commands asynchronously, possibly substantially delaying + searches over slow backing storage media, for example. It is + also important to allow servers to be able to send unsolicited + search messages that might inform the client of interesting + patterns of messages, such as new and unseen mail. + + - This proposal introduces a specific protocol for the negotiation + of protocol versions and server features. This is important + because it allows client/server pairs to come to an agreement on + what behavior is really available to it. RFC 1176 introduces a + number of "optional" commands, which are in some way analogous + to "feature-introduced" commands in this proposal. The principle + distinction between these is that in RFC 1176 there is no way + for a client to discover the set of optional commands, nor is + there a way for it to determine whether a specific command + really is supported, since RFC 1176 requires the use of the + "BAD" response if a feature is not supported. There is, + therefore, no way for the client to determine why the attempted + command did not work. This also means that, for example, a + client cannot disable certain user commands or make them + invisible on menus if they are not supported, since there + is no way for the client to discover whether the commands are + indeed supported without trying to execute such a command. + + - This proposal introduces a mechanism for clients to create and + delete user flags (keywords). This is nor supported in either + RFC 1176 or RFC 1064, requiring the user to add keys manually + on the server, generally by editing some form of "init" file. + + - RFC 1064 has no mechanism for determining whether a mailbox is + readonly or not. RFC 1176 introduces a non-enforced convention + of encoding data about the readonly status of a mailbox in the + SELECT message's OK respose comment field. This is not regular + with respect to the rest of the protocol, in which the comment + field is used for no purpose other than documentation. This + + + +Rice [Page 3] + +RFC 1203 IMAP3 February 1991 + + + proposal introduces specific protocol additions for the dynamic + determination and modification of the readonly/readwrite status + of mailboxes. + +Introduction + + The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3) + is to allow a (possibly unreliable) workstation or similar machine to + access electronic mail from a reliable mailbox server in an efficient + manner. + + Although different in many ways from POP2 (RFC 937), IMAP3 may be + thought of as a functional superset of POP2, and the POP2 RFC was + used as a model for this RFC. There was a cognizant reason for this; + RFC 937 deals with an identical problem and it was desirable to offer + a basis for comparison. + + Like POP2, IMAP3 specifies a means of accessing stored mail and not + of posting mail; this function is handled by a mail transfer protocol + such as SMTP (RFC 821). A comparison with the DMSP protocol of + PCMAIL can be found at the end of "System Model and Philosophy" + section. + + This protocol assumes a reliable data stream such as provided by TCP + or any similar protocol. When TCP is used, the IMAP server listens + on port 220. When CHAOS is used the IMAP server listens for the + logical contact name "IMAP3". + + Communication in IMAP is defined to be using the ASCII character + interpretation of data. Communication using other conventions may be + possible by the selection of features on some servers. + +System Model and Philosophy + + Electronic mail is a primary means of communication for the widely + spread SUMEX-AIM community. The advent of distributed workstations + is forcing a significant rethinking of the mechanisms employed to + manage such mail. With mainframes, each user tends to receive and + process mail at the computer he used most of the time, his "primary + host". The first inclination of many users when an independent + workstation is placed in front of them is to begin receiving mail at + the workstation, and, in fact, many vendors have implemented + facilities to do this. However, this approach has several + disadvantages: + + (1) Workstations (especially Lisp workstations) have a software + design that gives full control of all aspects of the system + to the user at the console. As a result, background tasks, + + + +Rice [Page 4] + +RFC 1203 IMAP3 February 1991 + + + like receiving mail, could well be kept from running for + long periods of time either because the user is asking to + use all of the machine's resources, or because, in the course + of working, the user has (perhaps accidentally) manipulated + the environment in such a way as to prevent mail reception. + This could lead to repeated failed delivery attempts by + outside agents. + + (2) The hardware failure of a single workstation could keep its + user "off the air" for a considerable time, since repair of + individual workstation units might be delayed. Given the + growing number of workstations spread throughout office + environments, quick repair would not be assured, whereas a + centralized mainframe is generally repaired very soon after + failure. + + (3) It is more difficult to keep track of mailing addresses when + each person is associated with a distinct machine. Consider + the difficulty in keeping track of a large number of postal + addresses or phone numbers, particularly if there was no + single address or phone number for an organization through + which you could reach any person in that organization. + Traditionally, electronic mail on the ARPANET involved + remembering a name and one of several "hosts" (machines) + whose name reflected the organization in which the + individual worked. This was suitable at a time when most + organizations had only one central host. It is less + satisfactory today unless the concept of a host is changed + to refer to an organizational entity and not a particular + machine. + + (4) It is very difficult to keep a multitude of heterogeneous + workstations working properly with complex mailing protocols, + making it difficult to move forward as progress is made in + electronic communication and as new standards emerge. Each + system has to worry about receiving incoming mail, routing + and delivering outgoing mail, formatting, storing, and + providing for the stability of mailboxes over a variety of + possible filing and mailing protocols. + + Consequently, while the workstation may be viewed as an Internet host + in the sense that it implements IP, it should not be viewed as the + entity which contains the user's mailbox. Rather, a mail server + machine (sometimes called a "repository") should hold the mailbox, + and the workstation (hereafter referred to as a "client") should + access the mailbox via mail transactions. Because the mail server + machine would be isolated from direct user manipulation, it could + achieve high software reliability easily, and, as a shared resource, + + + +Rice [Page 5] + +RFC 1203 IMAP3 February 1991 + + + it could achieve high hardware reliability, perhaps through + redundancy. The mail server could be used from arbitrary locations, + allowing users to read mail across campus, town, or country using + more and more commonly available clients. Furthermore, the same user + may access his mailbox from different clients at different times, and + multiple users may access the same mailbox simultaneously. + + The mail server acts an an interface among users, data storage, and + other mailers. The mail access protocol is used to retrieve + messages, access and change properties of messages, and manage + mailboxes. This differs from some approaches (e.g., Unix mail via + NFS) in that the mail access protocol is used for all message + manipulations, isolating the user and the client from all knowledge + of how the data storage is used. This means that the mail server can + utilize the data storage in whatever way is most efficient to + organize the mail in that particular environment, without having to + worry about storage representation compatibility across different + machines. + + In defining a mail access protocol, it is important to keep in mind + that the client and server form a macrosystem, in which it should be + possible to exploit the strong points of both while compensating for + each other's weaknesses. Furthermore, it's desirable to allow for a + growth path beyond the hoary text-only RFC 822 protocol. Unlike + POP2, IMAP3 has extensive features for remote searching and parsing + of messages on the server. For example, a free text search + (optionally in conjunction with other searching) can be made + throughout the entire mailbox by the server and the results made + available to the client without the client having to transfer the + entire mailbox and searching itself. Since remote parsing of a + message into a structured (and standard format) "envelope" is + available, a client can display envelope information and implement + commands such as REPLY without having any understanding of how to + parse RFC 822, etc., headers. + + Additionally, IMAP3 offers several facilities for managing a mailbox + beyond the simple "delete message" functionality of POP2. + + In spite of this, IMAP3 is a relatively simple protocol. Although + servers should implement the full set of IMAP3 functions, a simple + client can be written which uses IMAP3 in much the way as a POP2 + client. + + IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more + fundamental manner, reflecting the differing architectures of IMAP + and PCMAIL. PCMAIL is either an online ("interactive mode"), or + offline ("batch mode") system. IMAP is primarily an online system in + which real-time and simultaneous mail access were considered + + + +Rice [Page 6] + +RFC 1203 IMAP3 February 1991 + + + important. + + In PCMAIL, there is a long-term client/server relationship in which + some mailbox state is preserved on the client. There is a + registration of clients used by a particular user, and the client + keeps a set of "descriptors" for each message which summarize the + message. The server and client synchronize their states when the + DMSP connection starts up, and, if a client has not accessed the + server for a while, the client does a complete reset (reload) of its + state from the server. + + In IMAP, the client/server relationship lasts only for the duration + of the IMAP3 connection. All mailbox state is maintained on the + server. There is no registration of clients. The function of a + descriptor is handled by a structured representation of the message + "envelope". This structure makes it unnecessary for a client to know + anything about RFC 822 parsing. There is no synchronization since + the client does not remember state between IMAP3 connections. This + is not a problem since in general the client never needs the entire + state of the mailbox in a single session, therefore there isn't much + overhead in fetching the state information that is needed as it is + needed. + + There are also some functional differences between IMAP3 and DMSP. + DMSP has functions for sending messages, printing messages, and + changing passwords, all of which are done outside of IMAP3. DMSP has + 16 binary flags of which 8 are defined by the system. IMAP has flag + names; there are currently 5 defined system flag names and a facility + for some number (29 in the current implementations) of user flag + names. IMAP3 has a sophisticated message search facility in the + server to identify interesting messages based on dates, addresses, + flag status, or textual contents without compelling the client to + fetch this data for every message. + + It was felt that maintaining state on the client is advantageous only + in those cases where the client is only used by a single user, or if + there is some means on the client to restrict access to another + user's data. It can be a serious disadvantage in an environment in + which multiple users routinely use the same client, the same user + routinely uses different clients, and where there are no access + restrictions on the client. It was also observed that most user mail + access is to a relatively small set of "interesting" messages, which + were either "new" mail or mail based upon some user-selected + criteria. Consequently, IMAP3 was designed to easily identify those + "interesting" messages so that the client could fetch the state of + those messages and not those that were not "interesting". + + One crucial philosophical difference between IMAP and other common + + + +Rice [Page 7] + +RFC 1203 IMAP3 February 1991 + + + mail protocols is that IMAP is a mailbox access protocol, not a + protocol for manipulating mail files. In the IMAP model, unlike + other mail system models in which mail is stored in a linear mail + file, no specification is made for the implementation architecture + for mail storage. Servers may choose to implement mailboxes as files + but this is a detail of which the client can be totally unaware. + + What is more, in the IMAP model, mailboxes are viewed as mappings + from keys into values. There are broadly three types of keys, + generic, canonical and concrete. Generic keys are generic, mail + protocol independent keys defined by IMAP which are meaningful across + multiple mail encoding formats. An example of such a generic key + might be "TO", which would be associated with the "To:" field of an + RFC 822 format message. + + Canonical keys represent the way in which the server can associate + values that are generally "about" a certain key concept, possibly + integrating several mail format specific fields, without having to + worry the client with the particular details of any particular + message format. Thus, the canonical TO key (called $TO) could denote + anything that could reasonably be construed as being directed towards + someone. Hence, in an RFC 822 message the server could find the + union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to + be the appropriate value associated with the canonical $TO key. + + Concrete keys allow the client to gain access to certain mail format + specific concepts, that are not pre-specified by the IMAP protocol, + in a well defined manner. For example, If the client asks for the + value associated with the "APPARENTLY-TO" key then, if the message + were to be in RFC 822 format, the server would look for a header + field called "Apparently-To:". If no such field is found or the + field is not implemented or meaningful for the particular message + format then the server will respond with the null value, called NIL, + indicating the non-existence of the field. + + Thus, IMAP servers are at liberty to implement mailboxes as a + relational databases if it seems convenient. Indeed, we anticipate + that future mail systems will tend to use database technology for the + storage and indexing of mailboxes as a result of the pressure caused + by the increasing size of mailboxes. + + Although for historical reasons IMAP is currently somewhat closely + associated with RFC 822, we anticipate that future developments in + IMAP will remove these mail format specific components and will move + towards the generic model mentioned above. This will allow IMAP more + easily to incorporate such things as multi-media mail. + + + + + +Rice [Page 8] + +RFC 1203 IMAP3 February 1991 + + +The Protocol + + The IMAP3 protocol consists of a sequence of client commands and + server responses to those commands, with extra information from the + server data being sent asynchronously to and independent to the + responses to client commands. Unlike most Internet protocols, + commands and responses are tagged. That is, a command begins with a + unique identifier (typically a short alphanumeric sequence such as a + Lisp "gensym" function would generate e.g., A0001, A0002, etc.), + called a tag. The response to this command is given the same tag + from the server. + + We distinguish between data sent by the server as the result of a + client request, which we term "SOLICITED" and data sent by the server + not as the result of a client request, which we term "UNSOLICITED". + The server may send unsolicited data at any time that would not + fragment another piece of data on the same stream rendering it + unintelligible. The server is contractually required, however, to + return all data that is solicited by the client before the return of + the completion signal for that command, i.e., all solicited data must + be returned within the temporal extent of the request/completion + acknowledgement wrapper. This does not, however, preclude the + simultaneous processing of multiple requests by the client, it simply + requires that the client be confident that it has all the requested + data when a request finishes. This allows the implementation of both + synchronous and asynchronous clients. + + Solicited data is identified by the tag of the initial request by the + client. Unsolicited data is identified by the special reserved tag + of "*". There is another special reserved tag, "+", discussed below. + + Note: the tagging of SOLICITED data is only permitted for a selected + server version other than 2.0. + + No assumptions concerning serial or monolithic processing by the + server can be made by a correct client. The server is at liberty to + process multiple requests by the same client in any order. This + allows servers to process costly searches over mailboxes on slow + backing storage media in the background, while still preserving + interactive performance. Clients can, however, assume the + serialization of the request/data/completion behavior mentioned + above. + + When a connection is opened the server sends an unsolicited OK + response as a greeting message and then waits for commands. When + commands are received the server acts on them and responds with + responses, often interspersed with data. + + + + +Rice [Page 9] + +RFC 1203 IMAP3 February 1991 + + + The client opens a connection, waits for the greeting, then sends a + LOGIN command with user name and password arguments to establish + authorization. Following an OK response from the server, the client + then sends a SELECT command to access the desired mailbox. The + user's default mailbox has a special reserved name of "INBOX" which + is independent of the operating system that the server is implemented + on. The server will generally send a list of valid flags, number of + messages, and number of messages arrived since last access for this + mailbox as solicited data, followed by an OK response. The client + may terminate access to this mailbox and access a different one with + another SELECT command. + + Because the SELECT command affects the state of the server in a + fundamental way, the server is required to process all outstanding + commands for any given mailbox before sending the OK tag for the + SELECT command. Thus, the client will always know that all responses + before an OK SELECT response will refer to the old mailbox and all + responses following it will apply to the new mailbox. + + Because, in the real world, local needs or experimental work will + dictate that servers will support both supersets of the defined + behavior and incompatible changes, servers will support a + SELECT.VERSION command and a SELECT.FEATURES command, the purpose of + which is to allow clients to select the overall behavior and specific + features that they want from a server. The default behavior of any + server is to process commands and to have interaction syntax the same + as is specified by IMAP2 in RFC 1064. A server may not behave in any + other manner unless the SELECT.VERSION or SELECT.FEATURES commands + are used to select different behavior. + + Over time, when groups of generally useful changes to the current, + default behavior of the server are found, these will be collected + together and incorporated in such a way that all of the features can + be selected simply by selecting a particular major version number of + the protocol. It should be noted that the version numbers (both + major and minor) selected by the SELECT.VERSION command denote + versions of the IMAP protocol, not versions of the server per se. + Thus, although in general changes to the protocol specification will + be made in such a way that they are upwards compatible, this cannot + be guaranteed. No client should rely on tests of the form "if + major_version > 2 then..." being valid for all protocol versions, + since incompatible changes might be made in the future. + + The client reads mailbox information by means of FETCH commands. The + actual data is transmitted via the solicited data mechanism (that is, + FETCH should be viewed as poking the server to include the desired + data along with any other data it wishes to transmit to the client). + There are three major categories of data which may be fetched. + + + +Rice [Page 10] + +RFC 1203 IMAP3 February 1991 + + + The first category is that data which is associated with a message as + an entity in the mailbox. There are presently three such items of + data: the "internal date", the "RFC 822 size", and the "flags". The + internal date is the date and time that the message was placed in the + mailbox. The RFC 822 size is subject to deletion in the future; it + is the size in bytes of the message, expressed as an RFC 822 text + string. Current clients only use it as part of a status display + line. The flags are a list of status flags associated with the + message (see below). All of the first category data can be fetched + by using the macro-fetch word "FAST"; that is, "FAST" expands to + "(FLAGS INTERNALDATE RFC822.SIZE)". + + The second category is that data which describes the composition and + delivery information of a message; that is, information such as the + message sender, recipient lists, message-ID, subject, etc. This is + the information which is stored in the message header in RFC 822 + format message and is traditionally called the "envelope". [Note: + this should not be confused with the SMTP (RFC 821) envelope, which + is strictly limited to delivery information.] IMAP3 defines a + structured and unambiguous representation for the envelope which is + particularly nice for Lisp-based parsers. A client can use the + envelope for operations such as replying and not worry about RFC 822 + at all. Envelopes are discussed in more detail below. The first and + second category data can be fetched together by using the macro-fetch + word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE)". + + The third category is that data which is intended for direct human + viewing. The present RFC 822 based IMAP3 defines three such items: + RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two + former appended together in a single text string). Fetching "RFC822" + is equivalent to typing the RFC 822 representation of the message as + stored on the mailbox without any filtering or processing. + + Typically, a client will "FETCH ALL" for some or all of the messages + in the mailbox for use as a presentation menu, and when the user + wishes to read a particular message will "FETCH RFC822.TEXT" to get + the message body. A more primitive client could, of course, simply + "FETCH RFC822" a la POP2-type functionality. + + The client can alter certain data by means of a STORE command. As an + example, a message is deleted from a mailbox by a STORE command which + includes the \DELETED flag as one of the flags being set. + + Other client operations include copying a message to another mailbox + (COPY command), permanently removing deleted messages (EXPUNGE + command), checking for new messages (CHECK command), and searching + for messages which match certain criteria (SEARCH command). + + + +Rice [Page 11] + +RFC 1203 IMAP3 February 1991 + + + The client terminates the session with the LOGOUT command. The + server returns a "BYE" followed by an "OK". + +A Typical Scenario + + Client Server + ------ ------ + {Wait for Connection} + {Open Connection} --> + <-- * OK IMAP3 Server Ready + {Wait for command} + A001 SUPPORTED.VERSIONS --> + <-- * SUPPORTED.VERSIONS ((2 0 ) + (3 0 EIGHT.BIT.TRANSPARENT + AUTO.SET.SEEN + TAGGED.SOLICITED)) + A001 OK Supported Versions returned. + {Wait for command} + A002 SELECT.VERSION (3 0) --> + <-- A002 OK Version 3.0 Selected. + {Wait for command} + A002 SELECT.FEATURES TAGGED.SOLICITED --> + <-- A002 OK Features selected. + {Wait for command} + A003 LOGIN Fred Secret --> + <-- A003 OK User Fred logged in + {Wait for command} + A004 SELECT INBOX --> + <-- A004 FLAGS (Meeting Notice \Answered + \Flagged \Deleted \Seen) + <-- A004 19 EXISTS + <-- A004 2 RECENT + <-- A004 OK Select complete + {Wait for command} + A005 FETCH 1:19 ALL --> + <-- A005 1 Fetch (......) + ... + <-- A005 18 Fetch (......) + <-- A005 19 Fetch (......) + <-- A005 OK Fetch complete + {Wait for command} + A006 FETCH 8 RFC822.TEXT --> + <-- A006 8 Fetch (RFC822.TEXT {893} + ...893 characters of text... + <-- ) + <-- A006 OK Fetch complete + {Wait for command} + + + + +Rice [Page 12] + +RFC 1203 IMAP3 February 1991 + + + A007 STORE 8 +Flags \Deleted --> + <-- A007 8 Store (Flags (\Deleted + \Seen)) + <-- A007 OK Store complete + {Wait for command} + A008 EXPUNGE --> + <-- A008 19 EXISTS + <-- A008 8 EXPUNGE + <-- A008 18 EXISTS + <-- A008 Expunge complete + {Wait for command} + A009 LOGOUT --> + <-- A009 BYE IMAP3 server quitting + <-- A009 OK Logout complete + {Close Connection} --><-- {Close connection} + {Go back to start} + + A more complex scenario produced by a pipelining multiprocess client. + + Client Server + ------ ------ + {Wait for Connection} + {Open session as above} + <-- A004 19 EXISTS + <-- A004 2 RECENT + <-- A004 OK Select complete + {Wait for command} + A005 SEARCH RECENT --> + <-- A005 SEARCH (18 19) (RECENT) + <---A005 OK Search complete + A006 FETCH 18:19 ALL RFC822.TEXT + A007 STORE 18:19 +FLAGS (\SEEN) + A008 FETCH 1:17 ALL --> + <-- A006 18 Fetch (... RFC822.TEXT ...) + A009 STORE 18 +FLAGS (\DELETED) + <-- A006 19 Fetch (... RFC822.TEXT ...) + <-- A006 OK Fetch complete + <-- A007 18 STORE (Flags (\Seen)) + A010 STORE 19 +FLAGS (\DELETED) + <-- A007 19 STORE (Flags (\Seen)) + <-- A007 OK Store complete + <-- A008 1 Fetch (......) + ... + <-- A008 16 Fetch (......) + <-- A008 17 Fetch (......) + <-- A008 OK Fetch complete + <-- A009 18 STORE (Flags (\Seen + \Deleted)) + + + +Rice [Page 13] + +RFC 1203 IMAP3 February 1991 + + + <-- A009 OK Store complete + <-- A010 19 STORE (Flags (\Seen + \Deleted)) + <-- A010 OK Store complete + {Wait for command} + <-- * EXISTS 23 + <-- * RECENT 4 + <-- * SEARCH (20 21 22 23) (RECENT) + A011 FETCH 20:23 ALL RFC822.TEXT + +Conventions + + The following terms are used in a meta-sense in the syntax + specification below: + + An ASCII-STRING is a sequence of arbitrary ASCII characters. + + An ATOM is a sequence of ASCII characters delimited by SP or CRLF. + + A CHARACTER is any ASCII character except """", "{", CR, LF, "%", + or "\". + + A CRLF is an ASCII carriage-return character followed immediately + by an ASCII linefeed character. + + A NUMBER is a sequence of the ASCII characters which represent + decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or + ":". + + A SP is the ASCII space character. + + A TEXT_LINE is a human-readable sequence of ASCII characters up to + but not including a terminating CRLF. + + One of the most common fields in the IMAP3 protocol is a STRING, + which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside + double-quotes), or a LITERAL. A literal consists of an open brace + ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII- + STRING of n characters, where n is the value of the number inside the + brace. In general, a string should be represented as an ATOM or + QUOTED-STRING if at all possible. The semantics for QUOTED-STRING or + LITERAL are checked before those for ATOM; therefore an ATOM used in + a STRING may only contain CHARACTERs. Literals are most often sent + from the server to the client; in the rare case of a client to server + literal there is a special consideration (see the "+ text" response + below). + + Another important field is the SEQUENCE, which identifies a set of + + + +Rice [Page 14] + +RFC 1203 IMAP3 February 1991 + + + messages by consecutive numbers from 1 to n where n is the number of + messages in the mailbox. A sequence may consist of a single number, + a pair of numbers delimited by colon indicating all numbers between + those two numbers, or a list of single numbers and/or number pairs. + For example, the sequence 2,4:7,9,12:15 is equivalent to + 2,4,5,6,7,9,12,13,14,15 and identifies all of those messages. + +Definitions of Commands and Responses + + Summary of Commands and Responses + +Commands: + tag NOOP + tag LOGIN user password + tag LOGOUT + tag SELECT mailbox + tag CHECK + tag EXPUNGE + tag COPY sequence mailbox + tag FETCH sequence data + tag STORE sequence data value + tag SEARCH criteria + tag BBOARD bboard + tag FIND (BBOARDS / MAILBOXES) pattern + tag READONLY + tag READWRITE + tag SELECT.VERSION (major_version minor_version) + tag SELECT.FEATURES features + tag SUPPORTED.VERSIONS + tag FLAGS + tag SET.FLAGS + +Responses (can be either solicited or unsolicited): + */tag FLAGS flag_list + */tag SEARCH (numbers) (criteria) + */tag EXISTS + */tag RECENT + */tag EXPUNGE + */tag STORE data + */tag FETCH data + */tag BBOARD bboard_name + */tag MAILBOX non_inbox_mailbox_name + */tag SUPPORTED.VERSIONS version_data + */tag READONLY + */tag READWRITE + */tag OK text + */tag NO text + */tag BAD text + + + +Rice [Page 15] + +RFC 1203 IMAP3 February 1991 + + + */tag BYE text + +Responses (can only be solicited): + tag COPY message_number + +Responses (can only be unsolicited): + + text + +Commands + + tag NOOP + + The NOOP command returns an OK to the client. By itself, it does + nothing, but certain things may happen as side effects. For + example, server implementations which implicitly check the mailbox + for new mail may do so as a result of this command. The primary + use of this command is to for the client to see if the server is + still alive (and notify the server that the client is still alive, + for those servers which have inactivity autologout timers). + + tag LOGIN user password + + The LOGIN command identifies the user to the server and carries + the password authenticating this user. This information is used + by the server to control access to the mailboxes. + + EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with + password SESAME. + + tag LOGOUT + + The LOGOUT command indicates the client is done with the session. + The server sends a solicited BYE response before the (tagged) OK + response, and then closes the connection. + + tag SELECT mailbox + + The SELECT command selects a particular mailbox. The server must + check that the user is permitted read access to this mailbox. + Prior to returning an OK to the client, the server must send an + solicited FLAGS and <n> EXISTS response to the client giving the + flags list for this mailbox (simply the system flags if this + mailbox doesn't have any special flags) and the number of messages + in the mailbox. It is also recommended that the server send a <n> + RECENT unsolicited response to the client for the benefit of + clients which make use of the number of new messages in a mailbox. + It is further recommended that servers should send an unsolicited + READONLY message if the mailbox that has been selected is not + + + +Rice [Page 16] + +RFC 1203 IMAP3 February 1991 + + + writable by the user. + + Multiple SELECT commands are permitted in a session, in which case + the prior mailbox is deselected first. + + The default mailbox for the SELECT command is INBOX, which is a + special name reserved to mean "the primary mailbox for this user + on this server". The format of other mailbox names is operating + system dependent (as of this writing, it reflects the path of the + mailbox on the current servers), though it could reflect any + server-specific naming convention for the namespace of mailboxes. + Such a namespace need not and should not be viewed as being + equivalent or linked to the server machine's file system. + + EXAMPLES: A002 SELECT INBOX ;; selects the default mailbox. + A002 197 EXISTS ;; server says 197 messages in INBOX + A002 5 RECENT ;; server says 5 are recent. + A002 OK Select complete. + or + A003 SELECT /usr/fred/my-mail.txt + ;; select a different user specified mailbox. + ... + + tag CHECK + + The CHECK command forces a check for new messages and a rescan of + the mailbox for internal change for those implementations which + allow multiple simultaneous read/write access to the same mailbox + (e.g., TOPS-20). It is recommend that periodic implicit checks + for new mail be done by servers as well. The server must send a + solicited <n> EXISTS response prior to returning an OK to the + client. + + tag EXPUNGE + + The EXPUNGE command permanently removes all messages with the + \DELETED flag set in its flags from the mailbox. Prior to + returning an OK to the client, for each message which is removed, + a solicited <n> EXPUNGE response is sent indicating which message + was removed. The message number of each subsequent message in the + mailbox is immediately decremented by 1; this means that if the + last 5 messages in a 9-message mailbox are expunged you will + receive 5 "5 EXPUNGE" responses for message 5. To ensure mailbox + integrity and server/client synchronization, it is recommended + that the server do an implicit check prior to commencing the + expunge and again when the expunge is completed. Furthermore, if + the server allows multiple simultaneous access to the same mailbox + the server must guarantee both the integrity of the mailbox and + + + +Rice [Page 17] + +RFC 1203 IMAP3 February 1991 + + + the views of it held by the clients. + + EXPUNGE is not allowed if the user does not have write access to + this mailbox. If a user does not have write access to the mailbox + then the server is required to signal this fact by replying with a + NO response with a suitable text string that can be presented to + the user explaining that the mailbox is read-only. It is further + recommended that servers send an unsolicited READONLY message to + clients that attempt an expunge operation on a read only mailbox. + + tag COPY sequence mailbox + + The COPY command copies the specified message(s) to the specified + destination mailbox. If the destination mailbox does not exist, + the server should create it. Prior to returning an OK to the + client, the server must return a solicited <n> COPY response for + each message copied. + + EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4 to + mailbox "MEETING". + + COPY is not allowed if the user does not have write access to the + destination mailbox. If a user does not have write access to the + destination mailbox then the server is required to signal this + fact by replying with a NO response with a suitable text string + that can be presented to the user explaining that the mailbox is + read-only. It is further recommended that servers send an + unsolicited READONLY message to clients that attempt to copy to a + read only mailbox. IMAP3 does not specify "where" the message + will be put in the mailbox to which it has been copied. + + tag FETCH sequence fetch_att + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched may be either a single atom + or an S-expression list. The attributes that can be fetched are + any of those mentioned specifically below along with any generic, + canonical or concrete key. The set of predefined generic keys is: + {BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}. The set + of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}. The + value returned by the server for a non-existent or non-meaningful + key is defined to be the null value, NIL. + + ALL Equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) + + ENVELOPE The envelope of the message. The envelope is + computed by the server by parsing the header, + + + +Rice [Page 18] + +RFC 1203 IMAP3 February 1991 + + + i.e., the RFC 822 header for an RFC822 format + message, into the component parts, defaulting + various fields as necessary. + + FAST Macro equivalent to: + (FLAGS INTERNALDATE RFC822.SIZE) + + FLAGS The flags which are set for this message. + This may include the following system flags: + + \RECENT Message arrived since + last read of this mailbox + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE The date and time the message was written to + the mailbox. + + RFC822 The message in RFC 822 format. + + RFC822.HEADER The RFC 822 format header of the message. + + RFC822.SIZE The number of characters in the message as + expressed in RFC 822 format. + + RFC822.TEXT The text body of the message, omitting the + RFC 822 header. + + EXAMPLES: + + A003 FETCH 2:4 ALL + fetches the flags, internal date, RFC 822 size, and envelope + for messages 2, 3, and 4. + + A004 FETCH 3 RFC822 + fetches the RFC 822 representation for message 3. + + A005 FETCH 4 (FLAGS RFC822.HEADER) + fetches the flags and RFC 822 format header for message 4. + + A006 FETCH 42 $SUBJECT + A006 FETCH $SUBJECT "Some subject text..." + A006 OK FETCH completed ok. + fetches the canonical subject field. + + + +Rice [Page 19] + +RFC 1203 IMAP3 February 1991 + + + A007 FETCH 42 APPARENTLY-TO + A007 FETCH APPARENTLY-TO NIL + A007 OK FETCH found no value. + fetches the concrete apparently-to field. + + tag STORE sequence data value + + The STORE command alters the values associated with particular + keys for a message in the mailbox. As is the case for the FETCH + command, any generic, canonical or concrete key may be used to + index the value provided. In addition to these, the following + pre-defined keys are provided. + + FLAGS Replace the flags for the message with the + argument (in flag list format). + The server must respond with a solicited STORE FLAGS + message, showing the new state of the flags after + the store. + + +FLAGS Add the flags in the argument to the + message's flag list. + The server must respond with a solicited STORE FLAGS + message, showing the new state of the flags after + the store. + + -FLAGS Remove the flags in the argument from the + message's flag list. + The server must respond with a solicited STORE FLAGS + message, showing the new state of the flags after + the store. + + RFC822.HEADER Replace the header of the message(s) with that + specified. This allows users to use their mailboxes + as databases with header fields as keys. + The server must respond with solicited + STORE RFC822.HEADER, STORE RFC822.SIZE and + STORE ENVELOPE messages, showing the new state + of the reparsed header after the store. + + RFC822.TEXT Replace the body of the messages with that specified. + The server must respond with solicited + STORE RFC822.TEXT and STORE RFC822.SIZE messages, + showing the new state of the message after the store. + + STORE is not allowed if the user does not have write access to + this mailbox. + + The server is required to send a solicited STORE response for + + + +Rice [Page 20] + +RFC 1203 IMAP3 February 1991 + + + each store operation that results in a format transformation by + the server. For example, the server is required to send a + STORE FLAGS response when the client performs a STORE +FLAGS or + a STORE -FLAGS, since the client may not easily be able to know + what the result of this command will be. Similarly, if the + client emits a STORE FROM command then the server should + respond with a suitable STORE FROM response because the client + would be sending a string value to be stored and the server + should transform this into a set of addresses. In general, + however, although it is legal for the server to send a + solicited STORE response for each STORE operation, this is + discouraged, since it might result in the retransmission of + very large and unnecessary amounts of data that have been + stored. + + EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3, + and 4 for deletion. + + tag SEARCH search_criteria + + The SEARCH command searches the mailbox for messages which match + the given set of criteria. The server response SEARCH (criteria) + (numbers) gives the set of messages which match the conjunction of + the criteria specified. In addition to each of the search + criteria there is its logical inverse. The logical inverse + criterion is denoted by the ~ (tilda) sign. + + Thus, no message that matches the criterion: + FROM crispin + + will match the criterion: + ~FROM crispin + + The criteria for the search can be any generic, canonical or + concrete key. In addition to these, the following pre-defined + keys are also provided: + + ALL All messages in the mailbox; the default + initial criterion for ANDing. + + ANSWERED Messages with the \ANSWERED flag set. + + BCC string Messages which contain the specified string + in the envelope's BCC field. + + BEFORE date Messages whose internal date is earlier than + the specified date. + + + + +Rice [Page 21] + +RFC 1203 IMAP3 February 1991 + + + BODY string Messages which contain the specified string + in the body of the message. + + CC string Messages which contain the specified string + in the envelope's CC field. + + DELETED Messages with the \DELETED flag set. + + FLAGGED Messages with the \FLAGGED flag set. + + FROM string Messages which contain the specified string + in the envelope's FROM field. + + HEADER string Messages which contain the specified string + in the message header. + + KEYWORD flag Messages with the specified flag set. + + NEW Messages which have the \RECENT flag set but + not the \SEEN flag. This is functionally + equivalent to "RECENT UNSEEN". + + OLD Messages which do not have the \RECENT flag + set. + + ON date Messages whose internal date is the same as + the specified date. + + RECENT Messages which have the \RECENT flag set. + + SEEN Messages which have the \SEEN flag set. + + SINCE date Messages whose internal date is later than + the specified date. + + SUBJECT string Messages which contain the specified string + in the envelope's SUBJECT field. + + TEXT string Messages which contain the specified string. + + TO string Messages which contain the specified string in + the envelope's TO field. + + EXAMPLE: A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 + returns the message numbers for all deleted messages from Smith + that were placed in the mailbox since October 1, 1987. + + Implementation note: The UNANSWERED, UNDELETED, UNFLAGGED, + + + +Rice [Page 22] + +RFC 1203 IMAP3 February 1991 + + + UNKEYWORD and UNSEEN criteria, described below, are preserved in + IMAP3 for IMAP2 compatibility. They are, however, considered + obsolete and new Client programs are encouraged to use the ~ + notation for the logical inverses of search criteria with a view + to the dropping of this outmoded syntax in later versions. + + UNANSWERED Messages which do not have the \ANSWERED flag + set. + + UNDELETED Messages which do not have the \DELETED flag + set. + + UNFLAGGED Messages which do not have the \FLAGGED flag + set. + + UNKEYWORD flag Messages which do not have the specified flag + set. + + UNSEEN Messages which do not have the \SEEN flag set. + + tag READONLY + + The READONLY command indicates that the client wishes to make the + mailbox read-only. The server is required to reply with a + solicited READONLY or READWRITE response. + + tag READWRITE + + The READWRITE command indicates that the client wishes to make the + mailbox read-write. The server is required to reply with a + solicited READONLY or READWRITE response. + + tag SUPPORTED.VERSIONS + + The SUPPORTED.VERSIONS solicits from the server a + SUPPORTED.VERSIONS message, which encapsulates information about + which versions and features the server supports. + + tag SELECT.VERSION (major_version minor_version) + + The SELECT.VERSION command indicates that the client wishes to + select certain behavior on the part of the server. The major and + minor versions indicate the specific version of the protocol being + selected. + + EXAMPLE: A002 SELECT.VERSION (3 0) + + A client may not request a server version that is not supported by + + + +Rice [Page 23] + +RFC 1203 IMAP3 February 1991 + + + the server, i.e., which is specifically mentioned in the response + to a SUPPORTED.VERSIONS command. An attempt to do so by a client + will result in a NO response from the server. It is an error for + the SELECT.VERSION command to be used after a mailbox has been + selected. The rationale for this is that for some server + implementations it might be necessary to spawn separate programs + to implement widely divergent protocol versions. Thus, the client + cannot be allowed to expect any server state to be preserved after + the use of the SELECT.VERSION command. The default version of all + servers is 2.0, i.e., IMAP2 as defined by RFC 1064. + + tag SELECT.FEATURES 1#features + + The SELECT.FEATURES command indicates that the client wishes to + select certain specific features on the part of the server. A + client may not request a feature that is not supported by the + server, i.e., one that is explicitly mentioned in the set of + features for the selected version returned by the + SUPPORTED.VERSIONS command. An attempt to do so by a client will + result in a NO response from the server. + + EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED + EIGHT.BIT.TRANSPARENT + + i.e., select the set of features called AUTO.SET.SEEN and + EIGHT.BIT.TRANSPARENT and deselect the feature called + TAGGED.SOLICITED. The use of the SELECT.FEATURES command + completely resets the set of selected features. Note: These are + only example feature names and are not necessarily supported by + any server. See the appendix on features for more information on + features. Note: Some features, when present in the server, will + cause the upwards compatible extension of the grammar, i.e., by + adding extra commands. The server is at liberty not to remove + these upwards compatible extensions to the command tables when a + feature is disabled. Thus, it is an error for a client to rely on + getting a NO or BAD response in any way, for instance to determine + the selectedness or presence of a feature. + + tag BBOARD bboard + + The BBOARD command is equivalent to SELECT, except that its + argument is a bulletin board (BBoard) name. The format of a + BBoard name is implementation specific, although it is strongly + encouraged to use something that resembles a name in a generic + sense and not a file or mailbox name on the particular system. + There is no requirement that a BBoard name be a mailbox name or a + file name (in particular, Unix netnews has a completely different + namespace from mailbox or file names). + + + +Rice [Page 24] + +RFC 1203 IMAP3 February 1991 + + + The result from the BBOARD command is identical from that of the + SELECT command. For example, in the TOPS-20 server + implementation, the command + A0002 BBOARD FOO + is exactly equivalent to the command + A0002 SELECT POBOX:<BBOARD>FOO.TXT + Note: the equivalence in this example is *not* required by the + protocol, and merely reflects the fuzzy distinction between + mailboxes and BBoards on TOPS-20. + + tag FIND (BBOARDS / MAILBOXES) pattern + + The FIND command accepts as arguments the keywords BBOARDS or + MAILBOXES and a pattern which specifies some set of BBoard/mailbox + names which are usable by the BBOARD/SELECT command. Two wildcard + characters are defined; "*" specifies that any number (including + zero) characters may match at this position and "%" specifies that + a single character may match at this position. For example, + FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas + FOO%BAR will match only FOO.BAR; furthermore, "*" will match all + BBoards/mailboxes. The following quoting convention applies to + wildcards: "\*" is the literal "*" character, "\%" is the literal + "%" character and "\\" is the literal "\" character. Notes: The + format of mailboxes is server implementation dependent. The + special mailbox name INBOX is not included in the output to the + FIND MAILBOXES command. + + The FIND command solicits any number of BBOARD or MAILBOX + responses from the server as appropriate. + + Examples: + A0002 FIND BBOARDS * + A0002 BBOARD FOOBAR + A0002 BBOARD GENERAL + A0002 OK FIND completed + or + A0002 FIND MAILBOXES FOO%BA* + A0002 MAILBOX FOO.BAR + A0002 MAILBOX FOO.BAZZAR + A0002 OK FIND completed + + Note: Although the use of explicit file or path names for + mailboxes is discouraged by this standard, it may be unavoidable. + It is important that the value returned in the MAILBOX solicited + reply be usable in the SELECT command without remembering any path + specification which may have been used in the FIND MAILBOXES + pattern. + + + + +Rice [Page 25] + +RFC 1203 IMAP3 February 1991 + + + tag FLAGS + + The FLAGS command solicits a FLAGS response from the server. + + tag SET.FLAGS flag_list + + The SET.FLAGS command defines the user specifiable flags for this + mailbox, i.e., the keywords. If this set does not include flags + formerly sent to the client by the server in a FLAGS message then + this constitutes a request to delete the flag. Any new flags + should be created. This command does not affect the system + defined flags and any system flags that are included in the + flag_list will be ignored. The server must respond to this + command with a solicited FLAGS message. If the deletion of a flag + results in the invalidation of the flag sets of any messages then + the server is required to send solicited STORE FLAGS messages to + the client for each modified message. + +Responses: + + */tag OK text + + In its solicited form this response identifies successful + completion of the command with the indicated tag. The text is a + line of human-readable text which may be useful in a protocol + telemetry log for debugging purposes. + + In its unsolicited form, this response indicates simply that the + server is alive. No special action on the part of the client is + called for. This is presently only used by servers at startup as + a greeting message indicating that they are ready to accept the + first command. This usage, although legal, is by no means + required. The text is a line of human-readable text which may be + logged in protocol telemetry. + + */tag NO text + + In its solicited form this response identifies unsuccessful + completion of the command with the indicated tag. The text is a + line of human-readable text which probably should be displayed to + the user in an error report by the client. + + In its unsolicited form this response indicates some operational + error at the server which cannot be traced to any protocol + command. The text is a line of human-readable text which should + be logged in protocol telemetry for the maintainer of the server + and/or the client. + + + + +Rice [Page 26] + +RFC 1203 IMAP3 February 1991 + + + */tag BAD text + + In its solicited form response indicates faulty protocol received + from the client and indicates a bug. The text is a line of + human-readable text which should be recorded in any telemetry as + part of a bug report to the maintainer of the client. + + In its unsolicited form response indicates some protocol error at + the server which cannot be traced to any protocol command. The + text is a line of human-readable text which should be logged in + protocol telemetry for the maintainer of the server and/or the + client. This generally indicates a protocol synchronization + problem, and examination of the protocol telemetry is advised to + determine the cause of the problem. + + */tag BYE text + + This indicates that the server is about to close the connection. + The text is a line of human-readable text which should be + displayed to the user in a status report by the client. IMAP2 + requires that the server emit a solicited BYE response as part of + a normal logout sequence. This solicited form is not required + under IMAP3, though is still legal for compatibility. In its + unsolicited form the BYE response is used as a panic shutdown + announcement by the server. It is required to be used by any + server which performs autologouts due to inactivity. + + */tag number message_data + + The solicited (tag number message_data) response is generated as + the result of a number of client requests. The server may also + emit any the following at any time as unsolicited data (i.e., * + number message_data). The message_data is one of the following: + + EXISTS The specified number of messages exists in the mailbox. + + RECENT The specified number of messages have arrived since the + last time this mailbox was selected with the SELECT + command or equivalent. + + EXPUNGE The specified message number has been permanently + removed from the mailbox, and the next message in the + mailbox (if any) becomes that message number. + The server must send a solicited EXPUNGE response + for each message that it expunges as the result + of an EXPUNGE command. Note: future versions of the + protocol may allow the use of a message sequence + as a value returned by the EXPUNGE response to allow the + + + +Rice [Page 27] + +RFC 1203 IMAP3 February 1991 + + + more efficient compaction of client representations of + mailboxes. + + STORE data + Functionally equivalent to FETCH, only it is sent by the + server when the state of a mailbox changes. The server + must send solicited STORE responses as the result of + any change caused by a STORE command. + + FETCH data + This is the principle means by which data about a + message is sent to the client. The data is in a + Lisp-like S-expression property list form. Just as the + FETCH request from the client can fetch any generic, + canonical or concrete key, so also the FETCH response + can return values for any of these keys as well as for + the pre-defined attributes mentioned below. Note that + the server is permitted to send any unsolicited FETCH + or STORE messages that it should choose, be they the + values associated with generic, canonical or concrete + keys. Clients are required to ignore any such + FETCH responses that it cannot interpret. For example, + clients are not required to be able to understand, i.e., + use fruitfully, the canonical $TO key, but they are + required to be able to ignore an unsolicited $TO message + correctly. + + ENVELOPE An S-expression format list which describes the + envelope of a message. The envelope is computed + by the server by parsing the RFC 822 header into + the component parts, defaulting various fields + as necessary. + + The fields of the envelope are in the following + order: date, subject, from, sender, reply-to, to, + cc, bcc, in-reply-to, and message-id. The date, + subject, in-reply-to, and message-id fields are + strings. The from, sender, reply-to, to, cc, + and bcc fields are lists of addresses. + + An address is an S-expression format list which + describes an electronic mail address. The fields + of an address are in the following order: + personal name, source-route (i.e., the + at-domain-list in SMTP), mailbox name, host name + and comments. Implementation note: The addition + of the comment field is an incompatible extension + from IMAP2. The server is required not to provide + + + +Rice [Page 28] + +RFC 1203 IMAP3 February 1991 + + + this field when running in IMAP2 mode. + + Any field of an envelope or address which is + not applicable is presented as the atom NIL. + Note that the server must default the reply-to + and sender fields from the from field; a client is + not expected to know to do this. + + FLAGS An S-expression format list of flags which are set + for this message. This may include the following + system flags: + + \RECENT Message arrived since last + read of this mailbox + \SEEN Message has been read + \ANSWERED Message has been answered + \FLAGGED Message is "flagged" for + urgent/special attention + \DELETED Message is "deleted" for + removal by later EXPUNGE + + INTERNALDATE A string containing the date and time the + message was written to the mailbox. + + RFC822 A string expressing the message in RFC 822 + format. + Note: Some implementations of IMAP2 servers + had the (undocumented) behavior of setting + the \SEEN flag as a side effect of fetching + the body of a message. This resulted in + erroneous behavior for clients that prefetch + messages that the user might not get + around to reading. Thus, this behavior is + explicitly disallowed in IMAP3. + Note: this is not a significant performance + restriction because it is always possible for + IMAP3 clients to use an interaction with the + server of the following type: + A001 FETCH 42 RFC822 + A002 STORE 42 +FLAGS (\SEEN) + A001 42 FETCH RFC822 {637} ...... + A001 OK Fetch completed + A002 42 STORE FLAGS (\SEEN \FLAGGED...) + A002 OK Store Completed. + + RFC822.HEADER A string expressing the RFC 822 format + header of the message + + + + +Rice [Page 29] + +RFC 1203 IMAP3 February 1991 + + + RFC822.SIZE A number indicating the number of + characters in the message as expressed + in RFC 822 format. + + RFC822.TEXT A string expressing the text body of the + message, omitting the RFC 822 header. + See also note for RFC822. + + */tag FLAGS flag_list + + A solicited FLAGS response must occur as a result of a SELECT + command. The flag list is the list of flags (at a minimum, the + IMAP defined flags) which are applicable for this mailbox. Flags + other than the system flags are a function of the server + implementation. + + */tag SEARCH (numbers) (search_criteria) + + This response occurs as a result of a SEARCH command. The + number(s) refer to those messages which match the search criteria. + In its solicited form this message allows clients to find + interesting groups of messages, e.g., unseen messages from + Crispin. In its unsolicited form it allows the server to inform + the client of interesting patterns, e.g., when new mail arrives, + recent and from Crispin. Compatibility note: The search_criteria + are sent by the server along with the matching numbers so + unsolicited SEARCH messages may be interpreted. This syntax is + not upwards compatible with IMAP2 and so the new syntax is + intended to make it simple for clients that are not able to take + advantage of unsolicited SEARCH messages still to interpret + solicited SEARCH messages simply by ignoring everything that + follows the list of numbers with minimal parsing. Such clients + may not, however, simply discard the rest of the line because + there might be LITERALs in the search pattern. + + Examples: + A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN) + and + * SEARCH (42) (FROM Crispin RECENT) + + */tag READONLY + + This indicates that the mailbox is read-only. The server is + required to respond to a READONLY or READWRITE command with either + a solicited READONLY or a solicited READWRITE response. Note: If + the client attempts a mutation operation, such as STORE, on a + mailbox to which it does not have write access then the server is + required to reply with a solicited READONLY response on the first + + + +Rice [Page 30] + +RFC 1203 IMAP3 February 1991 + + + such attempted mutation. The server may also choose to send + solicited READONLY responses for each subsequent attempted + mutation. + + */tag READWRITE + + This indicates that the mailbox is read-write. The server is + required to respond to a READONLY or READWRITE command with either + a solicited READONLY or a solicited READWRITE response. + + */tag BBOARD bboard_name + + This message is produced in its solicited form as a response to a + FIND BBOARDS command. In its unsolicited form it represents a + notification by the server that a new BBoard has been added. + Bboard_name must be a name that can be supplied to the BBOARD + command so as to select the appropriate bboard. + + */tag MAILBOX non_inbox_mailbox_name + + This message is produced in its solicited form as a response to a + FIND MAILBOXES command. In its unsolicited form it represents a + notification by the server that a new mailbox has been added, + perhaps as the result of a COPY command creating a new mailbox. + Non_inbox_mailbox_name must be a name that can be supplied to the + SELECT command so as to select the appropriate mailbox. Note: + non_inbox_mailbox_name is never the string "INBOX". + + */tag SUPPORTED.VERSIONS (version_specs) + + This message is used either as a response to the + SUPPORTED.VERSIONS or, in its unsolicited form, to indicate the + dynamic addition or removal of support for features or protocol + versions. Each version_spec is of the form (4 2 + EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN ...), i.e., a major version + number and a minor version number for the protocol and the set of + features supported under the server's implementation of that + protocol version. A server may not dynamically remove support for + any version or feature that has been selected by any currently + logged in client by the use of the VERSION command. + + Example: + A00005 SUPPORTED.VERSIONS ((2 0 ) + (2 2 TAGGED.SOLICITED) + (3 0 EIGHT.BIT.TRANSPARENT TAGGED.SOLICITED)) + + Indicates that two major versions are supported and one minor + version is supported and that tagged solicited messages are + + + +Rice [Page 31] + +RFC 1203 IMAP3 February 1991 + + + supported in versions 2.2 and 3.0 with eight bit characters being + supported under version 3. For each feature mentioned in the list + of features there is also always the negation of that feature. + For example, if the server supports the TAGGED.SOLICITED feature + then it also supports the ~TAGGED.SOLICITED feature, which + disables this feature. Note: These are only example feature + names and are not necessarily supported by any server. See the + appendix on features for more information on features. + + + text + + This response indicates that the server is ready to accept the + text of a literal from the client. Normally, a command from the + client is a single text line. If the server detects an error in + the command, it can simply discard the remainder of the line. It + cannot do this in the case of commands which contain literals, + since a literal can be an arbitrarily long amount of text, and the + server may not even be expecting a literal. This mechanism is + provided so the client knows not to send a literal until the + server definitely expects it, preserving client/server + synchronization. + + In actual practice, this situation is rarely encountered. In the + current protocol, the only client commands likely to contain + literals are the LOGIN command and the STORE RFC822.HEADER or + STORE RFC822.TEXT commands. Consider a situation in which a + server validates the user before checking the password. If the + password contains "funny" characters and hence is sent as a + literal, then if the user is invalid an error would occur before + the password is parsed. + + No such synchronization protection is provided for literals sent + from the server to the client, for performance reasons. Any + synchronization problems in this direction would be due to a bug + in the client or server and not for some operational problem. + +Sample IMAP3 session + + The following is a transcript of an actual IMAP3 session. Server + output is identified by "S:" and client output by "U:". In cases + where lines were too long to fit within the boundaries of this + document, the line was continued on the next line preceded by a tab. + + S: * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol + III Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT + U: a001 SUPPORTED.VERSIONS + S: * SUPPORTED.VERSIONS ((2 0 ) (3 0 EIGHT.BIT.TRANSPARENT + AUTO.SET.SEEN TAGGED.SOLICITED)) + + + +Rice [Page 32] + +RFC 1203 IMAP3 February 1991 + + + S: A001 Supported Versions returned. + U: a002 SELECT.VERSION (3 0) + S: a002 OK Version 3.0 Selected. + U: a003 SELECT.FEATURES TAGGED.SOLICITED + S: a003 OK Features selected. + U: a004 login crispin secret + S: a004 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT, + job 76 + U: a005 select inbox + S: a005 FLAGS (Bugs SF Party Skating Meeting Flames Request AI + Question Note \XXXX \YYYY \Answered \Flagged \Deleted + \Seen) + S: a005 16 EXISTS + S: a005 0 RECENT + S: a006 OK Select complete + U: a006 fetch 16 all + S: a006 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55: + RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT" + "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN" + "SUMEX-AIM.Stanford.EDU" NIL)) ((NIL NIL "rindflEISCH" + "SUMEX-AIM.Stanford.EDU" NIL)) NIL NIL NIL + "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) + S: a006 OK Fetch completed + U: a007 fetch 16 rfc822 + S: a007 16 Fetch (RFC822 {637} + S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43 + S: Mail-From: FAGAN created at 4-Jun-88 13:27:12 + S: Date: Sat, 4 Jun 88 13:27:11 PDT + S: From: Larry Fagan <FAGAN@SUMEX-AIM.Stanford.EDU> + S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU + S: Subject: INFO-MAC Mail Message + S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> + S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT + S: ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU> + S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, + Crispin@SUMEX-AIM.Stanford.EDU + S: ReSent-Message-ID: + <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> + S: + S: The file is <info-mac>usenetv4-55.arc ... + S: Larry + S: ------- + S: ) + S: a007 OK Fetch completed + U: a008 logout + S: a008 BYE UNIX IMAP III server terminating connection + + + +Rice [Page 33] + +RFC 1203 IMAP3 February 1991 + + + S: a008 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol + Service logout + +Implementation Discussion + + As of this writing, SUMEX has completed an IMAP2 client for Xerox + Lisp machines written in hybrid Interlisp/CommonLisp and is beginning + distribution of a client for TI Explorer Lisp machines. SUMEX has + also completed a portable IMAP2 client protocol library module + written in C. This library, with the addition of a small main + program (primarily user interface) and a TCP/IP driver, became a + rudimentary remote system mail-reading program under Unix. The first + production use of this library is as a part of a MacII client which + has now been under daily use (by real users) at Stanford for quite + some time. + + As of this writing, SUMEX has completed IMAP2 servers for TOPS-20 + written in DEC-20 assembly language and 4.2/3 BSD Unix written in C. + The TOPS-20 server is fully compatible with MM-20, the standard + TOPS-20 mailsystem, and requires no special action or setup on the + part of the user. The INBOX under TOPS-20 is the user's MAIL.TXT. + The TOPS-20 server also supports multiple simultaneous access to the + same mailbox, including simultaneous access between the IMAP3 server + and MM-20. The 4.2/3 BSD Unix server requires that the user use + either Unix Mail format or mail.txt format which is compatible with + SRI MM-32 or Columbia MM-C. The 4.2/3 BSD Unix server allows + simultaneous read access; write access must be exclusive. There is + also an experimental IMAP3 server running on the TI Explorer class of + machine, which uses MM mailbox format and which can communicate over + both TCP and Chaos. + + The Xerox Lisp client and DEC-20 server have been in production use + for over two years; the Unix server was been in production use for + over a year. IMAP3 has been used to access mailboxes at remote sites + from a local workstation via the Internet. For example, from the + Stanford local network one of the authors has read his mailbox at a + Milnet site. + + A number of IMAP clients have now been developed or are being + developed. Amongst these are versions that run on the following + machines: + + . Xerox Lisp machines + . Apple Macintosh + . NeXT + . IBM PC + . TI Explorer Lisp machines + . "Glass teletype" version that runs under Unix + + + +Rice [Page 34] + +RFC 1203 IMAP3 February 1991 + + + . GNU Emacs + . X Windows + . NTT ELIS + + Each of these client programs is carefully tuned to optimize the + performance and user interface in a manner that is consistent with + the the user interface model of the native machine. For example, the + Macintosh client features a "messy-desk" interface that allows the + cutting and pasting of text with the use of the clipboard with a menu + driven interface with keyboard accelerators. + + This specification does not make any formal definition of size + restrictions, but some of the existing servers have the following + limitations: + + DEC-20 + . length of a mailbox: 7,077,888 characters + . maximum number of messages: 18,432 messages + . length of a command line: 10,000 characters + . length of the local host name: 64 characters + . length of a "short" argument: 39 characters + . length of a "long" argument: 491,520 characters + . maximum amount of data output in a single fetch: + 655,360 characters + + TI-Explorer + . length of a mailbox: limited by the Minimum of the size of the + virtual address space and the size of the file system + . maximum number of messages: limited by the the size of the + virtual address space + . length of a command line: limited by the the size of the + virtual address space + . length of the local host name: limited by the the size of the + virtual address space + . length of a "short" argument: limited by the the size of the + virtual address space + . length of a "long" argument: limited by the the size of the + virtual address space + . maximum amount of data output in a single fetch: not limited + + Typical values for these limits are 30Mb for file systems and 128Mb + for virtual address space. + + To date, nobody has run up against any of these limitations, many of + which are substantially larger than most current user mail reading + programs. + + There are several advantages to the scheme of tags and solicited + + + +Rice [Page 35] + +RFC 1203 IMAP3 February 1991 + + + responses and unsolicited data. First, the infamous synchronization + problems of SMTP and similar protocols do not happen with tagged + commands; a command is not considered satisfied until a completion + acknowledgement with the same tag is seen. Tagging allows an + arbitrary amount of other responses ("solicited" data) to be sent by + the server with no possibility of the client losing synchronization. + Compare this with the problems that FTP or SMTP clients have with + continuation, partial completion, and commentary reply codes. + + Another advantage is that a non-lockstep client implementation is + possible. The client could send a command, and entrust the handling + of the server responses to a different process which would signal the + client when the tagged response comes in. Some clients might be + implemented in a thoroughly asynchronous manner, having, perhaps, + multiple outstanding commands at any given time. Note: this does + not require that the server process these commands in anything other + than a lock-step manner. It simply allows clients to take advantage + of servers that are able to do such asynchronous operations. + + It was observed that synchronization problems can occur with literals + if the literal is not recognized as such. Fortunately, the cases in + which this can happen are relatively rare; a mechanism (the special + "+" tag response) was introduced to handle those few cases which + could happen. The proper way to address this problem in all cases is + probably to move towards a record-oriented architecture instead of + the text stream model provided by TCP. + + Unsolicited data needs some discussion. Unlike most protocols, in + which the server merely does the client's bidding, an IMAP3 server + has a semi-autonomous role. By means of sending "unsolicited data", + the server is in effect sending a command to the client -- to update + and/or extend its (incomplete) model of the mailbox with new + information from the server. In this viewpoint, although a "fetch" + command is a request for specific information from the client, the + server is always at liberty to include more than the desired data as + "unsolicited". A server acknowledgement to the "fetch" is a + statement that at least all the requested data has been sent. + + In terms of implementation, a simple lock-step client may have a + local cache of data from the mailbox. This cache is incomplete in + general, and at select time is empty. A listener on the IMAP + connection in the client processes all solicited and unsolicited data + symmetrically, and updates the cache based on this data, i.e., the + client faults on a cache miss and asks the server to fill that cache + slot synchronously. If a tagged completion response arrives, the + listener unblocks the process which sent the tagged request. + + Clearly, given this model it is not strictly necessary to distinguish + + + +Rice [Page 36] + +RFC 1203 IMAP3 February 1991 + + + most solicited from unsolicited data. Doing so, however, apart from + being clearer, also allows such simplistic, lock-step client + implementations that extract the specific value of the response to + command by trapping the tagged response. This allows the client not + to have to block on some complex predicate that involves watching to + see an update in a cache cell. + + For example, perhaps as a result of opening a mailbox, solicited data + from the server arrives. The first piece of data is the number of + messages. This is used to size the cache; note that, if new mail + arrives, by sending a new "number of messages" unsolicited data + message server will cause the cache to be re-sized. If the client + attempts to access information from the cache, it will encounter + empty spots which will trigger "fetch" requests. The request would + be sent, some solicited data including the answer to the fetch will + flow back, and then the "fetch" response will unblock the client. + + People familiar with demand-paged virtual memory design will + recognize this model as being very similar to page-fault handling on + a demand-paged system. + +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 + a comma. + +address ::= "(" addr_name SP addr_adl SP addr_mailbox SP + addr_host addr_comment ")" + +addr_adl ::= nil / string + +addr_comment ::= nil / string + +addr_host ::= nil / string + +addr_mailbox ::= nil / string + +addr_name ::= nil / string + +bboard ::= "BBOARD" SP bboard_name + +bboard_name ::= string + +bboard_notify ::= "BBOARD" sp bboard_name + +canonical_key ::= "$CC" / "$FROM" / "$SUBJECT" / "$TO" + + + +Rice [Page 37] + +RFC 1203 IMAP3 February 1991 + + +check ::= "CHECK" + +concrete_key ::= string + +copy ::= "COPY" SP sequence SP mailbox + +criterion ::= "ALL" / "ANSWERED" / + "BCC" SP string / "BEFORE" SP string / + "BODY" SP string / "CC" SP string / "DELETED" / + "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / + "ON" SP string / "RECENT" / "SEEN" / + "SINCE" SP string / "TEXT" SP string / + "TO" SP string / "UNANSWERED" / "UNDELETED" / + "UNFLAGGED" / "UNKEYWORD" / "UNSEEN" / key SP string + +criteria ::= 1#criterion + +data ::= ("FLAGS" SP flag_list / + search_notify / bboard_notify / mailbox_notify / + supported_versions_notify / "READONLY" / "READWRITE" / + "BYE" SP text_line / "OK" SP text_line / + "NO" SP text_line / "BAD" SP text_line) + +date ::= string in form "dd-mmm-yy hh:mm:ss-zzz" + +envelope ::= "(" env_date SP env_subject SP env_from SP + env_sender SP env_reply-to SP env_to SP + env_cc SP env_bcc SP env_in-reply-to SP + env_message-id ")" + +env_bcc ::= nil / "(" 1*address ")" + +env_cc ::= nil / "(" 1*address ")" + +env_date ::= string + +env_from ::= nil / "(" 1*address ")" + +env_in-reply-to ::= nil / string + +env_length ::= NUMBER + +env_message-id ::= nil / string + +env_reply-to ::= nil / "(" 1*address ")" + +env_sender ::= nil / "(" 1*address ")" + + + + +Rice [Page 38] + +RFC 1203 IMAP3 February 1991 + + +env_subject ::= nil / string + +env_to ::= nil / "(" 1*address ")" + +expunge ::= "EXPUNGE" + +feature ::= ATOM + +fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / + fetch_att / "(" 1#fetch_att ")") + +fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / + "RFC822.TEXT" / key + +find ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern + +flag_list ::= ATOM / "(" 1#ATOM ")" + +flags ::= "FLAGS" + +generic_key ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" / + "SUBJECT" / "TEXT" / "TO" + +key ::= generic_key / canonical_key / concrete_key + +literal ::= "{" NUMBER "}" CRLF ASCII-STRING + +login ::= "LOGIN" SP userid SP password + +logout ::= "LOGOUT" + +mailbox ::= "INBOX" / string + +mailbox_notify ::= MAILBOX non_inbox_mailbox_name + +msg_copy ::= "COPY" + +msg_data ::= (msg_exists / msg_recent / msg_expunge / + msg_fetch / msg_copy) + +msg_exists ::= "EXISTS" + +msg_expunge ::= "EXPUNGE" + +msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP + env_length envelope / "FLAGS" SP "(" 1#(recent_flag + flag_list) ")" / "INTERNALDATE" SP date / + + + +Rice [Page 39] + +RFC 1203 IMAP3 February 1991 + + + "RFC822" SP string / "RFC822.HEADER" SP string / + "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP + string / key SP string_list) ")" + +msg_recent ::= "RECENT" + +msg_num ::= NUMBER + +nil ::= "NIL" + +non_inbox_mailbox_name ::= string + +noop ::= "NOOP" + +numbers ::= 1#NUMBER + +password ::= string + +pattern ::= string + +recent_flag ::= "\RECENT" + +read_only ::= "READONLY" + +read_write ::= "READWRITE" + +ready ::= "+" SP text_line + +request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags ) CRLF + +response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF + +search ::= "SEARCH" SP criteria + +search_notify ::= "SEARCH" SP (numbers) SP (criteria) + +select ::= "SELECT" SP mailbox + +select_features ::= "SELECT.FEATURES" 1#feature + +select_version ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")" + +sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" + sequence) + + + +Rice [Page 40] + +RFC 1203 IMAP3 February 1991 + + +set_flags ::= "SET.FLAGS" SP flag_list + +solicited ::= tag SP (msg_num SP msg_data / data / + solicited_only) CRLF + +solicited_only ::= {None currently defined} + +store ::= "STORE" SP sequence SP store_att + +store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / + "FLAGS" SP flag_list / RFC822.TEXT SP string + / RFC822.HEADER SP string / key SP string) + +string ::= atom / """" 1*character """" / literal + +string_list ::= string / ("(" 1#string ")") + +supported_versions ::= "SUPPORTED.VERSIONS" + +supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec + ")" + +system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP + "\SEEN" + +tag ::= atom + +unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF + +userid ::= string + +version_spec ::= "(" NUMBER SP NUMBER SP 1#feature ")" + +Appendix: Features. + + In this section we outline the standard features that are supported + by all IMAP3 servers and identify those features which are + recommended or experimental. For each of these features the default + setting is specified. This means that it is required of any server + that supports a given feature to make the default enabledness of that + feature as is specified below. It is required that for each feature + supported by a server the inverse feature should also be supported. + The inverse feature name shall always be defined as the feature name + preceded by the "~" character. Thus, the AUTO.SET.SEEN feature is + disabled by the ~AUTO.SET.SEEN feature. + + + + + + +Rice [Page 41] + +RFC 1203 IMAP3 February 1991 + + + Required Features: + + AUTO.SET.SEEN - When this features is enabled (default is disabled), + the \\SEEN flag is set for all appropriate messages as a side + effect of any of the following: + FETCH of RFC822 + FETCH of RFC822.TEXT + COPY + Justification: This feature is provided for the use of clients + that are unable to pipeline their commands effectively and + communicate over high latency connections. When disabled, + the server will not perform any such side effects. This feature + is also provided so as to smooth the transition from IMAP2 to + IMAP3. + + + TAGGED.SOLICITED - When this feature is enabled (default is enabled + for IMAP3, disabled for IMAP2 mode), solicited responses from + the server will have the tag specified by the client. + When this feature is disabled, solicited responses from the + server will have the IMAP2 compatible tag "*", not the + tag specified by the client. + Justification: This feature is provided so as to smooth the + transition from IMAP2 to IMAP3. + + Recommended Features. + + EIGHT.BIT.TRANSPARENT - When this feature is enabled + (default is disabled), the server allows the transparent + transmission of eight bit characters. When this feature is + disabled, the value of any bit other than the least significant + 7 bits transmitted by the server is unspecified. If this + feature is enabled, the characters that compose all command + keywords specified in the IMAP3 grammar and all feature names + use only their 7 least significant bits. + Justification: This feature is provided for the purpose of + supporting national character sets within messages, encoded + languages such as Japanese Kanji characters and also of binary + data, such as programs, graphics and sound. + + + NEW.MAIL.NOTIFY - When this feature is enabled (default is + disabled for compatibility with the majority of existing + IMAP2 servers), the server will notify the client of the + arrival of new mail in the currently selected mailbox + using the appropriate RECENT and EXISTS unsolicited messages + without the client needing to send periodic CHECK commands. + Justification: This feature is provided to allow clients to + + + +Rice [Page 42] + +RFC 1203 IMAP3 February 1991 + + + switch off any periodic polling strategy that they may use + to look for new mail. Such polling unnecessarily uses bandwidth + and can cause the interactive performance to degrade because + the user can be kept waiting while some background process + is doing a CHECK. + + + SEND - When this feature is enabled (default is disabled) a new + "SEND" command becomes available to the client. The SEND + command instructs the server to send a message, rather + than requiring the client to use its own, local message + sending capability, for example. An example of of the + send command might be as follows: + tag42 SEND RFC822 {2083} + From: James Rice <Rice@Sumex-Aim.Stanford.Edu> + To:..... + If the server is unable to parse the message being sent then + it is required to issue a suitable NO notification to the client. + If the message cannot be delivered for some reason then the + server should send a suitable message to the FROM: address + of the message detailing the delivery failure. + When the SEND feature is enabled, the "send" production in + the grammar is added and as defined below. The "send" + request is added to the list of requests in the request + production also as shown below: + + message_format ::= RFC822 + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / + set_flags / send) CRLF + + send ::= SEND SP message_format SP string + + Justification: This feature is provided so that mail can be + sent by the same reliable server that is used for the storage + of mail. This has, amongst others, the following benefits: + - Single process clients need not be delayed by mail + transmission. + - Mail sent by the client will have the server named as the + message's sender. This can be important because there are + a lot of mailers that erroneously cause reply mail to be + sent to the Sender, not the From or Reply-To address. Since + the client in general is not listening for mail being sent + to it directly this can cause mail to be lost. + + + +Rice [Page 43] + +RFC 1203 IMAP3 February 1991 + + + - Clients can be written that do not have any native message + sending capability. + + + ADD.MESSAGE - When this feature is enabled (default is disabled) + a new "ADD.MESSAGE" command becomes available to the client. + The ADD.MESSAGE command instructs the server to add the + specified message to the designated mailbox. This command + can be thought of as being like a COPY command except in + this case the message that is put in the designated mailbox + is specified as a string, rather than as a message number to + be copied from the currently selected mailbox. An example + use of this command might be as follows: + tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083} + From: James Rice <Rice@Sumex-Aim.Stanford.Edu> + To:..... + This will have the effect of adding the message to the mailbox + called OUTGOING-MAIL. + If the server is unable to parse the message being added then + it is required to issue a suitable NO notification to the client. + When the ADD.MESSAGE feature is enabled, the "add_message" + production in the grammar is added and as defined below. + The "add_message" request is added to the list of requests + in the request production also as shown below: + + add_message ::= ADD.MESSAGE SP mailbox SP format SP string + + message_format ::= RFC822 + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags / + add_message) CRLF + + Justification: This feature is provided so that clients can + easily add mail to specific mailboxes. This allows clients + to implement such behavior as outgoing mail storage (BCC) + without the need to resort to mailing to special BCC mailboxes. + + + RENUMBER - When this feature is enabled (default is disabled) + the RENUMBER command becomes available to the client. + The RENUMBER command will reorder the assignment of message + numbers to the messages in the mailbox. If this results in a + change to the association of any message number with any + message then the server is required to send solicited RESET + + + +Rice [Page 44] + +RFC 1203 IMAP3 February 1991 + + + responses to the client. The intent of this command is + to allow users to view mailboxes in user-meaningful order + efficiently. While the client could do the ordering, + it would be less efficient in general. Note that the + server may or may not change the actual storage of the + messages and the ordering may or may not remain in effect + after another mailbox is selected or the IMAP session is + terminated. Informally, the syntax for the RENUMBER + command is: + + tag RENUMBER field_name ordering_type + + this has the effect of changing the IMAP grammar to be + as follows: + + ordering_type ::= DATE / NUMERIC / ALPHA + + renumber ::= RENUMBER SP field_name SP ordering_type + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags / + renumber) CRLF + + For example: + tag42 RENUMBER FROM ALPHA + ;;;RENUMBER alphabetically by the from field + tag42 RESET 10:20,49 + ;;;Messages 10 to 20 and 49 have changed + tag42 OK RENUMBER finished. Sequence has changed + tag43 FETCH ALL 10:20,49 + ;;;Client chooses to fetch the changed msgs. + + To support this the RESET message is defined as follows: + + */tag RESET message_sequence + This solicited of unsolicited message from the server informs the + client that it should flush any information that it has + retained for the specified messages. + + Justification: This feature is provided so that clients can + view mailboxes in an order that is convenient to the user. + This is particularly important in the context of mailboxes + that the user copies messages to from other mailboxes. This + user-controlled filing process often does not happen in any + well-defined order. Because messages in a mailbox are + + + +Rice [Page 45] + +RFC 1203 IMAP3 February 1991 + + + implicitly ordered (usually by arrival date, though this is + not a required ordering predicate), the user can be confused + by the apparent order of messages in the mailbox. The + addition of the RENUMBER command makes it unnecessary + for the user to leave IMAP and use some other mail system to + sort mailboxes. + + + ENCODING - When this feature is enabled (default is disabled) a new + generic key named ENCODING is defined. The value associated + with the generic ENCODING key is a list of (tag encoding-type + options...) lists that represent the ordered, possibly encoded + body of the message. Each such list represents a segment of + the body of the message and the way in which it is encoded. + Any options that follow the encoding_type are further + qualifiers that describe the format of the segment. Each tag + is created by the server and is unique with respect to the + other tags allocated for the other elements in the ENCODING + list. The client may use the tags returned by the server as + concrete keys to access a field which is encoded using the + encoding type and options mentioned in the appropriate list. + Thus: + + tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196. + tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded. + tag41 OK Fetch completed. + tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197. + tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies. + tag42 OK Fetch completed. + tag43 FETCH 197 G002 ; Client asks for field named G002 + tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field. + tag43 OK Fetch completed. + + or + + tag44 STORE 197 G002 "0A 00 FF 31 24......." + ; Store back the segment with nibbles swapped + + Note: As a side-effect of enabling this feature, the generic key + TEXT will be redefined so as to return only those body parts of a + message that are of type TEXT. The concrete key RFC822.TEXT, on + the other hand, would still return everything in the body of the + message, even if it was full of strange, binary character + sequences. + + When the client STOREs to a field denoted by one of the above tags + the server will interpret the value being passed as being in the + same format as is currently specified in the ENCODING field. The + + + +Rice [Page 46] + +RFC 1203 IMAP3 February 1991 + + + server is not required to be able to reformat the data associated + with the ENCODING tags if the client STOREs a new value for the + ENCODING field. The interpretability of a message in the context + of its ENCODING field is undefined if the client side-effects that + ENCODING field, unless the client also STOREs new, reformatted + values for the fields that have had their encoding changed. + + If the client stores a new value for the ENCODING field then the + tags in the new value will be used to index the parts of the body. + All tags in a client-STOREd ENCODING that are the same as those + originally generated by the server in response to a FETCH ENCODING + command are said still to denote the fields that they originally + denoted, though possibly reordered. Any tags not originally + defined by the server will denote new message parts, in the + appropriate format, in the relative position specified. The + exclusion of any tags that the server originally defined in a + FETCH of the ENCODING field will indicate the deletion of that + part of the message. Newly created message parts are undefined by + default, so if the client fails to follow the STOREing of the + ENCODING field with suitable STORE commands for the values + associated with any newly created tags, these fields will contain + the null value NIL. + + Justification: This feature is supplied so as to allow support + for emergent multi-part and multi-media mail standards. + + INDEXABLE.FIELDS - When this feature is enabled (default is + disabled) the grammar of fetch commands is changed to allow the + client to select a specific subsequence from the field in + question. For example: + + tag42 FETCH 197 BODY 2000:3999 + + would fetch the second two thousand bytes of the body of message + 197. This feature allows resource limited clients to access + small parts of large messages. The formal syntax for this is: + + fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + fetch_key / (fetch_key SP NUMBER ":" NUMBER) + + fetch_key ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / + "RFC822.TEXT" / key + + If the lower bound number (the number to the left of the colon) + exceeds the maximum size of the field then the empty string is + returned. If the upper bound exceeds the maximum size of the + field but the lower bound does not then the server will return the + remaining substring of the field after the lower bound. The + + + +Rice [Page 47] + +RFC 1203 IMAP3 February 1991 + + + bounds specified are zero indexed into the fields and the bounds + index fields by 8-bit bytes. + + Justification: This feature is provided so as to allow resource- + limited clients to read very large messages and also to allow + clients to improve interactive response for the reading of large + messages by fetching the first "screen full" of data to display + immediately and fetching the rest of the message in the + background. + + SET.EOL - When enabled (default is disabled), this feature + allows the new command SET.EOL to be available, changing the + grammar as follows: + + character ::= "CR" / "LF" / number + + request ::= tag SP (noop / login / logout / select / check / + expunge / copy / fetch / store / search / + select_version / select_features / + supported_versions / bboard / find / + read_only / read_write / flags / set_flags / + set_eol) CRLF + + set_eol ::= "SET.EOL" 1#character + + This has the effect of changing the end of line character sequence + generated by the server for newlines within strings to the + sequence of characters specified. The characters in the sequence + can be either the specified symbolically named characters or a + numerical value, specifying the decimal value of the character to + use. Thus, if the client would like newlines in strings to be + indicated by a carriage return followed by a control-d, the client + would issue the following command: + + tag42 SET.EOL CR 4 + + If the server is unable to support the combination of characters + requested by the client as its end-of-line pattern it will reply + with a NO response. This might be the case, for example, if a + server is only able to generate its own native line feed pattern + and the CRLF required by IMAP by default. + + The server is required to change any length denoting values, such + as envelope byte counts for all future transactions to reflect the + new eol setting. This change in reported sizes should apply to + all generic size fetching keys, but not to concrete ones such as + RFC822.SIZE, which by their very nature require a size measurement + in RFC822 format, i.e., with CRLF as the end-of-line convention. + + + +Rice [Page 48] + +RFC 1203 IMAP3 February 1991 + + + Justification: This feature is provided because frequently clients + and servers might have end-of-line conventions other than the CRLF + specified by RFC822. It is undesirable that the IMAP be linked + too closely to RFC822 and selecting a different convention might + allow substantial performance improvements in both clients and + servers by saving either client, server or both from having to + shuffle text around so as to add or remove non-local end-of-line + sequences. + +Acknowledgements: + + This text is based on RFC 1064 by Mark Crispin. + + The following have made major contributions to this proposed update + to the IMAP2 protocol: + + James Rice <Rice@sumex-aim.stanford.edu> + Richard Acuff <acuff@sumex-aim.stanford.edu> + Bill Yeager <yeager@sumex-aim.stanford.edu> + Christopher Lane <lane@sumex-aim.stanford.edu> + Bjorn Victor <Bjorn.Victor@docs.uu.se> + + Additional input was also received from: + + Andrew Sweer <sweer@sumex-aim.stanford.edu> + Tom Gruber <Gruber@sumex-aim.stanford.edu> + Kevin Brock <Brock@Sumex-Aim.Stanford.Edu> + Mark Crispin <MRC@cac.washington.edu> + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + James Rice + Stanford University + Knowledge Systems Laboratory + 701 Welch Road + Building C + Palo Alto, CA 94304 + + Phone: (415) 723-8405 + EMail: RICE@SUMEX-AIM.STANFORD.EDU + + + + + + + +Rice [Page 49] +
\ No newline at end of file diff --git a/RFC/rfc1225.txt b/RFC/rfc1225.txt new file mode 100644 index 00000000..8d7e0029 --- /dev/null +++ b/RFC/rfc1225.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group M. Rose +Request for Comments: 1225 Performance Systems International +Obsoletes: RFC 1081 May 1991 + + + Post Office Protocol - Version 3 + +Status of this Memo + + This memo suggests a simple method for workstations to dynamically + access mail from a mailbox server. This RFC specifies an IAB + standards track protocol for the Internet community, and requests + discussion and suggestions for improvements. Please refer to the + current edition of the "IAB Official Protocol Standards" for the + standardization state and status of this protocol. Distribution of + this memo is unlimited. + +Overview + + This memo is a republication of RFC 1081 which was based on RFC 918 + (since revised as RFC 937). Although similar in form to the original + Post Office Protocol (POP) proposed for the Internet community, the + protocol discussed in this memo is similar in spirit to the ideas + investigated by the MZnet project at the University of California, + Irvine. + + Further, substantial work was done on examining POP in a PC-based + environment. This work, which resulted in additional functionality + in this protocol, was performed by the ACIS Networking Systems Group + at Stanford University. The author gratefully acknowledges their + interest. + +Introduction + + On certain types of smaller nodes in the Internet it is often + impractical to maintain a message transport system (MTS). For + example, a workstation may not have sufficient resources (cycles, + disk space) in order to permit a SMTP server and associated local + mail delivery system to be kept resident and continuously running. + Similarly, it may be expensive (or impossible) to keep a personal + computer interconnected to an IP-style network for long amounts of + time (the node is lacking the resource known as "connectivity"). + + Despite this, it is often very useful to be able to manage mail on + these smaller nodes, and they often support a user agent (UA) to aid + the tasks of mail handling. To solve this problem, a node which can + support an MTS entity offers a maildrop service to these less endowed + nodes. The Post Office Protocol - Version 3 (POP3) is intended to + + + +Rose [Page 1] + +RFC 1225 POP3 May 1991 + + + permit a workstation to dynamically access a maildrop on a server + host in a useful fashion. Usually, this means that the POP3 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + For the remainder of this memo, the term "client host" refers to a + host making use of the POP3 service, while the term "server host" + refers to a host which offers the POP3 service. + +A Short Digression + + This memo does not specify how a client host enters mail into the + transport system, although a method consistent with the philosophy of + this memo is presented here: + + When the user agent on a client host wishes to enter a message + into the transport system, it establishes an SMTP connection to + its relay host (this relay host could be, but need not be, the + POP3 server host for the client host). + + If this method is followed, then the client host appears to the MTS + as a user agent, and should NOT be regarded as a "trusted" MTS entity + in any sense whatsoever. This concept, along with the role of the + POP3 as a part of a split-UA model is discussed later in this memo. + + Initially, the server host starts the POP3 service by listening on + TCP port 110. When a client host wishes to make use of the service, + it establishes a TCP connection with the server host. When the + connection is established, the POP3 server sends a greeting. The + client and POP3 server then exchange commands and responses + (respectively) until the connection is closed or aborted. + + Commands in the POP3 consist of a keyword possibly followed by an + argument. All commands are terminated by a CRLF pair. + + Responses in the POP3 consist of a success indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. There are currently two success + indicators: positive ("+OK") and negative ("-ERR"). + + Responses to certain commands are multi-line. In these cases, which + are clearly indicated below, after sending the first line of the + response and a CRLF, any additional lines are sent, each terminated + by a CRLF pair. When all lines of the response have been sent, a + final line is sent, consisting of a termination octet (decimal code + 046, ".") and a CRLF pair. If any line of the multi-line response + begins with the termination octet, the line is "byte-stuffed" by + pre-pending the termination octet to that line of the response. + + + +Rose [Page 2] + +RFC 1225 POP3 May 1991 + + + Hence a multi-line response is terminated with the five octets + "CRLF.CRLF". When examining a multi-line response, the client checks + to see if the line begins with the termination octet. If so and if + octets other than CRLF follow, the the first octet of the line (the + termination octet) is stripped away. If so and if CRLF immediately + follows the termination character, then the response from the POP + server is ended and the line containing ".CRLF" is not considered + part of the multi-line response. + + A POP3 session progresses through a number of states during its + lifetime. Once the TCP connection has been opened and the POP3 + server has sent the greeting, the session enters the AUTHORIZATION + state. In this state, the client must identify itself to the POP3 + server. Once the client has successfully done this, the server + acquires resources associated with the client's maildrop, and the + session enters the TRANSACTION state. In this state, the client + requests actions on the part of the POP3 server. When the client has + finished its transactions, the session enters the UPDATE state. In + this state, the POP3 server releases any resources acquired during + the TRANSACTION state and says goodbye. The TCP connection is then + closed. + +The AUTHORIZATION State + + Once the TCP connection has been opened by a POP3 client, the POP3 + server issues a one line greeting. This can be any string terminated + by CRLF. An example might be: + + S. +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + The POP3 session is now in the AUTHORIZATION state. The client must + now issue the USER command. If the POP3 server responds with a + positive success indicator ("+OK"), then the client may issue either + the PASS command to complete the authorization, or the QUIT command + to terminate the POP3 session. If the POP3 server responds with a + negative success indicator ("-ERR") to the USER command, then the + client may either issue a new USER command or may issue the QUIT + command. + + When the client issues the PASS command, the POP3 server uses the + argument pair from the USER and PASS commands to determine if the + client should be given access to the appropriate maildrop. If so, + the POP3 server then acquires an exclusive-access lock on the + maildrop. If the lock is successfully acquired, the POP3 server + parses the maildrop into individual messages (read note below), + + + +Rose [Page 3] + +RFC 1225 POP3 May 1991 + + + determines the last message (if any) present in the maildrop that was + referenced by the RETR command, and responds with a positive success + indicator. The POP3 session now enters the TRANSACTION state. If + the lock can not be acquired or the client should is denied access to + the appropriate maildrop or the maildrop can't be parsed for some + reason, the POP3 server responds with a negative success indicator. + (If a lock was acquired but the POP3 server intends to respond with a + negative success indicator, the POP3 server must release the lock + prior to rejecting the command.) At this point, the client may + either issue a new USER command and start again, or the client may + issue the QUIT command. + + NOTE: Minimal implementations of the POP3 need only be + able to break a maildrop into its component messages; + they need NOT be able to parse individual messages. + More advanced implementations may wish to have this + capability, for reasons discussed later. + + After the POP3 server has parsed the maildrop into individual + messages, it assigns a message-id to each message, and notes the size + of the message in octets. The first message in the maildrop is + assigned a message-id of "1", the second is assigned "2", and so on, + so that the n'th message in a maildrop is assigned a message-id of + "n". In POP3 commands and responses, all message-id's and message + sizes are expressed in base-10 (i.e., decimal). + + It sets the "highest number accessed" to be that of the last message + referenced by the RETR command. + + Here are summaries for the three POP3 commands discussed thus far: + + USER name + Arguments: a server specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting or after an + unsuccessful USER or PASS command + Possible Responses: + +OK name is welcome here + -ERR never heard of name + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + ... + C: USER frated + S: -ERR sorry, frated doesn't get his mail here + + PASS string + Arguments: a server/user-id specific password (required) + + + +Rose [Page 4] + +RFC 1225 POP3 May 1991 + + + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command + Possible Responses: + +OK maildrop locked and ready + -ERR invalid password + -ERR unable to lock maildrop + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages + (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR unable to lock mrose's maildrop, file + already locked + + QUIT + Arguments: none + Restrictions: none + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + + +The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and burst the appropriate maildrop, + the POP3 session is now in the TRANSACTION state. The client may now + issue any of the following POP3 commands repeatedly. After each + command, the POP3 server issues a response. Eventually, the client + issues the QUIT command and the POP3 session enters the UPDATE state. + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + Arguments: none + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing information for the maildrop. This line is + called a "drop listing" for that maildrop. + + + +Rose [Page 5] + +RFC 1225 POP3 May 1991 + + + In order to simplify parsing, all POP3 servers are + required to use a certain format for drop listings. + The first octets present must indicate the number of + messages in the maildrop. Following this is the size + of the maildrop in octets. This memo makes no + requirement on what follows the maildrop size. + Minimal implementations should just end that line of + the response with a CRLF pair. More advanced + implementations may include other information. + + NOTE: This memo STRONGLY discourages + implementations from supplying additional + information in the drop listing. Other, + optional, facilities are discussed later on + which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not counted in + either total. + + Possible Responses: + +OK nn mm + Examples: + C: STAT + S: +OK 2 320 + + LIST [msg] + Arguments: a message-id (optionally) If a message-id is + given, it may NOT refer to a message marked as + deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If an argument was given and the POP3 server issues a + positive response with a line containing information + for that message. This line is called a "scan listing" + for that message. + + If no argument was given and the POP3 server issues a + positive response, then the response given is + multi-line. After the initial +OK, for each message + in the maildrop, the POP3 server responds with a line + containing information for that message. This line + is called a "scan listing" for that message. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. + The first octets present must be the message-id of + + + +Rose [Page 6] + +RFC 1225 POP3 May 1991 + + + the message. Following the message-id is the size of + the message in octets. This memo makes no requirement + on what follows the message size in the scan listing. + Minimal implementations should just end that line of + the response with a CRLF pair. More advanced + implementations may include other information, as + parsed from the message. + + NOTE: This memo STRONGLY discourages + implementations from supplying additional + information in the scan listing. Other, optional, + facilities are discussed later on which permit + the client to parse the messages in the maildrop. + + Note that messages marked as deleted are not listed. + + Possible Responses: + +OK scan listing follows + -ERR no such message + Examples: + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + ... + C: LIST 2 + S: +OK 2 200 + ... + C: LIST 3 + S: -ERR no such message, only 2 messages in + maildrop + + RETR msg + Arguments: a message-id (required) This message-id may + NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, + the POP3 server sends the message corresponding to the + given message-id, being careful to byte-stuff the + termination character (as with all multi-line + responses). + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, the + + + +Rose [Page 7] + +RFC 1225 POP3 May 1991 + + + POP3 server updates the "highest number accessed" to + the number associated with this message. + + Possible Responses: + +OK message follows + -ERR no such message + Examples: + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends the entire message here> + S: . + + DELE msg + Arguments: a message-id (required) This message-id + may NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server marks the message as deleted. Any + future reference to the message-id associated with the + message in a POP3 command generates an error. The POP3 + server does not actually delete the message until the + POP3 session enters the UPDATE state. + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, + the POP3 server updates the "highest number accessed" + to the number associated with this message. + + Possible Responses: + +OK message deleted + -ERR no such message + Examples: + C: DELE 1 + S: +OK message 1 deleted + ... + C: DELE 2 + S: -ERR message 2 already deleted + + NOOP + Arguments: none + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server does nothing, it merely replies with a + positive response. + + Possible Responses: + + + +Rose [Page 8] + +RFC 1225 POP3 May 1991 + + + +OK + Examples: + C: NOOP + S: +OK + + LAST + Arguments: none + Restrictions: may only be issued in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing the highest message number which accessed. + Zero is returned in case no message in the maildrop has + been accessed during previous transactions. A client + may thereafter infer that messages, if any, numbered + greater than the response to the LAST command are + messages not yet accessed by the client. + + Possible Response: + +OK nn + + Examples: + C: STAT + S: +OK 4 320 + C: LAST + S: +OK 1 + C: RETR 3 + S: +OK 120 octets + S: <the POP3 server sends the entire message + here> + S: . + C: LAST + S: +OK 3 + C: DELE 2 + S: +OK message 2 deleted + C: LAST + S: +OK 3 + C: RSET + S: +OK + C: LAST + S: +OK 1 + + RSET + Arguments: none + Restrictions: may only be given in the TRANSACTION + state. + Discussion: + + + + +Rose [Page 9] + +RFC 1225 POP3 May 1991 + + + If any messages have been marked as deleted by the POP3 + server, they are unmarked. The POP3 server then + replies with a positive response. In addition, the + "highest number accessed" is also reset to the value + determined at the beginning of the POP3 session. + + Possible Responses: + +OK + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + + + +The UPDATE State + + When the client issues the QUIT command from the TRANSACTION state, + the POP3 session enters the UPDATE state. (Note that if the client + issues the QUIT command from the AUTHORIZATION state, the POP3 + session terminates but does NOT enter the UPDATE state.) + + QUIT + Arguments: none + Restrictions: none + Discussion: + + The POP3 server removes all messages marked as deleted + from the maildrop. It then releases the + exclusive-access lock on the maildrop and replies as + to the success of + these operations. The TCP connection is then closed. + + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop + empty) + ... + C: QUIT + S: +OK dewey POP3 server signing off (2 messages + left) + ... + + +Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + + + +Rose [Page 10] + +RFC 1225 POP3 May 1991 + + + implementations of POP3 servers. + + The optional POP3 commands described below permit a POP3 client + greater freedom in message handling, while preserving a simple POP3 + server implementation. + + NOTE: This memo STRONGLY encourages implementations to + support these commands in lieu of developing augmented + drop and scan listings. In short, the philosophy of + this memo is to put intelligence in the part of the + POP3 client and not the POP3 server. + + TOP msg n + Arguments: a message-id (required) and a number. This + message-id may NOT refer to a message marked as + deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If the POP3 server issues a positive response, then + the response given is multi-line. After the initial + +OK, the POP3 server sends the headers of the message, + the blank line separating the headers from the body, + and then the number of lines indicated message's body, + being careful to byte-stuff the termination character + (as with all multi-line responses). + + Note that if the number of lines requested by the POP3 + client is greater than than the number of lines in the + body, then the POP3 server sends the entire message. + + Possible Responses: + +OK top of message follows + -ERR no such message + Examples: + C: TOP 10 + S: +OK + S: <the POP3 server sends the headers of the + message, a blank line, and the first 10 lines + of the body of the message> + S: . + ... + C: TOP 100 + S: -ERR no such message + + RPOP user + Arguments: a client specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + + + +Rose [Page 11] + +RFC 1225 POP3 May 1991 + + + state after a successful USER command; in addition, + may only be given if the client used a reserved + (privileged) TCP port to connect to the server. + Discussion: + + The RPOP command may be used instead of the PASS + command to authenticate access to the maildrop. In + order for this command to be successful, the POP3 + client must use a reserved TCP port (port < 1024) to + connect tothe server. The POP3 server uses the + argument pair from the USER and RPOP commands to + determine if the client should be given access to + the appropriate maildrop. Unlike the PASS command + however, the POP3 server considers if the remote user + specified by the RPOP command who resides on the POP3 + client host is allowed to access the maildrop for the + user specified by the USER command (e.g., on Berkeley + UNIX, the .rhosts mechanism is used). With the + exception of this differing in authentication, this + command is identical to the PASS command. + + Note that the use of this feature has allowed much wider + penetration into numerous hosts on local networks (and + sometimes remote networks) by those who gain illegal + access to computers by guessing passwords or otherwise + breaking into the system. + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: RPOP mrose + S: +OK mrose's maildrop has 2 messages (320 + octets) + + Minimal POP3 Commands: + USER name valid in the AUTHORIZATION state + PASS string + QUIT + + STAT valid in the TRANSACTION state + LIST [msg] + RETR msg + DELE msg + NOOP + LAST + + + +Rose [Page 12] + +RFC 1225 POP3 May 1991 + + + RSET + + QUIT valid in the UPDATE state + + Optional POP3 Commands: + RPOP user valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + + POP3 Replies: + +OK + -ERR + + Note that with the exception of the STAT command, the reply given + by the POP3 server to any command is significant only to "+OK" + and "-ERR". Any text occurring after this reply may be ignored + by the client. + +Example POP3 Session + + S: <wait for connection on TCP port 110> + ... + C: <open connection> + S: +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages (320 octets) + C: STAT + S: +OK 2 320 + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends message 1> + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: <the POP3 server sends message 2> + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + + + +Rose [Page 13] + +RFC 1225 POP3 May 1991 + + + S: +OK dewey POP3 server signing off (maildrop empty) + C: <close connection> + S: <wait for next connection> + +Message Format + + All messages transmitted during a POP3 session are assumed to conform + to the standard for the format of Internet text messages [RFC822]. + + It is important to note that the byte count for a message on the + server host may differ from the octet count assigned to that message + due to local conventions for designating end-of-line. Usually, + during the AUTHORIZATION state of the POP3 session, the POP3 client + can calculate the size of each message in octets when it parses the + maildrop into messages. For example, if the POP3 server host + internally represents end-of-line as a single character, then the + POP3 server simply counts each occurrence of this character in a + message as two octets. Note that lines in the message which start + with the termination octet need not be counted twice, since the POP3 + client will remove all byte-stuffed termination characters when it + receives a multi-line response. + +The POP and the Split-UA model + + The underlying paradigm in which the POP3 functions is that of a + split-UA model. The POP3 client host, being a remote PC based + workstation, acts solely as a client to the message transport system. + It does not provide delivery/authentication services to others. + Hence, it is acting as a UA, on behalf of the person using the + workstation. Furthermore, the workstation uses SMTP to enter mail + into the MTS. + + In this sense, we have two UA functions which interface to the + message transport system: Posting (SMTP) and Retrieval (POP3). The + entity which supports this type of environment is called a split-UA + (since the user agent is split between two hosts which must + interoperate to provide these functions). + + ASIDE: Others might term this a remote-UA instead. + There are arguments supporting the use of both terms. + + This memo has explicitly referenced TCP as the underlying transport + agent for the POP3. This need not be the case. In the MZnet split- + UA, for example, personal micro-computer systems are used which do + not have IP-style networking capability. To connect to the POP3 + server host, a PC establishes a terminal connection using some simple + protocol (PhoneNet). A program on the PC drives the connection, + first establishing a login session as a normal user. The login shell + + + +Rose [Page 14] + +RFC 1225 POP3 May 1991 + + + for this pseudo-user is a program which drives the other half of the + terminal protocol and communicates with one of two servers. Although + MZnet can support several PCs, a single pseudo-user login is present + on the server host. The user-id and password for this pseudo-user + login is known to all members of MZnet. Hence, the first action of + the login shell, after starting the terminal protocol, is to demand a + USER/PASS authorization pair from the PC. This second level of + authorization is used to ascertain who is interacting with the MTS. + Although the server host is deemed to support a "trusted" MTS entity, + PCs in MZnet are not. Naturally, the USER/PASS authorization pair + for a PC is known only to the owner of the PC (in theory, at least). + + After successfully verifying the identity of the client, a modified + SMTP server is started, and the PC posts mail with the server host. + After the QUIT command is given to the SMTP server and it terminates, + a modified POP3 server is started, and the PC retrieves mail from the + server host. After the QUIT command is given to the POP3 server and + it terminates, the login shell for the pseudo-user terminates the + terminal protocol and logs the job out. The PC then closes the + terminal connection to the server host. + + The SMTP server used by MZnet is modified in the sense that it knows + that it's talking to a user agent and not a "trusted" entity in the + message transport system. Hence, it does performs the validation + activities normally performed by an entity in the MTS when it accepts + a message from a UA. + + The POP3 server used by MZnet is modified in the sense that it does + not require a USER/PASS combination before entering the TRANSACTION + state. The reason for this (of course) is that the PC has already + identified itself during the second-level authorization step + described above. + + NOTE: Truth in advertising laws require that the author + of this memo state that MZnet has not actually been + fully implemented. The concepts presented and proven + by the project led to the notion of the MZnet + split-slot model. This notion has inspired the + split-UA concept described in this memo, led to the + author's interest in the POP, and heavily influenced + the the description of the POP3 herein. + + In fact, some UAs present in the Internet already support the notion + of posting directly to an SMTP server and retrieving mail directly + from a POP server, even if the POP server and client resided on the + same host! + + ASIDE: this discussion raises an issue which this memo + + + +Rose [Page 15] + +RFC 1225 POP3 May 1991 + + + purposedly avoids: how does SMTP know that it's talking + to a "trusted" MTS entity? + +References + + [MZnet] Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail + Service for Personal Micro-Computer Systems", + Proceedings, IFIP 6.5 International Conference on + Computer Message Systems, Nottingham, U.K., May 1984. + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", + USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet + Text Messages", University of Delaware, August 1982. + + [RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. + Reynolds, "Post Office Protocol - Version 2", RFC 937, + USC/Information Sciences Institute, February 1985. + + [RFC1060] Reynolds, J., and J. Postel, "Assigned Numbers", RFC + 1060, USC/Information Sciences Institute, March 1990. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address: + + Marshall T. Rose + Performance Systems International + 5201 Great America Parkway + Suite 3106 + Santa Clara, CA 95054 + + Phone: +1 408 562 6222 + + EMail: mrose@psi.com + X.500: rose, psi, us + + + + + + + + + + + + +Rose [Page 16] +
\ No newline at end of file diff --git a/RFC/rfc1460.txt b/RFC/rfc1460.txt new file mode 100644 index 00000000..d6177599 --- /dev/null +++ b/RFC/rfc1460.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group M. Rose +Request for Comments: 1460 Dover Beach Consulting, Inc. +Obsoletes: 1225 June 1993 + + + Post Office Protocol - Version 3 + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Overview + + This memo is a revision to RFC 1225, a Draft Standard. It makes the + following changes from that document: + + - the RPOP facility is removed; + + - the optional APOP facility is added (which is in interoperable, + operational use in at least three implementations); + + - a typo was corrected with respect to the interaction of LAST + and RSET; + + - section numbers were added; and, + + - an acknowledgements section was added. + +1. Introduction + + On certain types of smaller nodes in the Internet it is often + impractical to maintain a message transport system (MTS). For + example, a workstation may not have sufficient resources (cycles, + disk space) in order to permit a SMTP server [RFC821] and associated + local mail delivery system to be kept resident and continuously + running. + + Similarly, it may be expensive (or impossible) to keep a personal + computer interconnected to an IP-style network for long amounts of + time (the node is lacking the resource known as "connectivity"). + + Despite this, it is often very useful to be able to manage mail on + these smaller nodes, and they often support a user agent (UA) to aid + + + +Rose [Page 1] + +RFC 1460 POP3 June 1993 + + + the tasks of mail handling. To solve this problem, a node which can + support an MTS entity offers a maildrop service to these less endowed + nodes. The Post Office Protocol - Version 3 (POP3) is intended to + permit a workstation to dynamically access a maildrop on a server + host in a useful fashion. Usually, this means that the POP3 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + For the remainder of this memo, the term "client host" refers to a + host making use of the POP3 service, while the term "server host" + refers to a host which offers the POP3 service. + +2. A Short Digression + + This memo does not specify how a client host enters mail into the + transport system, although a method consistent with the philosophy of + this memo is presented here: + + When the user agent on a client host wishes to enter a message + into the transport system, it establishes an SMTP connection to + its relay host (this relay host could be, but need not be, the + POP3 server host for the client host). + + If this method is followed, then the client host appears to the MTS + as a user agent, and should NOT be regarded as a "trusted" MTS entity + in any sense whatsoever. This concept, along with the role of the + POP3 as a part of a split-UA model is discussed later in this memo. + +3. Basic Operation + + Initially, the server host starts the POP3 service by listening on + TCP port 110. When a client host wishes to make use of the service, + it establishes a TCP connection with the server host. When the + connection is established, the POP3 server sends a greeting. The + client and POP3 server then exchange commands and responses + (respectively) until the connection is closed or aborted. + + Commands in the POP3 consist of a keyword possibly followed by an + argument. All commands are terminated by a CRLF pair. + + Responses in the POP3 consist of a success indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. There are currently two success + indicators: positive ("+OK") and negative ("-ERR"). + + Responses to certain commands are multi-line. In these cases, which + are clearly indicated below, after sending the first line of the + response and a CRLF, any additional lines are sent, each terminated + + + +Rose [Page 2] + +RFC 1460 POP3 June 1993 + + + by a CRLF pair. When all lines of the response have been sent, a + final line is sent, consisting of a termination octet (decimal code + 046, ".") and a CRLF pair. If any line of the multi-line response + begins with the termination octet, the line is "byte-stuffed" by + pre-pending the termination octet to that line of the response. + + Hence a multi-line response is terminated with the five octets + "CRLF.CRLF". When examining a multi-line response, the client checks + to see if the line begins with the termination octet. If so and if + octets other than CRLF follow, the the first octet of the line (the + termination octet) is stripped away. If so and if CRLF immediately + follows the termination character, then the response from the POP + server is ended and the line containing ".CRLF" is not considered + part of the multi-line response. + + A POP3 session progresses through a number of states during its + lifetime. Once the TCP connection has been opened and the POP3 + server has sent the greeting, the session enters the AUTHORIZATION + state. In this state, the client must identify itself to the POP3 + server. Once the client has successfully done this, the server + acquires resources associated with the client's maildrop, and the + session enters the TRANSACTION state. In this state, the client + requests actions on the part of the POP3 server. When the client has + finished its transactions, the session enters the UPDATE state. In + this state, the POP3 server releases any resources acquired during + the TRANSACTION state and says goodbye. The TCP connection is then + closed. + +4. The AUTHORIZATION State + + Once the TCP connection has been opened by a POP3 client, the POP3 + server issues a one line greeting. This can be any string terminated + by CRLF. An example might be: + + S. +OK POP3 server ready + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + The POP3 session is now in the AUTHORIZATION state. The client must + now issue the USER command. If the POP3 server responds with a + positive success indicator ("+OK"), then the client may issue either + the PASS command to complete the authorization, or the QUIT command + to terminate the POP3 session. If the POP3 server responds with a + negative success indicator ("-ERR") to the USER command, then the + client may either issue a new USER command or may issue the QUIT + command. + + + + +Rose [Page 3] + +RFC 1460 POP3 June 1993 + + + When the client issues the PASS command, the POP3 server uses the + argument pair from the USER and PASS commands to determine if the + client should be given access to the appropriate maildrop. If so, + the POP3 server then acquires an exclusive-access lock on the + maildrop. If the lock is successfully acquired, the POP3 server + parses the maildrop into individual messages (read note below), + determines the last message (if any) present in the maildrop that was + referenced by the RETR command, and responds with a positive success + indicator. The POP3 session now enters the TRANSACTION state. If + the lock can not be acquired or the client should is denied access to + the appropriate maildrop or the maildrop can't be parsed for some + reason, the POP3 server responds with a negative success indicator. + (If a lock was acquired but the POP3 server intends to respond with a + negative success indicator, the POP3 server must release the lock + prior to rejecting the command.) At this point, the client may + either issue a new USER command and start again, or the client may + issue the QUIT command. + + NOTE: Minimal implementations of the POP3 need only be + able to break a maildrop into its component messages; + they need NOT be able to parse individual messages. + More advanced implementations may wish to have this + capability, for reasons discussed later. + + After the POP3 server has parsed the maildrop into individual + messages, it assigns a message-id to each message, and notes the size + of the message in octets. The first message in the maildrop is + assigned a message-id of "1", the second is assigned "2", and so on, + so that the n'th message in a maildrop is assigned a message-id of + "n". In POP3 commands and responses, all message-id's and message + sizes are expressed in base-10 (i.e., decimal). + + It sets the "highest number accessed" to be that of the last message + referenced by the RETR command. + + Here are summaries for the three POP3 commands discussed thus far: + + USER name + Arguments: a server specific user-id (required) + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting or after an + unsuccessful USER or PASS command + Possible Responses: + +OK name is welcome here + -ERR never heard of name + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + + + +Rose [Page 4] + +RFC 1460 POP3 June 1993 + + + ... + C: USER frated + S: -ERR sorry, frated doesn't get his mail here + + PASS string + Arguments: a server/user-id specific password (required) + Restrictions: may only be given in the AUTHORIZATION + state after a successful USER command + Possible Responses: + +OK maildrop locked and ready + -ERR invalid password + -ERR unable to lock maildrop + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages + (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR unable to lock mrose's maildrop, file + already locked + + QUIT + Arguments: none + Restrictions: none + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + +5. The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and burst the appropriate maildrop, + the POP3 session is now in the TRANSACTION state. The client may now + issue any of the following POP3 commands repeatedly. After each + command, the POP3 server issues a response. Eventually, the client + issues the QUIT command and the POP3 session enters the UPDATE state. + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + Arguments: none + Restrictions: may only be given in the TRANSACTION state. + + + +Rose [Page 5] + +RFC 1460 POP3 June 1993 + + + Discussion: + + The POP3 server issues a positive response with a line + containing information for the maildrop. This line is + called a "drop listing" for that maildrop. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for drop listings. + The first octets present must indicate the number of + messages in the maildrop. Following this is the size + of the maildrop in octets. This memo makes no + requirement on what follows the maildrop size. + Minimal implementations should just end that line of + the response with a CRLF pair. More advanced + implementations may include other information. + + NOTE: This memo STRONGLY discourages + implementations from supplying additional + information in the drop listing. Other, + optional, facilities are discussed later on + which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not counted in + either total. + + Possible Responses: + +OK nn mm + Examples: + C: STAT + S: +OK 2 320 + + LIST [msg] + Arguments: a message-id (optionally) If a message-id is + given, it may NOT refer to a message marked as + deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If an argument was given and the POP3 server issues a + positive response with a line containing information + for that message. This line is called a "scan listing" + for that message. + + If no argument was given and the POP3 server issues a + positive response, then the response given is + multi-line. After the initial +OK, for each message + in the maildrop, the POP3 server responds with a line + + + +Rose [Page 6] + +RFC 1460 POP3 June 1993 + + + containing information for that message. This line + is called a "scan listing" for that message. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. + The first octets present must be the message-id of + the message. Following the message-id is the size of + the message in octets. This memo makes no requirement + on what follows the message size in the scan listing. + Minimal implementations should just end that line of + the response with a CRLF pair. More advanced + implementations may include other information, as + parsed from the message. + + NOTE: This memo STRONGLY discourages + implementations from supplying additional + information in the scan listing. Other, optional, + facilities are discussed later on which permit + the client to parse the messages in the maildrop. + + Note that messages marked as deleted are not listed. + + Possible Responses: + +OK scan listing follows + -ERR no such message + Examples: + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + ... + C: LIST 2 + S: +OK 2 200 + ... + C: LIST 3 + S: -ERR no such message, only 2 messages in + maildrop + + RETR msg + Arguments: a message-id (required) This message-id may + NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, + the POP3 server sends the message corresponding to the + + + +Rose [Page 7] + +RFC 1460 POP3 June 1993 + + + given message-id, being careful to byte-stuff the + termination character (as with all multi-line + responses). + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, the + POP3 server updates the "highest number accessed" to + the number associated with this message. + + Possible Responses: + +OK message follows + -ERR no such message + Examples: + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends the entire message here> + S: . + + DELE msg + Arguments: a message-id (required) This message-id + may NOT refer to a message marked as deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + The POP3 server marks the message as deleted. Any + future reference to the message-id associated with the + message in a POP3 command generates an error. The POP3 + server does not actually delete the message until the + POP3 session enters the UPDATE state. + + If the number associated with this message is higher + than the "highest number accessed" in the maildrop, + the POP3 server updates the "highest number accessed" + to the number associated with this message. + + Possible Responses: + +OK message deleted + -ERR no such message + Examples: + C: DELE 1 + S: +OK message 1 deleted + ... + C: DELE 2 + S: -ERR message 2 already deleted + + NOOP + Arguments: none + Restrictions: may only be given in the TRANSACTION state. + + + +Rose [Page 8] + +RFC 1460 POP3 June 1993 + + + Discussion: + + The POP3 server does nothing, it merely replies with a + positive response. + + Possible Responses: + +OK + Examples: + C: NOOP + S: +OK + + LAST + Arguments: none + Restrictions: may only be issued in the TRANSACTION state. + Discussion: + + The POP3 server issues a positive response with a line + containing the highest message number which accessed. + Zero is returned in case no message in the maildrop has + been accessed during previous transactions. A client + may thereafter infer that messages, if any, numbered + greater than the response to the LAST command are + messages not yet accessed by the client. + + Possible Response: + +OK nn + + Examples: + C: STAT + S: +OK 4 320 + C: LAST + S: +OK 1 + C: RETR 3 + S: +OK 120 octets + S: <the POP3 server sends the entire message + here> + S: . + C: LAST + S: +OK 3 + C: DELE 2 + S: +OK message 2 deleted + C: LAST + S: +OK 3 + C: RSET + S: +OK + C: LAST + S: +OK 0 + + + + +Rose [Page 9] + +RFC 1460 POP3 June 1993 + + + RSET + Arguments: none + Restrictions: may only be given in the TRANSACTION + state. + Discussion: + + If any messages have been marked as deleted by the POP3 + server, they are unmarked. The POP3 server then + replies with a positive response. In addition, the + "highest number accessed" is also reset to zero. + + Possible Responses: + +OK + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + +6. The UPDATE State + + When the client issues the QUIT command from the TRANSACTION state, + the POP3 session enters the UPDATE state. (Note that if the client + issues the QUIT command from the AUTHORIZATION state, the POP3 + session terminates but does NOT enter the UPDATE state.) + + QUIT + Arguments: none + Restrictions: none + Discussion: + + The POP3 server removes all messages marked as deleted + from the maildrop. It then releases the + exclusive-access lock on the maildrop and replies as + to the success of these operations. The TCP + connection is then closed. + + Possible Responses: + +OK + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop + empty) + ... + C: QUIT + S: +OK dewey POP3 server signing off (2 messages + left) + ... + + + + + +Rose [Page 10] + +RFC 1460 POP3 June 1993 + + +7. Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + implementations of POP3 servers. + + The optional POP3 commands described below permit a POP3 client + greater freedom in message handling, while preserving a simple POP3 + server implementation. + + NOTE: This memo STRONGLY encourages implementations to + support these commands in lieu of developing augmented + drop and scan listings. In short, the philosophy of + this memo is to put intelligence in the part of the + POP3 client and not the POP3 server. + + TOP msg n + Arguments: a message-id (required) and a number. This + message-id may NOT refer to a message marked as + deleted. + Restrictions: may only be given in the TRANSACTION state. + Discussion: + + If the POP3 server issues a positive response, then + the response given is multi-line. After the initial + +OK, the POP3 server sends the headers of the message, + the blank line separating the headers from the body, + and then the number of lines indicated message's body, + being careful to byte-stuff the termination character + (as with all multi-line responses). + + Note that if the number of lines requested by the POP3 + client is greater than than the number of lines in the + body, then the POP3 server sends the entire message. + + Possible Responses: + +OK top of message follows + -ERR no such message + Examples: + C: TOP 10 + S: +OK + S: <the POP3 server sends the headers of the + message, a blank line, and the first 10 lines + of the body of the message> + S: . + ... + C: TOP 100 + S: -ERR no such message + + + + +Rose [Page 11] + +RFC 1460 POP3 June 1993 + + + APOP name digest + Arguments: a server specific user-id and a digest string + (both required). + Restrictions: may only be given in the AUTHORIZATION + state after the POP3 greeting + Discussion: + + Normally, each POP3 session starts with a USER/PASS + exchange. This results in a server/user-id specific + password being sent in the clear on the network. For + intermittent use of POP3, this may not introduce a + sizable risk. However, many POP3 client + implementations connect to the POP3 server on a + regular basis -- to check for new mail. Further the + interval of session initiation may be on the order of + five minutes. Hence, the risk of password capture is + greatly enhanced. + + An alternate method of authentication is required + which provides for both origin authentication and + replay protection, but which does not involve sending + a password in the clear over the network. The APOP + command provides this functionality. + + A POP3 server which implements the APOP command will + include a timestamp in its banner greeting. The + syntax of the timestamp corresponds to the "msg-id" + in [RFC822], and MUST be different each time the POP3 + server issues a banner greeting. For example, on a + UNIX implementation in which a separate UNIX process + is used for each instance of a POP3 server, the + syntax of the timestamp might be: + + <process-ID.clock@hostname> + + where "process-ID" is the decimal value of the + process's PID, clock is the decimal value of the + system clock, and hostname is the fully-qualified + domain-name corresponding to the host where the POP3 + server is running. + + The POP3 client makes note of this timestamp, and + then issues the APOP command. The "name" parameter + has identical semantics to the "name" parameter of + the USER command. The "digest" parameter is + calculated by applying the MD5 algorithm [RFC1321] to + a string consisting of the timestamp (including + angle-brackets) followed by a shared secret. This + + + +Rose [Page 12] + +RFC 1460 POP3 June 1993 + + + shared secret is a string known only to the POP3 + client and server. Great care should be taken to + prevent unauthorized disclosure of the secret, as + knowledge of the secret will allow any entity to + successfully masquerade as the named user. The + "digest" parameter itself is a 16-octet value which + is sent in hexadecimal format, using lower-case ASCII + characters. + + When the POP3 server receives the APOP command, it + verifies the digest provided. If the digest is + correct, the POP3 server issues a positive response, + and the POP3 session enters the TRANSACTION state. + Otherwise, a negative response is issued and the POP3 + session remains in the AUTHORIZATION state. + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + Examples: + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK maildrop has 1 message (369 octets) + + In this example, the shared secret is the string "tanstaaf". + Hence, the MD5 algorithm is applied to the string + + <1896.697170952@dbc.mtview.ca.us>tanstaaf + + which produces a digest value of + + c4c9334bac560ecc979e58001b3e22fb + +8. POP3 Command Summary + + Minimal POP3 Commands: + USER name valid in the AUTHORIZATION state + PASS string + QUIT + + STAT valid in the TRANSACTION state + LIST [msg] + RETR msg + DELE msg + NOOP + LAST + RSET + + + + +Rose [Page 13] + +RFC 1460 POP3 June 1993 + + + QUIT valid in the UPDATE state + + Optional POP3 Commands: + APOP name digest valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + + POP3 Replies: + +OK + -ERR + + Note that with the exception of the STAT command, the reply given + by the POP3 server to any command is significant only to "+OK" + and "-ERR". Any text occurring after this reply may be ignored + by the client. + +9. Example POP3 Session + + S: <wait for connection on TCP port 110> + ... + C: <open connection> + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK mrose's maildrop has 2 messages (320 octets) + C: STAT + S: +OK 2 320 + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends message 1> + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: <the POP3 server sends message 2> + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: <close connection> + S: <wait for next connection> + + + + +Rose [Page 14] + +RFC 1460 POP3 June 1993 + + +10. Message Format + + All messages transmitted during a POP3 session are assumed to conform + to the standard for the format of Internet text messages [RFC822]. + + It is important to note that the byte count for a message on the + server host may differ from the octet count assigned to that message + due to local conventions for designating end-of-line. Usually, + during the AUTHORIZATION state of the POP3 session, the POP3 client + can calculate the size of each message in octets when it parses the + maildrop into messages. For example, if the POP3 server host + internally represents end-of-line as a single character, then the + POP3 server simply counts each occurrence of this character in a + message as two octets. Note that lines in the message which start + with the termination octet need not be counted twice, since the POP3 + client will remove all byte-stuffed termination characters when it + receives a multi-line response. + +11. The POP and the Split-UA model + + The underlying paradigm in which the POP3 functions is that of a + split-UA model. The POP3 client host, being a remote PC based + workstation, acts solely as a client to the message transport system. + It does not provide delivery/authentication services to others. + Hence, it is acting as a UA, on behalf of the person using the + workstation. Furthermore, the workstation uses SMTP to enter mail + into the MTS. + + In this sense, we have two UA functions which interface to the + message transport system: Posting (SMTP) and Retrieval (POP3). The + entity which supports this type of environment is called a split-UA + (since the user agent is split between two hosts which must + interoperate to provide these functions). + + ASIDE: Others might term this a remote-UA instead. + There are arguments supporting the use of both terms. + + This memo has explicitly referenced TCP as the underlying transport + agent for the POP3. This need not be the case. In the MZnet split- + UA, for example, personal micro-computer systems are used which do + not have IP-style networking capability [MZnet]. To connect to the + POP3 server host, a PC establishes a terminal connection using some + simple protocol (PhoneNet). A program on the PC drives the + connection, first establishing a login session as a normal user. The + login shell for this pseudo-user is a program which drives the other + half of the terminal protocol and communicates with one of two + servers. Although MZnet can support several PCs, a single pseudo- + user login is present on the server host. The user-id and password + + + +Rose [Page 15] + +RFC 1460 POP3 June 1993 + + + for this pseudo-user login is known to all members of MZnet. Hence, + the first action of the login shell, after starting the terminal + protocol, is to demand a USER/PASS authorization pair from the PC. + This second level of authorization is used to ascertain who is + interacting with the MTS. Although the server host is deemed to + support a "trusted" MTS entity, PCs in MZnet are not. Naturally, the + USER/PASS authorization pair for a PC is known only to the owner of + the PC (in theory, at least). + + After successfully verifying the identity of the client, a modified + SMTP server is started, and the PC posts mail with the server host. + After the QUIT command is given to the SMTP server and it terminates, + a modified POP3 server is started, and the PC retrieves mail from the + server host. After the QUIT command is given to the POP3 server and + it terminates, the login shell for the pseudo-user terminates the + terminal protocol and logs the job out. The PC then closes the + terminal connection to the server host. + + The SMTP server used by MZnet is modified in the sense that it knows + that it's talking to a user agent and not a "trusted" entity in the + message transport system. Hence, it does performs the validation + activities normally performed by an entity in the MTS when it accepts + a message from a UA. + + The POP3 server used by MZnet is modified in the sense that it does + not require a USER/PASS combination before entering the TRANSACTION + state. The reason for this (of course) is that the PC has already + identified itself during the second-level authorization step + described above. + + NOTE: Truth in advertising laws require that the author + of this memo state that MZnet has not actually been + fully implemented. The concepts presented and proven + by the project led to the notion of the MZnet + split-slot model. This notion has inspired the + split-UA concept described in this memo, led to the + author's interest in the POP, and heavily influenced + the the description of the POP3 herein. + + In fact, some UAs present in the Internet already support the notion + of posting directly to an SMTP server and retrieving mail directly + from a POP3 server, even if the POP3 server and client resided on the + same host! + + ASIDE: this discussion raises an issue which this memo + purposedly avoids: how does SMTP know that it's talking + to a "trusted" MTS entity? + + + + +Rose [Page 16] + +RFC 1460 POP3 June 1993 + + +12. References + + [MZnet] Stefferud, E., Sweet, J., and T. Domae, "MZnet: Mail + Service for Personal Micro-Computer Systems,: + Proceedings, IFIP 6.5 International Conference on + Computer Message Systems, Nottingham, U.K., May 1984. + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, + RFC 821, USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet + Text Messages", STD 11, RFC 822, University of Delaware, + August 1982. + + [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT + Laboratory for Computer Science, April 1992. + +13. Security Considerations + + It is conjectured that use of the APOP command provides origin + identification and replay protection for a POP3 session. + Accordingly, a POP3 server which implements both the PASS and APOP + commands must not allow both methods of access for a given user; that + is, for a given "USER name" either the PASS or APOP command is + allowed, but not both. + + Otherwise, security issues are not discussed in this memo. + +14. Acknowledgements + + The POP family has a long and checkered history. Although primarily + a minor revision to [RFC1225], POP3 is based on the ideas presented + in RFCs 918, 937, and 1081. + + In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff + provided significant comments on the APOP command. + +15. Author's Address + + Marshall T. Rose + Dover Beach Consulting, Inc. + Mountain View, CA 94043-2186 + + Phone: +1 415 968 1052 + Fax: +1 415 968 2510 + + EMail: mrose@dbc.mtview.ca.us + X.500: rose, dbc, us + + + +Rose [Page 17] +
\ No newline at end of file diff --git a/RFC/rfc1521.txt b/RFC/rfc1521.txt new file mode 100644 index 00000000..cb4ee75a --- /dev/null +++ b/RFC/rfc1521.txt @@ -0,0 +1,4539 @@ +
+
+
+
+
+
+Network Working Group N. Borenstein
+Request for Comments: 1521 Bellcore
+Obsoletes: 1341 N. Freed
+Category: Standards Track Innosoft
+ September 1993
+
+
+ MIME (Multipurpose Internet Mail Extensions) Part One:
+ Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies
+
+Status of this Memo
+
+ This RFC 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" for the standardization state and status
+ of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ STD 11, RFC 822 defines a message representation protocol which
+ specifies considerable detail about message headers, but which leaves
+ the message content, or message body, as flat ASCII text. This
+ document redefines the format of message bodies to allow multi-part
+ textual and non-textual message bodies to be represented and
+ exchanged without loss of information. This is based on earlier work
+ documented in RFC 934 and STD 11, RFC 1049, but extends and revises
+ that work. Because RFC 822 said so little about message bodies, this
+ document is largely orthogonal to (rather than a revision of) RFC
+ 822.
+
+ In particular, this document is designed to provide facilities to
+ include multiple objects in a single message, to represent body text
+ in character sets other than US-ASCII, to represent formatted multi-
+ font text messages, to represent non-textual material such as images
+ and audio fragments, and generally to facilitate later extensions
+ defining new types of Internet mail for use by cooperating mail
+ agents.
+
+ This document does NOT extend Internet mail header fields to permit
+ anything other than US-ASCII text data. Such extensions are the
+ subject of a companion document [RFC-1522].
+
+ This document is a revision of RFC 1341. Significant differences
+ from RFC 1341 are summarized in Appendix H.
+
+
+
+
+
+Borenstein & Freed [Page 1]
+
+RFC 1521 MIME September 1993
+
+
+Table of Contents
+
+ 1. Introduction....................................... 3
+ 2. Notations, Conventions, and Generic BNF Grammar.... 6
+ 3. The MIME-Version Header Field...................... 7
+ 4. The Content-Type Header Field...................... 9
+ 5. The Content-Transfer-Encoding Header Field......... 13
+ 5.1. Quoted-Printable Content-Transfer-Encoding......... 18
+ 5.2. Base64 Content-Transfer-Encoding................... 21
+ 6. Additional Content-Header Fields................... 23
+ 6.1. Optional Content-ID Header Field................... 23
+ 6.2. Optional Content-Description Header Field.......... 24
+ 7. The Predefined Content-Type Values................. 24
+ 7.1. The Text Content-Type.............................. 24
+ 7.1.1. The charset parameter.............................. 25
+ 7.1.2. The Text/plain subtype............................. 28
+ 7.2. The Multipart Content-Type......................... 28
+ 7.2.1. Multipart: The common syntax...................... 29
+ 7.2.2. The Multipart/mixed (primary) subtype.............. 34
+ 7.2.3. The Multipart/alternative subtype.................. 34
+ 7.2.4. The Multipart/digest subtype....................... 36
+ 7.2.5. The Multipart/parallel subtype..................... 37
+ 7.2.6. Other Multipart subtypes........................... 37
+ 7.3. The Message Content-Type........................... 38
+ 7.3.1. The Message/rfc822 (primary) subtype............... 38
+ 7.3.2. The Message/Partial subtype........................ 39
+ 7.3.3. The Message/External-Body subtype.................. 42
+ 7.3.3.1. The "ftp" and "tftp" access-types............... 44
+ 7.3.3.2. The "anon-ftp" access-type...................... 45
+ 7.3.3.3. The "local-file" and "afs" access-types......... 45
+ 7.3.3.4. The "mail-server" access-type................... 45
+ 7.3.3.5. Examples and Further Explanations............... 46
+ 7.4. The Application Content-Type....................... 49
+ 7.4.1. The Application/Octet-Stream (primary) subtype..... 50
+ 7.4.2. The Application/PostScript subtype................. 50
+ 7.4.3. Other Application subtypes......................... 53
+ 7.5. The Image Content-Type............................. 53
+ 7.6. The Audio Content-Type............................. 54
+ 7.7. The Video Content-Type............................. 54
+ 7.8. Experimental Content-Type Values................... 54
+ 8. Summary............................................ 56
+ 9. Security Considerations............................ 56
+ 10. Authors' Addresses................................. 57
+ 11. Acknowledgements................................... 58
+ Appendix A -- Minimal MIME-Conformance.................... 60
+ Appendix B -- General Guidelines For Sending Email Data... 63
+ Appendix C -- A Complex Multipart Example................. 66
+ Appendix D -- Collected Grammar........................... 68
+
+
+
+Borenstein & Freed [Page 2]
+
+RFC 1521 MIME September 1993
+
+
+ Appendix E -- IANA Registration Procedures................ 72
+ E.1 Registration of New Content-type/subtype Values...... 72
+ E.2 Registration of New Access-type Values
+ for Message/external-body............................ 73
+ Appendix F -- Summary of the Seven Content-types.......... 74
+ Appendix G -- Canonical Encoding Model.................... 76
+ Appendix H -- Changes from RFC 1341....................... 78
+ References................................................ 80
+
+1. Introduction
+
+ Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined
+ the standard format of textual mail messages on the Internet. Its
+ success has been such that the RFC 822 format has been adopted,
+ wholly or partially, well beyond the confines of the Internet and the
+ Internet SMTP transport defined by STD 10, RFC 821 [RFC-821]. As the
+ format has seen wider use, a number of limitations have proven
+ increasingly restrictive for the user community.
+
+ RFC 822 was intended to specify a format for text messages. As such,
+ non-text messages, such as multimedia messages that might include
+ audio or images, are simply not mentioned. Even in the case of text,
+ however, RFC 822 is inadequate for the needs of mail users whose
+ languages require the use of character sets richer than US ASCII
+ [US-ASCII]. Since RFC 822 does not specify mechanisms for mail
+ containing audio, video, Asian language text, or even text in most
+ European languages, additional specifications are needed.
+
+ One of the notable limitations of RFC 821/822 based mail systems is
+ the fact that they limit the contents of electronic mail messages to
+ relatively short lines of seven-bit ASCII. This forces users to
+ convert any non-textual data that they may wish to send into seven-
+ bit bytes representable as printable ASCII characters before invoking
+ a local mail UA (User Agent, a program with which human users send
+ and receive mail). Examples of such encodings currently used in the
+ Internet include pure hexadecimal, uuencode, the 3-in-4 base 64
+ scheme specified in RFC 1421, the Andrew Toolkit Representation
+ [ATK], and many others.
+
+ The limitations of RFC 822 mail become even more apparent as gateways
+ are designed to allow for the exchange of mail messages between RFC
+ 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
+ inclusion of non-textual body parts within electronic mail messages.
+ The current standards for the mapping of X.400 messages to RFC 822
+ messages specify either that X.400 non-textual body parts must be
+ converted to (not encoded in) an ASCII format, or that they must be
+ discarded, notifying the RFC 822 user that discarding has occurred.
+ This is clearly undesirable, as information that a user may wish to
+
+
+
+Borenstein & Freed [Page 3]
+
+RFC 1521 MIME September 1993
+
+
+ receive is lost. Even though a user's UA may not have the capability
+ of dealing with the non-textual body part, the user might have some
+ mechanism external to the UA that can extract useful information from
+ the body part. Moreover, it does not allow for the fact that the
+ message may eventually be gatewayed back into an X.400 message
+ handling system (i.e., the X.400 message is "tunneled" through
+ Internet mail), where the non-textual information would definitely
+ become useful again.
+
+ This document describes several mechanisms that combine to solve most
+ of these problems without introducing any serious incompatibilities
+ with the existing world of RFC 822 mail. In particular, it
+ describes:
+
+ 1. A MIME-Version header field, which uses a version number to
+ declare a message to be conformant with this specification and
+ allows mail processing agents to distinguish between such
+ messages and those generated by older or non-conformant software,
+ which is presumed to lack such a field.
+
+ 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],
+ which can be used to specify the type and subtype of data in the
+ body of a message and to fully specify the native representation
+ (encoding) of such data.
+
+ 2.a. A "text" Content-Type value, which can be used to represent
+ textual information in a number of character sets and
+ formatted text description languages in a standardized
+ manner.
+
+ 2.b. A "multipart" Content-Type value, which can be used to
+ combine several body parts, possibly of differing types of
+ data, into a single message.
+
+ 2.c. An "application" Content-Type value, which can be used to
+ transmit application data or binary data, and hence, among
+ other uses, to implement an electronic mail file transfer
+ service.
+
+ 2.d. A "message" Content-Type value, for encapsulating another
+ mail message.
+
+ 2.e An "image" Content-Type value, for transmitting still image
+ (picture) data.
+
+ 2.f. An "audio" Content-Type value, for transmitting audio or
+ voice data.
+
+
+
+
+Borenstein & Freed [Page 4]
+
+RFC 1521 MIME September 1993
+
+
+ 2.g. A "video" Content-Type value, for transmitting video or
+ moving image data, possibly with audio as part of the
+ composite video data format.
+
+ 3. A Content-Transfer-Encoding header field, which can be used to
+ specify an auxiliary encoding that was applied to the data in
+ order to allow it to pass through mail transport mechanisms which
+ may have data or character set limitations.
+
+ 4. Two additional header fields that can be used to further describe
+ the data in a message body, the Content-ID and Content-
+ Description header fields.
+
+ MIME has been carefully designed as an extensible mechanism, and it
+ is expected that the set of content-type/subtype pairs and their
+ associated parameters will grow significantly with time. Several
+ other MIME fields, notably including character set names, are likely
+ to have new values defined over time. In order to ensure that the
+ set of such values is developed in an orderly, well-specified, and
+ public manner, MIME defines a registration process which uses the
+ Internet Assigned Numbers Authority (IANA) as a central registry for
+ such values. Appendix E provides details about how IANA registration
+ is accomplished.
+
+ Finally, to specify and promote interoperability, Appendix A of this
+ document provides a basic applicability statement for a subset of the
+ above mechanisms that defines a minimal level of "conformance" with
+ this document.
+
+ HISTORICAL NOTE: Several of the mechanisms described in this
+ document may seem somewhat strange or even baroque at first
+ reading. It is important to note that compatibility with existing
+ standards AND robustness across existing practice were two of the
+ highest priorities of the working group that developed this
+ document. In particular, compatibility was always favored over
+ elegance.
+
+ MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]
+ [RFC-1342]. This document is a relatively minor updating of RFC
+ 1341, and is intended to supersede it. The differences between this
+ document and RFC 1341 are summarized in Appendix H. Please refer to
+ the current edition of the "IAB Official Protocol Standards" for the
+ standardization state and status of this protocol. Several other RFC
+ documents will be of interest to the MIME implementor, in particular
+ [RFC 1343], [RFC-1344], and [RFC-1345].
+
+
+
+
+
+
+Borenstein & Freed [Page 5]
+
+RFC 1521 MIME September 1993
+
+
+2. Notations, Conventions, and Generic BNF Grammar
+
+ This document is being published in two versions, one as plain ASCII
+ text and one as PostScript (PostScript is a trademark of Adobe
+ Systems Incorporated.). While the text version is the official
+ specification, some will find the PostScript version easier to read.
+ The textual contents are identical. An Andrew-format copy of this
+ document is also available from the first author (Borenstein).
+
+ Although the mechanisms specified in this document are all described
+ in prose, most are also described formally in the modified BNF
+ notation of RFC 822. Implementors will need to be familiar with this
+ notation in order to understand this specification, and are referred
+ to RFC 822 for a complete explanation of the modified BNF notation.
+
+ Some of the modified BNF in this document makes reference to
+ syntactic entities that are defined in RFC 822 and not in this
+ document. A complete formal grammar, then, is obtained by combining
+ the collected grammar appendix of this document with that of RFC 822
+ plus the modifications to RFC 822 defined in RFC 1123, which
+ specifically changes the syntax for `return', `date' and `mailbox'.
+
+ The term CRLF, in this document, refers to the sequence of the two
+ ASCII characters CR (13) and LF (10) which, taken together, in this
+ order, denote a line break in RFC 822 mail.
+
+ The term "character set" is used in this document to refer to a
+ method used with one or more tables to convert encoded text to a
+ series of octets. This definition is intended to allow various kinds
+ of text encodings, from simple single-table mappings such as ASCII to
+ complex table switching methods such as those that use ISO 2022's
+ techniques. However, a MIME character set name must fully specify
+ the mapping to be performed.
+
+ The term "message", when not further qualified, means either the
+ (complete or "top-level") message being transferred on a network, or
+ a message encapsulated in a body of type "message".
+
+ The term "body part", in this document, means one of the parts of the
+ body of a multipart entity. A body part has a header and a body, so
+ it makes sense to speak about the body of a body part.
+
+ The term "entity", in this document, means either a message or a body
+ part. All kinds of entities share the property that they have a
+ header and a body.
+
+ The term "body", when not further qualified, means the body of an
+ entity, that is the body of either a message or of a body part.
+
+
+
+Borenstein & Freed [Page 6]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE: The previous four definitions are clearly circular. This is
+ unavoidable, since the overall structure of a MIME message is
+ indeed recursive.
+
+ In this document, all numeric and octet values are given in decimal
+ notation.
+
+ It must be noted that Content-Type values, subtypes, and parameter
+ names as defined in this document are case-insensitive. However,
+ parameter values are case-sensitive unless otherwise specified for
+ the specific parameter.
+
+ FORMATTING NOTE: This document has been carefully formatted for
+ ease of reading. The PostScript version of this document, in
+ particular, places notes like this one, which may be skipped by
+ the reader, in a smaller, italicized, font, and indents it as
+ well. In the text version, only the indentation is preserved, so
+ if you are reading the text version of this you might consider
+ using the PostScript version instead. However, all such notes will
+ be indented and preceded by "NOTE:" or some similar introduction,
+ even in the text version.
+
+ The primary purpose of these non-essential notes is to convey
+ information about the rationale of this document, or to place this
+ document in the proper historical or evolutionary context. Such
+ information may be skipped by those who are focused entirely on
+ building a conformant implementation, but may be of use to those
+ who wish to understand why this document is written as it is.
+
+ For ease of recognition, all BNF definitions have been placed in a
+ fixed-width font in the PostScript version of this document.
+
+3. The MIME-Version Header Field
+
+ Since RFC 822 was published in 1982, there has really been only one
+ format standard for Internet messages, and there has been little
+ perceived need to declare the format standard in use. This document
+ is an independent document that complements RFC 822. Although the
+ extensions in this document have been defined in such a way as to be
+ compatible with RFC 822, there are still circumstances in which it
+ might be desirable for a mail-processing agent to know whether a
+ message was composed with the new standard in mind.
+
+ Therefore, this document defines a new header field, "MIME-Version",
+ which is to be used to declare the version of the Internet message
+ body format standard in use.
+
+ Messages composed in accordance with this document MUST include such
+
+
+
+Borenstein & Freed [Page 7]
+
+RFC 1521 MIME September 1993
+
+
+ a header field, with the following verbatim text:
+
+ MIME-Version: 1.0
+
+ The presence of this header field is an assertion that the message
+ has been composed in compliance with this document.
+
+ Since it is possible that a future document might extend the message
+ format standard again, a formal BNF is given for the content of the
+ MIME-Version field:
+
+ version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ Thus, future format specifiers, which might replace or extend "1.0",
+ are constrained to be two integer fields, separated by a period. If
+ a message is received with a MIME-version value other than "1.0", it
+ cannot be assumed to conform with this specification.
+
+ Note that the MIME-Version header field is required at the top level
+ of a message. It is not required for each body part of a multipart
+ entity. It is required for the embedded headers of a body of type
+ "message" if and only if the embedded message is itself claimed to be
+ MIME-conformant.
+
+ It is not possible to fully specify how a mail reader that conforms
+ with MIME as defined in this document should treat a message that
+ might arrive in the future with some value of MIME-Version other than
+ "1.0". However, conformant software is encouraged to check the
+ version number and at least warn the user if an unrecognized MIME-
+ version is encountered.
+
+ It is also worth noting that version control for specific content-
+ types is not accomplished using the MIME-Version mechanism. In
+ particular, some formats (such as application/postscript) have
+ version numbering conventions that are internal to the document
+ format. Where such conventions exist, MIME does nothing to supersede
+ them. Where no such conventions exist, a MIME type might use a
+ "version" parameter in the content-type field if necessary.
+
+ NOTE TO IMPLEMENTORS: All header fields defined in this document,
+ including MIME-Version, Content-type, etc., are subject to the
+ general syntactic rules for header fields specified in RFC 822. In
+ particular, all can include comments, which means that the following
+ two MIME-Version fields are equivalent:
+
+ MIME-Version: 1.0
+ MIME-Version: 1.0 (Generated by GBD-killer 3.7)
+
+
+
+
+Borenstein & Freed [Page 8]
+
+RFC 1521 MIME September 1993
+
+
+4. The Content-Type Header Field
+
+ The purpose of the Content-Type field is to describe the data
+ contained in the body fully enough that the receiving user agent can
+ pick an appropriate agent or mechanism to present the data to the
+ user, or otherwise deal with the data in an appropriate manner.
+
+ HISTORICAL NOTE: The Content-Type header field was first defined in
+ RFC 1049. RFC 1049 Content-types used a simpler and less powerful
+ syntax, but one that is largely compatible with the mechanism given
+ here.
+
+ The Content-Type header field is used to specify the nature of the
+ data in the body of an entity, by giving type and subtype
+ identifiers, and by providing auxiliary information that may be
+ required for certain types. After the type and subtype names, the
+ remainder of the header field is simply a set of parameters,
+ specified in an attribute/value notation. The set of meaningful
+ parameters differs for the different types. In particular, there are
+ NO globally-meaningful parameters that apply to all content-types.
+ Global mechanisms are best addressed, in the MIME model, by the
+ definition of additional Content-* header fields. The ordering of
+ parameters is not significant. Among the defined parameters is a
+ "charset" parameter by which the character set used in the body may
+ be declared. Comments are allowed in accordance with RFC 822 rules
+ for structured header fields.
+
+ In general, the top-level Content-Type is used to declare the general
+ type of data, while the subtype specifies a specific format for that
+ type of data. Thus, a Content-Type of "image/xyz" is enough to tell
+ a user agent that the data is an image, even if the user agent has no
+ knowledge of the specific image format "xyz". Such information can
+ be used, for example, to decide whether or not to show a user the raw
+ data from an unrecognized subtype -- such an action might be
+ reasonable for unrecognized subtypes of text, but not for
+ unrecognized subtypes of image or audio. For this reason, registered
+ subtypes of audio, image, text, and video, should not contain
+ embedded information that is really of a different type. Such
+ compound types should be represented using the "multipart" or
+ "application" types.
+
+ Parameters are modifiers of the content-subtype, and do not
+ fundamentally affect the requirements of the host system. Although
+ most parameters make sense only with certain content-types, others
+ are "global" in the sense that they might apply to any subtype. For
+ example, the "boundary" parameter makes sense only for the
+ "multipart" content-type, but the "charset" parameter might make
+ sense with several content-types.
+
+
+
+Borenstein & Freed [Page 9]
+
+RFC 1521 MIME September 1993
+
+
+ An initial set of seven Content-Types is defined by this document.
+ This set of top-level names is intended to be substantially complete.
+ It is expected that additions to the larger set of supported types
+ can generally be accomplished by the creation of new subtypes of
+ these initial types. In the future, more top-level types may be
+ defined only by an extension to this standard. If another primary
+ type is to be used for any reason, it must be given a name starting
+ with "X-" to indicate its non-standard status and to avoid a
+ potential conflict with a future official name.
+
+ In the Augmented BNF notation of RFC 822, a Content-Type header field
+ value is defined as follows:
+
+ content := "Content-Type" ":" type "/" subtype *(";"
+ parameter)
+ ; case-insensitive matching of type and subtype
+
+ type := "application" / "audio"
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / extension-token
+ ; All values case-insensitive
+
+ extension-token := x-token / iana-token
+
+ iana-token := <a publicly-defined extension token,
+ registered with IANA, as specified in
+ appendix E>
+
+ x-token := <The two characters "X-" or "x-" followed, with
+ no intervening white space, by any token>
+
+ subtype := token ; case-insensitive
+
+ parameter := attribute "=" value
+
+ attribute := token ; case-insensitive
+
+ value := token / quoted-string
+
+ token := 1*<any (ASCII) CHAR except SPACE, CTLs,
+ or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@"
+ / "," / ";" / ":" / "\" / <">
+ / "/" / "[" / "]" / "?" / "="
+ ; Must be in quoted-string,
+ ; to use within parameter values
+
+
+
+Borenstein & Freed [Page 10]
+
+RFC 1521 MIME September 1993
+
+
+ Note that the definition of "tspecials" is the same as the RFC 822
+ definition of "specials" with the addition of the three characters
+ "/", "?", and "=", and the removal of ".".
+
+ Note also that a subtype specification is MANDATORY. There are no
+ default subtypes.
+
+ The type, subtype, and parameter names are not case sensitive. For
+ example, TEXT, Text, and TeXt are all equivalent. Parameter values
+ are normally case sensitive, but certain parameters are interpreted
+ to be case-insensitive, depending on the intended use. (For example,
+ multipart boundaries are case-sensitive, but the "access-type" for
+ message/External-body is not case-sensitive.)
+
+ Beyond this syntax, the only constraint on the definition of subtype
+ names is the desire that their uses must not conflict. That is, it
+ would be undesirable to have two different communities using
+ "Content-Type: application/foobar" to mean two different things. The
+ process of defining new content-subtypes, then, is not intended to be
+ a mechanism for imposing restrictions, but simply a mechanism for
+ publicizing the usages. There are, therefore, two acceptable
+ mechanisms for defining new Content-Type subtypes:
+
+ 1. Private values (starting with "X-") may be
+ defined bilaterally between two cooperating
+ agents without outside registration or
+ standardization.
+
+ 2. New standard values must be documented,
+ registered with, and approved by IANA, as
+ described in Appendix E. Where intended for
+ public use, the formats they refer to must
+ also be defined by a published specification,
+ and possibly offered for standardization.
+
+ The seven standard initial predefined Content-Types are detailed in
+ the bulk of this document. They are:
+
+ text -- textual information. The primary subtype,
+ "plain", indicates plain (unformatted) text. No
+ special software is required to get the full
+ meaning of the text, aside from support for the
+ indicated character set. Subtypes are to be used
+ for enriched text in forms where application
+ software may enhance the appearance of the text,
+ but such software must not be required in order to
+ get the general idea of the content. Possible
+ subtypes thus include any readable word processor
+
+
+
+Borenstein & Freed [Page 11]
+
+RFC 1521 MIME September 1993
+
+
+ format. A very simple and portable subtype,
+ richtext, was defined in RFC 1341, with a future
+ revision expected.
+
+ multipart -- data consisting of multiple parts of
+ independent data types. Four initial subtypes
+ are defined, including the primary "mixed"
+ subtype, "alternative" for representing the same
+ data in multiple formats, "parallel" for parts
+ intended to be viewed simultaneously, and "digest"
+ for multipart entities in which each part is of
+ type "message".
+
+ message -- an encapsulated message. A body of
+ Content-Type "message" is itself all or part of a
+ fully formatted RFC 822 conformant message which
+ may contain its own different Content-Type header
+ field. The primary subtype is "rfc822". The
+ "partial" subtype is defined for partial messages,
+ to permit the fragmented transmission of bodies
+ that are thought to be too large to be passed
+ through mail transport facilities. Another
+ subtype, "External-body", is defined for
+ specifying large bodies by reference to an
+ external data source.
+
+ image -- image data. Image requires a display device
+ (such as a graphical display, a printer, or a FAX
+ machine) to view the information. Initial
+ subtypes are defined for two widely-used image
+ formats, jpeg and gif.
+
+ audio -- audio data, with initial subtype "basic".
+ Audio requires an audio output device (such as a
+ speaker or a telephone) to "display" the contents.
+
+ video -- video data. Video requires the capability to
+ display moving images, typically including
+ specialized hardware and software. The initial
+ subtype is "mpeg".
+
+ application -- some other kind of data, typically
+ either uninterpreted binary data or information to
+ be processed by a mail-based application. The
+ primary subtype, "octet-stream", is to be used in
+ the case of uninterpreted binary data, in which
+ case the simplest recommended action is to offer
+ to write the information into a file for the user.
+
+
+
+Borenstein & Freed [Page 12]
+
+RFC 1521 MIME September 1993
+
+
+ An additional subtype, "PostScript", is defined
+ for transporting PostScript documents in bodies.
+ Other expected uses for "application" include
+ spreadsheets, data for mail-based scheduling
+ systems, and languages for "active"
+ (computational) email. (Note that active email
+ and other application data may entail several
+ security considerations, which are discussed later
+ in this memo, particularly in the context of
+ application/PostScript.)
+
+ Default RFC 822 messages are typed by this protocol as plain text in
+ the US-ASCII character set, which can be explicitly specified as
+ "Content-type: text/plain; charset=us-ascii". If no Content-Type is
+ specified, this default is assumed. In the presence of a MIME-
+ Version header field, a receiving User Agent can also assume that
+ plain US-ASCII text was the sender's intent. In the absence of a
+ MIME-Version specification, plain US-ASCII text must still be
+ assumed, but the sender's intent might have been otherwise.
+
+ RATIONALE: In the absence of any Content-Type header field or
+ MIME-Version header field, it is impossible to be certain that a
+ message is actually text in the US-ASCII character set, since it
+ might well be a message that, using the conventions that predate
+ this document, includes text in another character set or non-
+ textual data in a manner that cannot be automatically recognized
+ (e.g., a uuencoded compressed UNIX tar file). Although there is
+ no fully acceptable alternative to treating such untyped messages
+ as "text/plain; charset=us-ascii", implementors should remain
+ aware that if a message lacks both the MIME-Version and the
+ Content-Type header fields, it may in practice contain almost
+ anything.
+
+ It should be noted that the list of Content-Type values given here
+ may be augmented in time, via the mechanisms described above, and
+ that the set of subtypes is expected to grow substantially.
+
+ When a mail reader encounters mail with an unknown Content-type
+ value, it should generally treat it as equivalent to
+ "application/octet-stream", as described later in this document.
+
+5. The Content-Transfer-Encoding Header Field
+
+ Many Content-Types which could usefully be transported via email are
+ represented, in their "natural" format, as 8-bit character or binary
+ data. Such data cannot be transmitted over some transport protocols.
+ For example, RFC 821 restricts mail messages to 7-bit US-ASCII data
+ with lines no longer than 1000 characters.
+
+
+
+Borenstein & Freed [Page 13]
+
+RFC 1521 MIME September 1993
+
+
+ It is necessary, therefore, to define a standard mechanism for re-
+ encoding such data into a 7-bit short-line format. This document
+ specifies that such encodings will be indicated by a new "Content-
+ Transfer-Encoding" header field. The Content-Transfer-Encoding field
+ is used to indicate the type of transformation that has been used in
+ order to represent the body in an acceptable manner for transport.
+
+ Unlike Content-Types, a proliferation of Content-Transfer-Encoding
+ values is undesirable and unnecessary. However, establishing only a
+ single Content-Transfer-Encoding mechanism does not seem possible.
+ There is a tradeoff between the desire for a compact and efficient
+ encoding of largely-binary data and the desire for a readable
+ encoding of data that is mostly, but not entirely, 7-bit data. For
+ this reason, at least two encoding mechanisms are necessary: a
+ "readable" encoding and a "dense" encoding.
+
+ The Content-Transfer-Encoding field is designed to specify an
+ invertible mapping between the "native" representation of a type of
+ data and a representation that can be readily exchanged using 7 bit
+ mail transport protocols, such as those defined by RFC 821 (SMTP).
+ This field has not been defined by any previous standard. The field's
+ value is a single token specifying the type of encoding, as
+ enumerated below. Formally:
+
+ encoding := "Content-Transfer-Encoding" ":" mechanism
+
+ mechanism := "7bit" ; case-insensitive
+ / "quoted-printable"
+ / "base64"
+ / "8bit"
+ / "binary"
+ / x-token
+
+ These values are not case sensitive. That is, Base64 and BASE64 and
+ bAsE64 are all equivalent. An encoding type of 7BIT requires that
+ the body is already in a seven-bit mail-ready representation. This
+ is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is
+ assumed if the Content-Transfer-Encoding header field is not present.
+
+ The values "8bit", "7bit", and "binary" all mean that NO encoding has
+ been performed. However, they are potentially useful as indications
+ of the kind of data contained in the object, and therefore of the
+ kind of encoding that might need to be performed for transmission in
+ a given transport system. In particular:
+
+ "7bit" means that the data is all represented as short
+ lines of US-ASCII data.
+
+
+
+
+Borenstein & Freed [Page 14]
+
+RFC 1521 MIME September 1993
+
+
+ "8bit" means that the lines are short, but there may be
+ non-ASCII characters (octets with the high-order
+ bit set).
+
+ "Binary" means that not only may non-ASCII characters
+ be present, but also that the lines are not
+ necessarily short enough for SMTP transport.
+
+ The difference between "8bit" (or any other conceivable bit-width
+ token) and the "binary" token is that "binary" does not require
+ adherence to any limits on line length or to the SMTP CRLF semantics,
+ while the bit-width tokens do require such adherence. If the body
+ contains data in any bit-width other than 7-bit, the appropriate
+ bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"
+ for unencoded 8 bit wide data). If the body contains binary data,
+ the "binary" Content-Transfer-Encoding token must be used.
+
+ NOTE: The distinction between the Content-Transfer-Encoding values
+ of "binary", "8bit", etc. may seem unimportant, in that all of
+ them really mean "none" -- that is, there has been no encoding of
+ the data for transport. However, clear labeling will be of
+ enormous value to gateways between future mail transport systems
+ with differing capabilities in transporting data that do not meet
+ the restrictions of RFC 821 transport.
+
+ Mail transport for unencoded 8-bit data is defined in RFC-1426
+ [RFC-1426]. As of the publication of this document, there are no
+ standardized Internet mail transports for which it is legitimate
+ to include unencoded binary data in mail bodies. Thus there are
+ no circumstances in which the "binary" Content-Transfer-Encoding
+ is actually legal on the Internet. However, in the event that
+ binary mail transport becomes a reality in Internet mail, or when
+ this document is used in conjunction with any other binary-capable
+ transport mechanism, binary bodies should be labeled as such using
+ this mechanism.
+
+ NOTE: The five values defined for the Content-Transfer-Encoding
+ field imply nothing about the Content-Type other than the
+ algorithm by which it was encoded or the transport system
+ requirements if unencoded.
+
+ Implementors may, if necessary, define new Content-Transfer-Encoding
+ values, but must use an x-token, which is a name prefixed by "X-" to
+ indicate its non-standard status, e.g., "Content-Transfer-Encoding:
+ x-my-new-encoding". However, unlike Content-Types and subtypes, the
+ creation of new Content-Transfer-Encoding values is explicitly and
+ strongly discouraged, as it seems likely to hinder interoperability
+ with little potential benefit. Their use is allowed only as the
+
+
+
+Borenstein & Freed [Page 15]
+
+RFC 1521 MIME September 1993
+
+
+ result of an agreement between cooperating user agents.
+
+ If a Content-Transfer-Encoding header field appears as part of a
+ message header, it applies to the entire body of that message. If a
+ Content-Transfer-Encoding header field appears as part of a body
+ part's headers, it applies only to the body of that body part. If an
+ entity is of type "multipart" or "message", the Content-Transfer-
+ Encoding is not permitted to have any value other than a bit width
+ (e.g., "7bit", "8bit", etc.) or "binary".
+
+ It should be noted that email is character-oriented, so that the
+ mechanisms described here are mechanisms for encoding arbitrary octet
+ streams, not bit streams. If a bit stream is to be encoded via one
+ of these mechanisms, it must first be converted to an 8-bit byte
+ stream using the network standard bit order ("big-endian"), in which
+ the earlier bits in a stream become the higher-order bits in a byte.
+ A bit stream not ending at an 8-bit boundary must be padded with
+ zeroes. This document provides a mechanism for noting the addition
+ of such padding in the case of the application Content-Type, which
+ has a "padding" parameter.
+
+ The encoding mechanisms defined here explicitly encode all data in
+ ASCII. Thus, for example, suppose an entity has header fields such
+ as:
+
+ Content-Type: text/plain; charset=ISO-8859-1
+ Content-transfer-encoding: base64
+
+ This must be interpreted to mean that the body is a base64 ASCII
+ encoding of data that was originally in ISO-8859-1, and will be in
+ that character set again after decoding.
+
+ The following sections will define the two standard encoding
+ mechanisms. The definition of new content-transfer-encodings is
+ explicitly discouraged and should only occur when absolutely
+ necessary. All content-transfer-encoding namespace except that
+ beginning with "X-" is explicitly reserved to the IANA for future
+ use. Private agreements about content-transfer-encodings are also
+ explicitly discouraged.
+
+ Certain Content-Transfer-Encoding values may only be used on certain
+ Content-Types. In particular, it is expressly forbidden to use any
+ encodings other than "7bit", "8bit", or "binary" with any Content-
+ Type that recursively includes other Content-Type fields, notably the
+ "multipart" and "message" Content-Types. All encodings that are
+ desired for bodies of type multipart or message must be done at the
+ innermost level, by encoding the actual body that needs to be
+ encoded.
+
+
+
+Borenstein & Freed [Page 16]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE ON ENCODING RESTRICTIONS: Though the prohibition against
+ using content-transfer-encodings on data of type multipart or
+ message may seem overly restrictive, it is necessary to prevent
+ nested encodings, in which data are passed through an encoding
+ algorithm multiple times, and must be decoded multiple times in
+ order to be properly viewed. Nested encodings add considerable
+ complexity to user agents: aside from the obvious efficiency
+ problems with such multiple encodings, they can obscure the basic
+ structure of a message. In particular, they can imply that
+ several decoding operations are necessary simply to find out what
+ types of objects a message contains. Banning nested encodings may
+ complicate the job of certain mail gateways, but this seems less
+ of a problem than the effect of nested encodings on user agents.
+
+ NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
+ TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding
+ could be inferred from the characteristics of the Content-Type
+ that is to be encoded, or, at the very least, that certain
+ Content-Transfer-Encodings could be mandated for use with specific
+ Content-Types. There are several reasons why this is not the case.
+ First, given the varying types of transports used for mail, some
+ encodings may be appropriate for some Content-Type/transport
+ combinations and not for others. (For example, in an 8-bit
+ transport, no encoding would be required for text in certain
+ character sets, while such encodings are clearly required for 7-
+ bit SMTP.) Second, certain Content-Types may require different
+ types of transfer encoding under different circumstances. For
+ example, many PostScript bodies might consist entirely of short
+ lines of 7-bit data and hence require little or no encoding.
+ Other PostScript bodies (especially those using Level 2
+ PostScript's binary encoding mechanism) may only be reasonably
+ represented using a binary transport encoding. Finally, since
+ Content-Type is intended to be an open-ended specification
+ mechanism, strict specification of an association between
+ Content-Types and encodings effectively couples the specification
+ of an application protocol with a specific lower-level transport.
+ This is not desirable since the developers of a Content-Type
+ should not have to be aware of all the transports in use and what
+ their limitations are.
+
+ NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64
+ encodings are designed so that conversion between them is
+ possible. The only issue that arises in such a conversion is the
+ handling of line breaks. When converting from quoted-printable to
+ base64 a line break must be converted into a CRLF sequence.
+ Similarly, a CRLF sequence in base64 data must be converted to a
+ quoted-printable line break, but ONLY when converting text data.
+
+
+
+
+Borenstein & Freed [Page 17]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in
+ earlier drafts of this memo, regarding the model for when email
+ data was to be converted to canonical form and encoded, and in
+ particular how this process would affect the treatment of CRLFs,
+ given that the representation of newlines varies greatly from
+ system to system, and the relationship between content-transfer-
+ encodings and character sets. For this reason, a canonical model
+ for encoding is presented as Appendix G.
+
+5.1. Quoted-Printable Content-Transfer-Encoding
+
+ The Quoted-Printable encoding is intended to represent data that
+ largely consists of octets that correspond to printable characters in
+ the ASCII character set. It encodes the data in such a way that the
+ resulting octets are unlikely to be modified by mail transport. If
+ the data being encoded are mostly ASCII text, the encoded form of the
+ data remains largely recognizable by humans. A body which is
+ entirely ASCII may also be encoded in Quoted-Printable to ensure the
+ integrity of the data should the message pass through a character-
+ translating, and/or line-wrapping gateway.
+
+ In this encoding, octets are to be represented as determined by the
+ following rules:
+
+ Rule #1: (General 8-bit representation) Any octet, except those
+ indicating a line break according to the newline convention of the
+ canonical (standard) form of the data being encoded, may be
+ represented by an "=" followed by a two digit hexadecimal
+ representation of the octet's value. The digits of the
+ hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".
+ Uppercase letters must be used when sending hexadecimal data,
+ though a robust implementation may choose to recognize lowercase
+ letters on receipt. Thus, for example, the value 12 (ASCII form
+ feed) can be represented by "=0C", and the value 61 (ASCII EQUAL
+ SIGN) can be represented by "=3D". Except when the following
+ rules allow an alternative encoding, this rule is mandatory.
+
+ Rule #2: (Literal representation) Octets with decimal values of 33
+ through 60 inclusive, and 62 through 126, inclusive, MAY be
+ represented as the ASCII characters which correspond to those
+ octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN
+ through TILDE, respectively).
+
+ Rule #3: (White Space): Octets with values of 9 and 32 MAY be
+ represented as ASCII TAB (HT) and SPACE characters, respectively,
+ but MUST NOT be so represented at the end of an encoded line. Any
+ TAB (HT) or SPACE characters on an encoded line MUST thus be
+ followed on that line by a printable character. In particular, an
+
+
+
+Borenstein & Freed [Page 18]
+
+RFC 1521 MIME September 1993
+
+
+ "=" at the end of an encoded line, indicating a soft line break
+ (see rule #5) may follow one or more TAB (HT) or SPACE characters.
+ It follows that an octet with value 9 or 32 appearing at the end
+ of an encoded line must be represented according to Rule #1. This
+ rule is necessary because some MTAs (Message Transport Agents,
+ programs which transport messages from one user to another, or
+ perform a part of such transfers) are known to pad lines of text
+ with SPACEs, and others are known to remove "white space"
+ characters from the end of a line. Therefore, when decoding a
+ Quoted-Printable body, any trailing white space on a line must be
+ deleted, as it will necessarily have been added by intermediate
+ transport agents.
+
+ Rule #4 (Line Breaks): A line break in a text body, independent of
+ what its representation is following the canonical representation
+ of the data being encoded, must be represented by a (RFC 822) line
+ break, which is a CRLF sequence, in the Quoted-Printable encoding.
+ Since the canonical representation of types other than text do not
+ generally include the representation of line breaks, no hard line
+ breaks (i.e. line breaks that are intended to be meaningful and
+ to be displayed to the user) should occur in the quoted-printable
+ encoding of such types. Of course, occurrences of "=0D", "=0A",
+ "0A=0D" and "=0D=0A" will eventually be encountered. In general,
+ however, base64 is preferred over quoted-printable for binary
+ data.
+
+ Note that many implementations may elect to encode the local
+ representation of various content types directly, as described in
+ Appendix G. In particular, this may apply to plain text material
+ on systems that use newline conventions other than CRLF
+ delimiters. Such an implementation is permissible, but the
+ generation of line breaks must be generalized to account for the
+ case where alternate representations of newline sequences are
+ used.
+
+ Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES
+ that encoded lines be no more than 76 characters long. If longer
+ lines are to be encoded with the Quoted-Printable encoding, 'soft'
+ line breaks must be used. An equal sign as the last character on a
+ encoded line indicates such a non-significant ('soft') line break
+ in the encoded text. Thus if the "raw" form of the line is a
+ single unencoded line that says:
+
+ Now's the time for all folk to come to the aid of
+ their country.
+
+ This can be represented, in the Quoted-Printable encoding, as
+
+
+
+
+Borenstein & Freed [Page 19]
+
+RFC 1521 MIME September 1993
+
+
+ Now's the time =
+ for all folk to come=
+ to the aid of their country.
+
+ This provides a mechanism with which long lines are encoded in
+ such a way as to be restored by the user agent. The 76 character
+ limit does not count the trailing CRLF, but counts all other
+ characters, including any equal signs.
+
+ Since the hyphen character ("-") is represented as itself in the
+ Quoted-Printable encoding, care must be taken, when encapsulating a
+ quoted-printable encoded body in a multipart entity, to ensure that
+ the encapsulation boundary does not appear anywhere in the encoded
+ body. (A good strategy is to choose a boundary that includes a
+ character sequence such as "=_" which can never appear in a quoted-
+ printable body. See the definition of multipart messages later in
+ this document.)
+
+ NOTE: The quoted-printable encoding represents something of a
+ compromise between readability and reliability in transport.
+ Bodies encoded with the quoted-printable encoding will work
+ reliably over most mail gateways, but may not work perfectly over
+ a few gateways, notably those involving translation into EBCDIC.
+ (In theory, an EBCDIC gateway could decode a quoted-printable body
+ and re-encode it using base64, but such gateways do not yet
+ exist.) A higher level of confidence is offered by the base64
+ Content-Transfer-Encoding. A way to get reasonably reliable
+ transport through EBCDIC gateways is to also quote the ASCII
+ characters
+
+ !"#$@[\]^`{|}~
+
+ according to rule #1. See Appendix B for more information.
+
+ Because quoted-printable data is generally assumed to be line-
+ oriented, it is to be expected that the representation of the breaks
+ between the lines of quoted printable data may be altered in
+ transport, in the same manner that plain text mail has always been
+ altered in Internet mail when passing between systems with differing
+ newline conventions. If such alterations are likely to constitute a
+ corruption of the data, it is probably more sensible to use the
+ base64 encoding rather than the quoted-printable encoding.
+
+ WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-
+ printable, care must be taken to encode CR and LF characters as "=0D"
+ and "=0A", respectively. In particular, a CRLF sequence in binary
+ data should be encoded as "=0D=0A". Otherwise, if CRLF were
+ represented as a hard line break, it might be incorrectly decoded on
+
+
+
+Borenstein & Freed [Page 20]
+
+RFC 1521 MIME September 1993
+
+
+ platforms with different line break conventions.
+
+ For formalists, the syntax of quoted-printable data is described by
+ the following grammar:
+
+ quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
+ ; Maximum line length of 76 characters excluding CRLF
+
+ ptext := octet /<any ASCII character except "=", SPACE, or TAB>
+ ; characters not listed as "mail-safe" in Appendix B
+ ; are also not recommended.
+
+ octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
+ ; octet must be used for characters > 127, =, SPACE, or TAB,
+ ; and is recommended for any characters not listed in
+ ; Appendix B as "mail-safe".
+
+5.2. Base64 Content-Transfer-Encoding
+
+ The Base64 Content-Transfer-Encoding is designed to represent
+ arbitrary sequences of octets in a form that need not be humanly
+ readable. The encoding and decoding algorithms are simple, but the
+ encoded data are consistently only about 33 percent larger than the
+ unencoded data. This encoding is virtually identical to the one used
+ in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
+ The base64 encoding is adapted from RFC 1421, with one change: base64
+ eliminates the "*" mechanism for embedded clear text.
+
+ A 65-character subset of US-ASCII is used, enabling 6 bits to be
+ represented per printable character. (The extra 65th character, "=",
+ is used to signify a special processing function.)
+
+ NOTE: This subset has the important property that it is
+ represented identically in all versions of ISO 646, including US
+ ASCII, and all characters in the subset are also represented
+ identically in all versions of EBCDIC. Other popular encodings,
+ such as the encoding used by the uuencode utility and the base85
+ encoding specified as part of Level 2 PostScript, do not share
+ these properties, and thus do not fulfill the portability
+ requirements a binary transport encoding for mail must meet.
+
+ The encoding process represents 24-bit groups of input bits as output
+ strings of 4 encoded characters. Proceeding from left to right, a
+ 24-bit input group is formed by concatenating 3 8-bit input groups.
+ These 24 bits are then treated as 4 concatenated 6-bit groups, each
+ of which is translated into a single digit in the base64 alphabet.
+ When encoding a bit stream via the base64 encoding, the bit stream
+ must be presumed to be ordered with the most-significant-bit first.
+
+
+
+Borenstein & Freed [Page 21]
+
+RFC 1521 MIME September 1993
+
+
+ That is, the first bit in the stream will be the high-order bit in
+ the first byte, and the eighth bit will be the low-order bit in the
+ first byte, and so on.
+
+ Each 6-bit group is used as an index into an array of 64 printable
+ characters. The character referenced by the index is placed in the
+ output string. These characters, identified in Table 1, below, are
+ selected so as to be universally representable, and the set excludes
+ characters with particular significance to SMTP (e.g., ".", CR, LF)
+ and to the encapsulation boundaries defined in this document (e.g.,
+ "-").
+
+ Table 1: The Base64 Alphabet
+
+ Value Encoding Value Encoding Value Encoding Value Encoding
+ 0 A 17 R 34 i 51 z
+ 1 B 18 S 35 j 52 0
+ 2 C 19 T 36 k 53 1
+ 3 D 20 U 37 l 54 2
+ 4 E 21 V 38 m 55 3
+ 5 F 22 W 39 n 56 4
+ 6 G 23 X 40 o 57 5
+ 7 H 24 Y 41 p 58 6
+ 8 I 25 Z 42 q 59 7
+ 9 J 26 a 43 r 60 8
+ 10 K 27 b 44 s 61 9
+ 11 L 28 c 45 t 62 +
+ 12 M 29 d 46 u 63 /
+ 13 N 30 e 47 v
+ 14 O 31 f 48 w (pad) =
+ 15 P 32 g 49 x
+ 16 Q 33 h 50 y
+
+ The output stream (encoded bytes) must be represented in lines of no
+ more than 76 characters each. All line breaks or other characters
+ not found in Table 1 must be ignored by decoding software. In base64
+ data, characters other than those in Table 1, line breaks, and other
+ white space probably indicate a transmission error, about which a
+ warning message or even a message rejection might be appropriate
+ under some circumstances.
+
+ Special processing is performed if fewer than 24 bits are available
+ at the end of the data being encoded. A full encoding quantum is
+ always completed at the end of a body. When fewer than 24 input bits
+ are available in an input group, zero bits are added (on the right)
+ to form an integral number of 6-bit groups. Padding at the end of
+ the data is performed using the '=' character. Since all base64
+ input is an integral number of octets, only the following cases can
+
+
+
+Borenstein & Freed [Page 22]
+
+RFC 1521 MIME September 1993
+
+
+ arise: (1) the final quantum of encoding input is an integral
+ multiple of 24 bits; here, the final unit of encoded output will be
+ an integral multiple of 4 characters with no "=" padding, (2) the
+ final quantum of encoding input is exactly 8 bits; here, the final
+ unit of encoded output will be two characters followed by two "="
+ padding characters, or (3) the final quantum of encoding input is
+ exactly 16 bits; here, the final unit of encoded output will be three
+ characters followed by one "=" padding character.
+
+ Because it is used only for padding at the end of the data, the
+ occurrence of any '=' characters may be taken as evidence that the
+ end of the data has been reached (without truncation in transit). No
+ such assurance is possible, however, when the number of octets
+ transmitted was a multiple of three.
+
+ Any characters outside of the base64 alphabet are to be ignored in
+ base64-encoded data. The same applies to any illegal sequence of
+ characters in the base64 encoding, such as "====="
+
+ Care must be taken to use the proper octets for line breaks if base64
+ encoding is applied directly to text material that has not been
+ converted to canonical form. In particular, text line breaks must be
+ converted into CRLF sequences prior to base64 encoding. The important
+ thing to note is that this may be done directly by the encoder rather
+ than in a prior canonicalization step in some implementations.
+
+ NOTE: There is no need to worry about quoting apparent
+ encapsulation boundaries within base64-encoded parts of multipart
+ entities because no hyphen characters are used in the base64
+ encoding.
+
+6. Additional Content-Header Fields
+
+6.1. Optional Content-ID Header Field
+
+ In constructing a high-level user agent, it may be desirable to allow
+ one body to make reference to another. Accordingly, bodies may be
+ labeled using the "Content-ID" header field, which is syntactically
+ identical to the "Message-ID" header field:
+
+ id := "Content-ID" ":" msg-id
+ Like the Message-ID values, Content-ID values must be generated to be
+ world-unique.
+
+ The Content-ID value may be used for uniquely identifying MIME
+ entities in several contexts, particularly for cacheing data
+ referenced by the message/external-body mechanism. Although the
+ Content-ID header is generally optional, its use is mandatory in
+
+
+
+Borenstein & Freed [Page 23]
+
+RFC 1521 MIME September 1993
+
+
+ implementations which generate data of the optional MIME Content-type
+ "message/external-body". That is, each message/external-body entity
+ must have a Content-ID field to permit cacheing of such data.
+
+ It is also worth noting that the Content-ID value has special
+ semantics in the case of the multipart/alternative content-type.
+ This is explained in the section of this document dealing with
+ multipart/alternative.
+
+6.2. Optional Content-Description Header Field
+
+ The ability to associate some descriptive information with a given
+ body is often desirable. For example, it may be useful to mark an
+ "image" body as "a picture of the Space Shuttle Endeavor." Such text
+ may be placed in the Content-Description header field.
+
+ description := "Content-Description" ":" *text
+
+ The description is presumed to be given in the US-ASCII character
+ set, although the mechanism specified in [RFC-1522] may be used for
+ non-US-ASCII Content-Description values.
+
+7. The Predefined Content-Type Values
+
+ This document defines seven initial Content-Type values and an
+ extension mechanism for private or experimental types. Further
+ standard types must be defined by new published specifications. It
+ is expected that most innovation in new types of mail will take place
+ as subtypes of the seven types defined here. The most essential
+ characteristics of the seven content-types are summarized in Appendix
+ F.
+
+7.1 The Text Content-Type
+
+ The text Content-Type is intended for sending material which is
+ principally textual in form. It is the default Content-Type. A
+ "charset" parameter may be used to indicate the character set of the
+ body text for some text subtypes, notably including the primary
+ subtype, "text/plain", which indicates plain (unformatted) text. The
+ default Content-Type for Internet mail is "text/plain; charset=us-
+ ascii".
+
+ Beyond plain text, there are many formats for representing what might
+ be known as "extended text" -- text with embedded formatting and
+ presentation information. An interesting characteristic of many such
+ representations is that they are to some extent readable even without
+ the software that interprets them. It is useful, then, to
+ distinguish them, at the highest level, from such unreadable data as
+
+
+
+Borenstein & Freed [Page 24]
+
+RFC 1521 MIME September 1993
+
+
+ images, audio, or text represented in an unreadable form. In the
+ absence of appropriate interpretation software, it is reasonable to
+ show subtypes of text to the user, while it is not reasonable to do
+ so with most nontextual data.
+
+ Such formatted textual data should be represented using subtypes of
+ text. Plausible subtypes of text are typically given by the common
+ name of the representation format, e.g., "text/richtext" [RFC-1341].
+
+7.1.1. The charset parameter
+
+ A critical parameter that may be specified in the Content-Type field
+ for text/plain data is the character set. This is specified with a
+ "charset" parameter, as in:
+
+ Content-type: text/plain; charset=us-ascii
+
+ Unlike some other parameter values, the values of the charset
+ parameter are NOT case sensitive. The default character set, which
+ must be assumed in the absence of a charset parameter, is US-ASCII.
+
+ The specification for any future subtypes of "text" must specify
+ whether or not they will also utilize a "charset" parameter, and may
+ possibly restrict its values as well. When used with a particular
+ body, the semantics of the "charset" parameter should be identical to
+ those specified here for "text/plain", i.e., the body consists
+ entirely of characters in the given charset. In particular, definers
+ of future text subtypes should pay close attention the the
+ implications of multibyte character sets for their subtype
+ definitions.
+
+ This RFC specifies the definition of the charset parameter for the
+ purposes of MIME to be a unique mapping of a byte stream to glyphs, a
+ mapping which does not require external profiling information.
+
+ An initial list of predefined character set names can be found at the
+ end of this section. Additional character sets may be registered
+ with IANA, although the standardization of their use requires the
+ usual IESG [RFC-1340] review and approval. Note that if the
+ specified character set includes 8-bit data, a Content-Transfer-
+ Encoding header field and a corresponding encoding on the data are
+ required in order to transmit the body via some mail transfer
+ protocols, such as SMTP.
+
+ The default character set, US-ASCII, has been the subject of some
+ confusion and ambiguity in the past. Not only were there some
+ ambiguities in the definition, there have been wide variations in
+ practice. In order to eliminate such ambiguity and variations in the
+
+
+
+Borenstein & Freed [Page 25]
+
+RFC 1521 MIME September 1993
+
+
+ future, it is strongly recommended that new user agents explicitly
+ specify a character set via the Content-Type header field. "US-
+ ASCII" does not indicate an arbitrary seven-bit character code, but
+ specifies that the body uses character coding that uses the exact
+ correspondence of codes to characters specified in ASCII. National
+ use variations of ISO 646 [ISO-646] are NOT ASCII and their use in
+ Internet mail is explicitly discouraged. The omission of the ISO 646
+ character set is deliberate in this regard. The character set name
+ of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
+ The character set name "ASCII" is reserved and must not be used for
+ any purpose.
+
+ NOTE: RFC 821 explicitly specifies "ASCII", and references an
+ earlier version of the American Standard. Insofar as one of the
+ purposes of specifying a Content-Type and character set is to
+ permit the receiver to unambiguously determine how the sender
+ intended the coded message to be interpreted, assuming anything
+ other than "strict ASCII" as the default would risk unintentional
+ and incompatible changes to the semantics of messages now being
+ transmitted. This also implies that messages containing
+ characters coded according to national variations on ISO 646, or
+ using code-switching procedures (e.g., those of ISO 2022), as well
+ as 8-bit or multiple octet character encodings MUST use an
+ appropriate character set specification to be consistent with this
+ specification.
+
+ The complete US-ASCII character set is listed in [US-ASCII]. Note
+ that the control characters including DEL (0-31, 127) have no defined
+ meaning apart from the combination CRLF (ASCII values 13 and 10)
+ indicating a new line. Two of the characters have de facto meanings
+ in wide use: FF (12) often means "start subsequent text on the
+ beginning of a new page"; and TAB or HT (9) often (though not always)
+ means "move the cursor to the next available column after the current
+ position where the column number is a multiple of 8 (counting the
+ first column as column 0)." Apart from this, any use of the control
+ characters or DEL in a body must be part of a private agreement
+ between the sender and recipient. Such private agreements are
+ discouraged and should be replaced by the other capabilities of this
+ document.
+
+ NOTE: Beyond US-ASCII, an enormous proliferation of character sets
+ is possible. It is the opinion of the IETF working group that a
+ large number of character sets is NOT a good thing. We would
+ prefer to specify a single character set that can be used
+ universally for representing all of the world's languages in
+ electronic mail. Unfortunately, existing practice in several
+ communities seems to point to the continued use of multiple
+ character sets in the near future. For this reason, we define
+
+
+
+Borenstein & Freed [Page 26]
+
+RFC 1521 MIME September 1993
+
+
+ names for a small number of character sets for which a strong
+ constituent base exists.
+
+ The defined charset values are:
+
+ US-ASCII -- as defined in [US-ASCII].
+
+ ISO-8859-X -- where "X" is to be replaced, as necessary, for the
+ parts of ISO-8859 [ISO-8859]. Note that the ISO 646
+ character sets have deliberately been omitted in favor of
+ their 8859 replacements, which are the designated character
+ sets for Internet mail. As of the publication of this
+ document, the legitimate values for "X" are the digits 1
+ through 9.
+
+ The character sets specified above are the ones that were relatively
+ uncontroversial during the drafting of MIME. This document does not
+ endorse the use of any particular character set other than US-ASCII,
+ and recognizes that the future evolution of world character sets
+ remains unclear. It is expected that in the future, additional
+ character sets will be registered for use in MIME.
+
+ Note that the character set used, if anything other than US-ASCII,
+ must always be explicitly specified in the Content-Type field.
+
+ No other character set name may be used in Internet mail without the
+ publication of a formal specification and its registration with IANA,
+ or by private agreement, in which case the character set name must
+ begin with "X-".
+
+ Implementors are discouraged from defining new character sets for
+ mail use unless absolutely necessary.
+
+ The "charset" parameter has been defined primarily for the purpose of
+ textual data, and is described in this section for that reason.
+ However, it is conceivable that non-textual data might also wish to
+ specify a charset value for some purpose, in which case the same
+ syntax and values should be used.
+
+ In general, mail-sending software must always use the "lowest common
+ denominator" character set possible. For example, if a body contains
+ only US-ASCII characters, it must be marked as being in the US-ASCII
+ character set, not ISO-8859-1, which, like all the ISO-8859 family of
+ character sets, is a superset of US-ASCII. More generally, if a
+ widely-used character set is a subset of another character set, and a
+ body contains only characters in the widely-used subset, it must be
+ labeled as being in that subset. This will increase the chances that
+ the recipient will be able to view the mail correctly.
+
+
+
+Borenstein & Freed [Page 27]
+
+RFC 1521 MIME September 1993
+
+
+7.1.2. The Text/plain subtype
+
+ The primary subtype of text is "plain". This indicates plain
+ (unformatted) text. The default Content-Type for Internet mail,
+ "text/plain; charset=us-ascii", describes existing Internet practice.
+ That is, it is the type of body defined by RFC 822.
+
+ No other text subtype is defined by this document.
+
+ The formal grammar for the content-type header field for text is as
+ follows:
+
+ text-type := "text" "/" text-subtype [";" "charset" "=" charset]
+
+ text-subtype := "plain" / extension-token
+
+ charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"
+ / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"
+ / "iso-8859-8" / "iso-8859-9" / extension-token
+ ; case insensitive
+
+7.2. The Multipart Content-Type
+
+ In the case of multiple part entities, in which one or more different
+ sets of data are combined in a single body, a "multipart" Content-
+ Type field must appear in the entity's header. The body must then
+ contain one or more "body parts," each preceded by an encapsulation
+ boundary, and the last one followed by a closing boundary. Each part
+ starts with an encapsulation boundary, and then contains a body part
+ consisting of header area, a blank line, and a body area. Thus a
+ body part is similar to an RFC 822 message in syntax, but different
+ in meaning.
+
+ A body part is NOT to be interpreted as actually being an RFC 822
+ message. To begin with, NO header fields are actually required in
+ body parts. A body part that starts with a blank line, therefore, is
+ allowed and is a body part for which all default values are to be
+ assumed. In such a case, the absence of a Content-Type header field
+ implies that the corresponding body is plain US-ASCII text. The only
+ header fields that have defined meaning for body parts are those the
+ names of which begin with "Content-". All other header fields are
+ generally to be ignored in body parts. Although they should
+ generally be retained in mail processing, they may be discarded by
+ gateways if necessary. Such other fields are permitted to appear in
+ body parts but must not be depended on. "X-" fields may be created
+ for experimental or private purposes, with the recognition that the
+ information they contain may be lost at some gateways.
+
+
+
+
+Borenstein & Freed [Page 28]
+
+RFC 1521 MIME September 1993
+
+
+ NOTE: The distinction between an RFC 822 message and a body part
+ is subtle, but important. A gateway between Internet and X.400
+ mail, for example, must be able to tell the difference between a
+ body part that contains an image and a body part that contains an
+ encapsulated message, the body of which is an image. In order to
+ represent the latter, the body part must have "Content-Type:
+ message", and its body (after the blank line) must be the
+ encapsulated message, with its own "Content-Type: image" header
+ field. The use of similar syntax facilitates the conversion of
+ messages to body parts, and vice versa, but the distinction
+ between the two must be understood by implementors. (For the
+ special case in which all parts actually are messages, a "digest"
+ subtype is also defined.)
+
+ As stated previously, each body part is preceded by an encapsulation
+ boundary. The encapsulation boundary MUST NOT appear inside any of
+ the encapsulated parts. Thus, it is crucial that the composing agent
+ be able to choose and specify the unique boundary that will separate
+ the parts.
+
+ All present and future subtypes of the "multipart" type must use an
+ identical syntax. Subtypes may differ in their semantics, and may
+ impose additional restrictions on syntax, but must conform to the
+ required syntax for the multipart type. This requirement ensures
+ that all conformant user agents will at least be able to recognize
+ and separate the parts of any multipart entity, even of an
+ unrecognized subtype.
+
+ As stated in the definition of the Content-Transfer-Encoding field,
+ no encoding other than "7bit", "8bit", or "binary" is permitted for
+ entities of type "multipart". The multipart delimiters and header
+ fields are always represented as 7-bit ASCII in any case (though the
+ header fields may encode non-ASCII header text as per [RFC-1522]),
+ and data within the body parts can be encoded on a part-by-part
+ basis, with Content-Transfer-Encoding fields for each appropriate
+ body part.
+
+ Mail gateways, relays, and other mail handling agents are commonly
+ known to alter the top-level header of an RFC 822 message. In
+ particular, they frequently add, remove, or reorder header fields.
+ Such alterations are explicitly forbidden for the body part headers
+ embedded in the bodies of messages of type "multipart."
+
+7.2.1. Multipart: The common syntax
+
+ All subtypes of "multipart" share a common syntax, defined in this
+ section. A simple example of a multipart message also appears in
+ this section. An example of a more complex multipart message is
+
+
+
+Borenstein & Freed [Page 29]
+
+RFC 1521 MIME September 1993
+
+
+ given in Appendix C.
+
+ The Content-Type field for multipart entities requires one parameter,
+ "boundary", which is used to specify the encapsulation boundary. The
+ encapsulation boundary is defined as a line consisting entirely of
+ two hyphen characters ("-", decimal code 45) followed by the boundary
+ parameter value from the Content-Type header field.
+
+ NOTE: The hyphens are for rough compatibility with the earlier RFC
+ 934 method of message encapsulation, and for ease of searching for
+ the boundaries in some implementations. However, it should be
+ noted that multipart messages are NOT completely compatible with
+ RFC 934 encapsulations; in particular, they do not obey RFC 934
+ quoting conventions for embedded lines that begin with hyphens.
+ This mechanism was chosen over the RFC 934 mechanism because the
+ latter causes lines to grow with each level of quoting. The
+ combination of this growth with the fact that SMTP implementations
+ sometimes wrap long lines made the RFC 934 mechanism unsuitable
+ for use in the event that deeply-nested multipart structuring is
+ ever desired.
+
+ WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
+ type field is such that it is often necessary to enclose the
+ boundaries in quotes on the Content-type line. This is not always
+ necessary, but never hurts. Implementors should be sure to study the
+ grammar carefully in order to avoid producing illegal Content-type
+ fields. Thus, a typical multipart Content-Type header field might
+ look like this:
+
+ Content-Type: multipart/mixed;
+ boundary=gc0p4Jq0M2Yt08jU534c0p
+
+ But the following is illegal:
+
+ Content-Type: multipart/mixed;
+ boundary=gc0p4Jq0M:2Yt08jU534c0p
+
+ (because of the colon) and must instead be represented as
+
+ Content-Type: multipart/mixed;
+ boundary="gc0p4Jq0M:2Yt08jU534c0p"
+
+ This indicates that the entity consists of several parts, each itself
+ with a structure that is syntactically identical to an RFC 822
+ message, except that the header area might be completely empty, and
+ that the parts are each preceded by the line
+
+ --gc0p4Jq0M:2Yt08jU534c0p
+
+
+
+Borenstein & Freed [Page 30]
+
+RFC 1521 MIME September 1993
+
+
+ Note that the encapsulation boundary must occur at the beginning of a
+ line, i.e., following a CRLF, and that the initial CRLF is considered
+ to be attached to the encapsulation boundary rather than part of the
+ preceding part. The boundary must be followed immediately either by
+ another CRLF and the header fields for the next part, or by two
+ CRLFs, in which case there are no header fields for the next part
+ (and it is therefore assumed to be of Content-Type text/plain).
+
+ NOTE: The CRLF preceding the encapsulation line is conceptually
+ attached to the boundary so that it is possible to have a part
+ that does not end with a CRLF (line break). Body parts that must
+ be considered to end with line breaks, therefore, must have two
+ CRLFs preceding the encapsulation line, the first of which is part
+ of the preceding body part, and the second of which is part of the
+ encapsulation boundary.
+
+ Encapsulation boundaries must not appear within the encapsulations,
+ and must be no longer than 70 characters, not counting the two
+ leading hyphens.
+
+ The encapsulation boundary following the last body part is a
+ distinguished delimiter that indicates that no further body parts
+ will follow. Such a delimiter is identical to the previous
+ delimiters, with the addition of two more hyphens at the end of the
+ line:
+
+ --gc0p4Jq0M2Yt08jU534c0p--
+
+ There appears to be room for additional information prior to the
+ first encapsulation boundary and following the final boundary. These
+ areas should generally be left blank, and implementations must ignore
+ anything that appears before the first boundary or after the last
+ one.
+
+ NOTE: These "preamble" and "epilogue" areas are generally not used
+ because of the lack of proper typing of these parts and the lack
+ of clear semantics for handling these areas at gateways,
+ particularly X.400 gateways. However, rather than leaving the
+ preamble area blank, many MIME implementations have found this to
+ be a convenient place to insert an explanatory note for recipients
+ who read the message with pre-MIME software, since such notes will
+ be ignored by MIME-compliant software.
+
+ NOTE: Because encapsulation boundaries must not appear in the body
+ parts being encapsulated, a user agent must exercise care to
+ choose a unique boundary. The boundary in the example above could
+ have been the result of an algorithm designed to produce
+ boundaries with a very low probability of already existing in the
+
+
+
+Borenstein & Freed [Page 31]
+
+RFC 1521 MIME September 1993
+
+
+ data to be encapsulated without having to prescan the data.
+ Alternate algorithms might result in more 'readable' boundaries
+ for a recipient with an old user agent, but would require more
+ attention to the possibility that the boundary might appear in the
+ encapsulated part. The simplest boundary possible is something
+ like "---", with a closing boundary of "-----".
+
+ As a very simple example, the following multipart message has two
+ parts, both of them plain text, one of them explicitly typed and one
+ of them implicitly typed:
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: Sample message
+ MIME-Version: 1.0
+ Content-type: multipart/mixed; boundary="simple
+ boundary"
+
+ This is the preamble. It is to be ignored, though it
+ is a handy place for mail composers to include an
+ explanatory note to non-MIME conformant readers.
+ --simple boundary
+
+ This is implicitly typed plain ASCII text.
+ It does NOT end with a linebreak.
+ --simple boundary
+ Content-type: text/plain; charset=us-ascii
+
+ This is explicitly typed plain ASCII text.
+ It DOES end with a linebreak.
+
+ --simple boundary--
+ This is the epilogue. It is also to be ignored.
+
+ The use of a Content-Type of multipart in a body part within another
+ multipart entity is explicitly allowed. In such cases, for obvious
+ reasons, care must be taken to ensure that each nested multipart
+ entity must use a different boundary delimiter. See Appendix C for an
+ example of nested multipart entities.
+
+ The use of the multipart Content-Type with only a single body part
+ may be useful in certain contexts, and is explicitly permitted.
+
+ The only mandatory parameter for the multipart Content-Type is the
+ boundary parameter, which consists of 1 to 70 characters from a set
+ of characters known to be very robust through email gateways, and NOT
+ ending with white space. (If a boundary appears to end with white
+ space, the white space must be presumed to have been added by a
+
+
+
+Borenstein & Freed [Page 32]
+
+RFC 1521 MIME September 1993
+
+
+ gateway, and must be deleted.) It is formally specified by the
+ following BNF:
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ Overall, the body of a multipart entity may be specified as
+ follows:
+
+ multipart-body := preamble 1*encapsulation
+ close-delimiter epilogue
+
+ encapsulation := delimiter body-part CRLF
+
+ delimiter := "--" boundary CRLF ; taken from Content-Type field.
+ ; There must be no space
+ ; between "--" and boundary.
+
+ close-delimiter := "--" boundary "--" CRLF ; Again, no space
+ by "--",
+
+ preamble := discard-text ; to be ignored upon receipt.
+
+ epilogue := discard-text ; to be ignored upon receipt.
+
+ discard-text := *(*text CRLF)
+
+ body-part := <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere. Note that the
+ semantics of a part differ from the semantics
+ of a message, as described in the text.>
+
+ NOTE: In certain transport enclaves, RFC 822 restrictions such as
+ the one that limits bodies to printable ASCII characters may not
+ be in force. (That is, the transport domains may resemble
+ standard Internet mail transport as specified in RFC821 and
+ assumed by RFC822, but without certain restrictions.) The
+ relaxation of these restrictions should be construed as locally
+ extending the definition of bodies, for example to include octets
+ outside of the ASCII range, as long as these extensions are
+ supported by the transport and adequately documented in the
+
+
+
+Borenstein & Freed [Page 33]
+
+RFC 1521 MIME September 1993
+
+
+ Content-Transfer-Encoding header field. However, in no event are
+ headers (either message headers or body-part headers) allowed to
+ contain anything other than ASCII characters.
+
+ NOTE: Conspicuously missing from the multipart type is a notion of
+ structured, related body parts. In general, it seems premature to
+ try to standardize interpart structure yet. It is recommended
+ that those wishing to provide a more structured or integrated
+ multipart messaging facility should define a subtype of multipart
+ that is syntactically identical, but that always expects the
+ inclusion of a distinguished part that can be used to specify the
+ structure and integration of the other parts, probably referring
+ to them by their Content-ID field. If this approach is used,
+ other implementations will not recognize the new subtype, but will
+ treat it as the primary subtype (multipart/mixed) and will thus be
+ able to show the user the parts that are recognized.
+
+7.2.2. The Multipart/mixed (primary) subtype
+
+ The primary subtype for multipart, "mixed", is intended for use when
+ the body parts are independent and need to be bundled in a particular
+ order. Any multipart subtypes that an implementation does not
+ recognize must be treated as being of subtype "mixed".
+
+7.2.3. The Multipart/alternative subtype
+
+ The multipart/alternative type is syntactically identical to
+ multipart/mixed, but the semantics are different. In particular,
+ each of the parts is an "alternative" version of the same
+ information.
+
+ Systems should recognize that the content of the various parts are
+ interchangeable. Systems should choose the "best" type based on the
+ local environment and preferences, in some cases even through user
+ interaction. As with multipart/mixed, the order of body parts is
+ significant. In this case, the alternatives appear in an order of
+ increasing faithfulness to the original content. In general, the best
+ choice is the LAST part of a type supported by the recipient system's
+ local environment.
+
+ Multipart/alternative may be used, for example, to send mail in a
+ fancy text format in such a way that it can easily be displayed
+ anywhere:
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 34]
+
+RFC 1521 MIME September 1993
+
+
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: Formatted text mail
+ MIME-Version: 1.0
+ Content-Type: multipart/alternative; boundary=boundary42
+
+ --boundary42
+
+ Content-Type: text/plain; charset=us-ascii
+
+ ...plain text version of message goes here....
+ --boundary42
+ Content-Type: text/richtext
+
+ .... RFC 1341 richtext version of same message goes here ...
+ --boundary42
+ Content-Type: text/x-whatever
+
+ .... fanciest formatted version of same message goes here
+ ...
+ --boundary42--
+
+ In this example, users whose mail system understood the "text/x-
+ whatever" format would see only the fancy version, while other users
+ would see only the richtext or plain text version, depending on the
+ capabilities of their system.
+
+ In general, user agents that compose multipart/alternative entities
+ must place the body parts in increasing order of preference, that is,
+ with the preferred format last. For fancy text, the sending user
+ agent should put the plainest format first and the richest format
+ last. Receiving user agents should pick and display the last format
+ they are capable of displaying. In the case where one of the
+ alternatives is itself of type "multipart" and contains unrecognized
+ sub-parts, the user agent may choose either to show that alternative,
+ an earlier alternative, or both.
+
+ NOTE: From an implementor's perspective, it might seem more
+ sensible to reverse this ordering, and have the plainest
+ alternative last. However, placing the plainest alternative first
+ is the friendliest possible option when multipart/alternative
+ entities are viewed using a non-MIME-conformant mail reader.
+ While this approach does impose some burden on conformant mail
+ readers, interoperability with older mail readers was deemed to be
+ more important in this case.
+
+ It may be the case that some user agents, if they can recognize more
+ than one of the formats, will prefer to offer the user the choice of
+
+
+
+Borenstein & Freed [Page 35]
+
+RFC 1521 MIME September 1993
+
+
+ which format to view. This makes sense, for example, if mail
+ includes both a nicely-formatted image version and an easily-edited
+ text version. What is most critical, however, is that the user not
+ automatically be shown multiple versions of the same data. Either
+ the user should be shown the last recognized version or should be
+ given the choice.
+
+ NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each
+ part of a multipart/alternative entity represents the same data, but
+ the mappings between the two are not necessarily without information
+ loss. For example, information is lost when translating ODA to
+ PostScript or plain text. It is recommended that each part should
+ have a different Content-ID value in the case where the information
+ content of the two parts is not identical. However, where the
+ information content is identical -- for example, where several parts
+ of type "application/external- body" specify alternate ways to access
+ the identical data -- the same Content-ID field value should be used,
+ to optimize any cacheing mechanisms that might be present on the
+ recipient's end. However, it is recommended that the Content-ID
+ values used by the parts should not be the same Content-ID value that
+ describes the multipart/alternative as a whole, if there is any such
+ Content-ID field. That is, one Content-ID value will refer to the
+ multipart/alternative entity, while one or more other Content-ID
+ values will refer to the parts inside it.
+
+7.2.4. The Multipart/digest subtype
+
+ This document defines a "digest" subtype of the multipart Content-
+ Type. This type is syntactically identical to multipart/mixed, but
+ the semantics are different. In particular, in a digest, the default
+ Content-Type value for a body part is changed from "text/plain" to
+ "message/rfc822". This is done to allow a more readable digest
+ format that is largely compatible (except for the quoting convention)
+ with RFC 934.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 36]
+
+RFC 1521 MIME September 1993
+
+
+ A digest in this format might, then, look something like this:
+
+ From: Moderator-Address
+ To: Recipient-List
+ MIME-Version: 1.0
+ Subject: Internet Digest, volume 42
+ Content-Type: multipart/digest;
+ boundary="---- next message ----"
+
+ ------ next message ----
+
+ From: someone-else
+ Subject: my opinion
+
+ ...body goes here ...
+
+ ------ next message ----
+
+ From: someone-else-again
+ Subject: my different opinion
+
+ ... another body goes here...
+
+ ------ next message ------
+
+7.2.5. The Multipart/parallel subtype
+
+ This document defines a "parallel" subtype of the multipart Content-
+ Type. This type is syntactically identical to multipart/mixed, but
+ the semantics are different. In particular, in a parallel entity,
+ the order of body parts is not significant.
+
+ A common presentation of this type is to display all of the parts
+ simultaneously on hardware and software that are capable of doing so.
+ However, composing agents should be aware that many mail readers will
+ lack this capability and will show the parts serially in any event.
+
+7.2.6. Other Multipart subtypes
+
+ Other multipart subtypes are expected in the future. MIME
+ implementations must in general treat unrecognized subtypes of
+ multipart as being equivalent to "multipart/mixed".
+
+ The formal grammar for content-type header fields for multipart data
+ is given by:
+
+ multipart-type := "multipart" "/" multipart-subtype
+ ";" "boundary" "=" boundary
+
+
+
+Borenstein & Freed [Page 37]
+
+RFC 1521 MIME September 1993
+
+
+ multipart-subtype := "mixed" / "parallel" / "digest"
+ / "alternative" / extension-token
+
+7.3. The Message Content-Type
+
+ It is frequently desirable, in sending mail, to encapsulate another
+ mail message. For this common operation, a special Content-Type,
+ "message", is defined. The primary subtype, message/rfc822, has no
+ required parameters in the Content-Type field. Additional subtypes,
+ "partial" and "External-body", do have required parameters. These
+ subtypes are explained below.
+
+ NOTE: It has been suggested that subtypes of message might be
+ defined for forwarded or rejected messages. However, forwarded
+ and rejected messages can be handled as multipart messages in
+ which the first part contains any control or descriptive
+ information, and a second part, of type message/rfc822, is the
+ forwarded or rejected message. Composing rejection and forwarding
+ messages in this manner will preserve the type information on the
+ original message and allow it to be correctly presented to the
+ recipient, and hence is strongly encouraged.
+
+ As stated in the definition of the Content-Transfer-Encoding field,
+ no encoding other than "7bit", "8bit", or "binary" is permitted for
+ messages or parts of type "message". Even stronger restrictions
+ apply to the subtypes "message/partial" and "message/external-body",
+ as specified below. The message header fields are always US-ASCII in
+ any case, and data within the body can still be encoded, in which
+ case the Content-Transfer-Encoding header field in the encapsulated
+ message will reflect this. Non-ASCII text in the headers of an
+ encapsulated message can be specified using the mechanisms described
+ in [RFC-1522].
+
+ Mail gateways, relays, and other mail handling agents are commonly
+ known to alter the top-level header of an RFC 822 message. In
+ particular, they frequently add, remove, or reorder header fields.
+ Such alterations are explicitly forbidden for the encapsulated
+ headers embedded in the bodies of messages of type "message."
+
+7.3.1. The Message/rfc822 (primary) subtype
+
+ A Content-Type of "message/rfc822" indicates that the body contains
+ an encapsulated message, with the syntax of an RFC 822 message.
+ However, unlike top-level RFC 822 messages, it is not required that
+ each message/rfc822 body must include a "From", "Subject", and at
+ least one destination header.
+
+ It should be noted that, despite the use of the numbers "822", a
+
+
+
+Borenstein & Freed [Page 38]
+
+RFC 1521 MIME September 1993
+
+
+ message/rfc822 entity can include enhanced information as defined in
+ this document. In other words, a message/rfc822 message may be a
+ MIME message.
+
+7.3.2. The Message/Partial subtype
+
+ A subtype of message, "partial", is defined in order to allow large
+ objects to be delivered as several separate pieces of mail and
+ automatically reassembled by the receiving user agent. (The concept
+ is similar to IP fragmentation/reassembly in the basic Internet
+ Protocols.) This mechanism can be used when intermediate transport
+ agents limit the size of individual messages that can be sent.
+ Content-Type "message/partial" thus indicates that the body contains
+ a fragment of a larger message.
+
+ Three parameters must be specified in the Content-Type field of type
+ message/partial: The first, "id", is a unique identifier, as close to
+ a world-unique identifier as possible, to be used to match the parts
+ together. (In general, the identifier is essentially a message-id;
+ if placed in double quotes, it can be any message-id, in accordance
+ with the BNF for "parameter" given earlier in this specification.)
+ The second, "number", an integer, is the part number, which indicates
+ where this part fits into the sequence of fragments. The third,
+ "total", another integer, is the total number of parts. This third
+ subfield is required on the final part, and is optional (though
+ encouraged) on the earlier parts. Note also that these parameters
+ may be given in any order.
+
+ Thus, part 2 of a 3-part message may have either of the following
+ header fields:
+
+ Content-Type: Message/Partial;
+ number=2; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
+
+ Content-Type: Message/Partial;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
+ number=2
+
+ But part 3 MUST specify the total number of parts:
+
+ Content-Type: Message/Partial;
+ number=3; total=3;
+ id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
+
+ Note that part numbering begins with 1, not 0.
+
+ When the parts of a message broken up in this manner are put
+
+
+
+Borenstein & Freed [Page 39]
+
+RFC 1521 MIME September 1993
+
+
+ together, the result is a complete MIME entity, which may have its
+ own Content-Type header field, and thus may contain any other data
+ type.
+
+ Message fragmentation and reassembly: The semantics of a reassembled
+ partial message must be those of the "inner" message, rather than of
+ a message containing the inner message. This makes it possible, for
+ example, to send a large audio message as several partial messages,
+ and still have it appear to the recipient as a simple audio message
+ rather than as an encapsulated message containing an audio message.
+ That is, the encapsulation of the message is considered to be
+ "transparent".
+
+ When generating and reassembling the parts of a message/partial
+ message, the headers of the encapsulated message must be merged with
+ the headers of the enclosing entities. In this process the following
+ rules must be observed:
+
+ (1) All of the header fields from the initial enclosing entity
+ (part one), except those that start with "Content-" and the
+ specific header fields "Message-ID", "Encrypted", and "MIME-
+ Version", must be copied, in order, to the new message.
+
+ (2) Only those header fields in the enclosed message which start
+ with "Content-" and "Message-ID", "Encrypted", and "MIME-Version"
+ must be appended, in order, to the header fields of the new
+ message. Any header fields in the enclosed message which do not
+ start with "Content-" (except for "Message-ID", "Encrypted", and
+ "MIME-Version") will be ignored.
+
+ (3) All of the header fields from the second and any subsequent
+ messages will be ignored.
+
+ For example, if an audio message is broken into two parts, the first
+ part might look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ Message-ID: <id1@host.com>
+ MIME-Version: 1.0
+ Content-type: message/partial;
+ id="ABC@host.com";
+ number=1; total=2
+
+ X-Weird-Header-1: Bar
+ X-Weird-Header-2: Hello
+
+
+
+Borenstein & Freed [Page 40]
+
+RFC 1521 MIME September 1993
+
+
+ Message-ID: <anotherid@foo.com>
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+
+ and the second half might look something like this:
+
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ MIME-Version: 1.0
+ Message-ID: <id2@host.com>
+ Content-type: message/partial;
+ id="ABC@host.com"; number=2; total=2
+
+ ... second half of encoded audio data goes here...
+
+ Then, when the fragmented message is reassembled, the resulting
+ message to be displayed to the user should look something like this:
+
+ X-Weird-Header-1: Foo
+ From: Bill@host.com
+ To: joe@otherhost.com
+ Subject: Audio mail
+ Message-ID: <anotherid@foo.com>
+ MIME-Version: 1.0
+ Content-type: audio/basic
+ Content-transfer-encoding: base64
+
+ ... first half of encoded audio data goes here...
+ ... second half of encoded audio data goes here...
+
+ Note on encoding of MIME entities encapsulated inside message/partial
+ entities: Because data of type "message" may never be encoded in
+ base64 or quoted-printable, a problem might arise if message/partial
+ entities are constructed in an environment that supports binary or
+ 8-bit transport. The problem is that the binary data would be split
+ into multiple message/partial objects, each of them requiring binary
+ transport. If such objects were encountered at a gateway into a 7-
+ bit transport environment, there would be no way to properly encode
+ them for the 7-bit world, aside from waiting for all of the parts,
+ reassembling the message, and then encoding the reassembled data in
+ base64 or quoted-printable. Since it is possible that different
+ parts might go through different gateways, even this is not an
+ acceptable solution. For this reason, it is specified that MIME
+ entities of type message/partial must always have a content-
+
+
+
+Borenstein & Freed [Page 41]
+
+RFC 1521 MIME September 1993
+
+
+ transfer-encoding of 7-bit (the default). In particular, even in
+ environments that support binary or 8-bit transport, the use of a
+ content-transfer-encoding of "8bit" or "binary" is explicitly
+ prohibited for entities of type message/partial.
+
+ It should be noted that, because some message transfer agents may
+ choose to automatically fragment large messages, and because such
+ agents may use different fragmentation thresholds, it is possible
+ that the pieces of a partial message, upon reassembly, may prove
+ themselves to comprise a partial message. This is explicitly
+ permitted.
+
+ It should also be noted that the inclusion of a "References" field in
+ the headers of the second and subsequent pieces of a fragmented
+ message that references the Message-Id on the previous piece may be
+ of benefit to mail readers that understand and track references.
+ However, the generation of such "References" fields is entirely
+ optional.
+
+ Finally, it should be noted that the "Encrypted" header field has
+ been made obsolete by Privacy Enhanced Messaging (PEM), but the rules
+ above are believed to describe the correct way to treat it if it is
+ encountered in the context of conversion to and from message/partial
+ fragments.
+
+7.3.3. The Message/External-Body subtype
+
+ The external-body subtype indicates that the actual body data are not
+ included, but merely referenced. In this case, the parameters
+ describe a mechanism for accessing the external data.
+
+ When an entity is of type "message/external-body", it consists of a
+ header, two consecutive CRLFs, and the message header for the
+ encapsulated message. If another pair of consecutive CRLFs appears,
+ this of course ends the message header for the encapsulated message.
+ However, since the encapsulated message's body is itself external, it
+ does NOT appear in the area that follows. For example, consider the
+ following message:
+
+ Content-type: message/external-body; access-
+ type=local-file;
+
+ name="/u/nsb/Me.gif"
+
+ Content-type: image/gif
+ Content-ID: <id42@guppylake.bellcore.com>
+ Content-Transfer-Encoding: binary
+
+
+
+
+Borenstein & Freed [Page 42]
+
+RFC 1521 MIME September 1993
+
+
+ THIS IS NOT REALLY THE BODY!
+
+ The area at the end, which might be called the "phantom body", is
+ ignored for most external-body messages. However, it may be used to
+ contain auxiliary information for some such messages, as indeed it is
+ when the access-type is "mail-server". Of the access-types defined
+ by this document, the phantom body is used only when the access-type
+ is "mail-server". In all other cases, the phantom body is ignored.
+
+ The only always-mandatory parameter for message/external-body is
+ "access-type"; all of the other parameters may be mandatory or
+ optional depending on the value of access-type.
+
+ ACCESS-TYPE -- A case-insensitive word, indicating the supported
+ access mechanism by which the file or data may be obtained.
+ Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP",
+ "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for
+ experimental values beginning with "X-" must be registered with
+ IANA, as described in Appendix E .
+
+ In addition, the following three parameters are optional for ALL
+ access-types:
+
+ EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as
+ extended by RFC 1123 to permit 4 digits in the year field) after
+ which the existence of the external data is not guaranteed.
+
+ SIZE -- The size (in octets) of the data. The intent of this
+ parameter is to help the recipient decide whether or not to expend
+ the necessary resources to retrieve the external data. Note that
+ this describes the size of the data in its canonical form, that
+ is, before any Content- Transfer-Encoding has been applied or
+ after the data have been decoded.
+
+ PERMISSION -- A case-insensitive field that indicates whether or
+ not it is expected that clients might also attempt to overwrite
+ the data. By default, or if permission is "read", the assumption
+ is that they are not, and that if the data is retrieved once, it
+ is never needed again. If PERMISSION is "read-write", this
+ assumption is invalid, and any local copy must be considered no
+ more than a cache. "Read" and "Read-write" are the only defined
+ values of permission.
+
+ The precise semantics of the access-types defined here are described
+ in the sections that follow.
+
+ The encapsulated headers in ALL message/external-body entities MUST
+ include a Content-ID header field to give a unique identifier by
+
+
+
+Borenstein & Freed [Page 43]
+
+RFC 1521 MIME September 1993
+
+
+ which to reference the data. This identifier may be used for
+ cacheing mechanisms, and for recognizing the receipt of the data when
+ the access-type is "mail-server".
+
+ Note that, as specified here, the tokens that describe external-body
+ data, such as file names and mail server commands, are required to be
+ in the US-ASCII character set. If this proves problematic in
+ practice, a new mechanism may be required as a future extension to
+ MIME, either as newly defined access-types for message/external-body
+ or by some other mechanism.
+
+ As with message/partial, it is specified that MIME entities of type
+ message/external-body must always have a content-transfer-encoding of
+ 7-bit (the default). In particular, even in environments that
+ support binary or 8-bit transport, the use of a content-transfer-
+ encoding of "8bit" or "binary" is explicitly prohibited for entities
+ of type message/external-body.
+
+7.3.3.1. The "ftp" and "tftp" access-types
+
+ An access-type of FTP or TFTP indicates that the message body is
+ accessible as a file using the FTP [RFC-959] or TFTP [RFC-783]
+ protocols, respectively. For these access-types, the following
+ additional parameters are mandatory:
+
+ NAME -- The name of the file that contains the actual body data.
+
+ SITE -- A machine from which the file may be obtained, using the
+ given protocol. This must be a fully qualified domain name, not a
+ nickname.
+
+ Before any data are retrieved, using FTP, the user will generally
+ need to be asked to provide a login id and a password for the machine
+ named by the site parameter. For security reasons, such an id and
+ password are not specified as content-type parameters, but must be
+ obtained from the user.
+
+ In addition, the following parameters are optional:
+
+ DIRECTORY -- A directory from which the data named by NAME should
+ be retrieved.
+
+ MODE -- A case-insensitive string indicating the mode to be used
+ when retrieving the information. The legal values for access-type
+ "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the
+ TFTP protocol [RFC-783]. The legal values for access-type "FTP"
+ are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
+ decimal integer, typically 8. These correspond to the
+
+
+
+Borenstein & Freed [Page 44]
+
+RFC 1521 MIME September 1993
+
+
+ representation types "A" "E" "I" and "L n" as specified by the FTP
+ protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid
+ values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be
+ used instead. IF MODE is not specified, the default value is
+ "NETASCII" for TFTP and "ASCII" otherwise.
+
+7.3.3.2. The "anon-ftp" access-type
+
+ The "anon-ftp" access-type is identical to the "ftp" access type,
+ except that the user need not be asked to provide a name and password
+ for the specified site. Instead, the ftp protocol will be used with
+ login "anonymous" and a password that corresponds to the user's email
+ address.
+
+7.3.3.3. The "local-file" and "afs" access-types
+
+ An access-type of "local-file" indicates that the actual body is
+ accessible as a file on the local machine. An access-type of "afs"
+ indicates that the file is accessible via the global AFS file system.
+ In both cases, only a single parameter is required:
+
+ NAME -- The name of the file that contains the actual body data.
+
+ The following optional parameter may be used to describe the locality
+ of reference for the data, that is, the site or sites at which the
+ file is expected to be visible:
+
+ SITE -- A domain specifier for a machine or set of machines that
+ are known to have access to the data file. Asterisks may be used
+ for wildcard matching to a part of a domain name, such as
+ "*.bellcore.com", to indicate a set of machines on which the data
+ should be directly visible, while a single asterisk may be used to
+ indicate a file that is expected to be universally available,
+ e.g., via a global file system.
+
+7.3.3.4. The "mail-server" access-type
+
+ The "mail-server" access-type indicates that the actual body is
+ available from a mail server. The mandatory parameter for this
+ access-type is:
+
+ SERVER -- The email address of the mail server from which the
+ actual body data can be obtained.
+
+ Because mail servers accept a variety of syntaxes, some of which is
+ multiline, the full command to be sent to a mail server is not
+ included as a parameter on the content-type line. Instead, it is
+ provided as the "phantom body" when the content-type is
+
+
+
+Borenstein & Freed [Page 45]
+
+RFC 1521 MIME September 1993
+
+
+ message/external-body and the access- type is mail-server.
+
+ An optional parameter for this access-type is:
+
+ SUBJECT -- The subject that is to be used in the mail that is sent
+ to obtain the data. Note that keying mail servers on Subject lines
+ is NOT recommended, but such mail servers are known to exist.
+
+ Note that MIME does not define a mail server syntax. Rather, it
+ allows the inclusion of arbitrary mail server commands in the phantom
+ body. Implementations must include the phantom body in the body of
+ the message it sends to the mail server address to retrieve the
+ relevant data.
+
+ It is worth noting that, unlike other access-types, mail-server
+ access is asynchronous and will happen at an unpredictable time in
+ the future. For this reason, it is important that there be a
+ mechanism by which the returned data can be matched up with the
+ original message/external-body entity. MIME mailservers must use the
+ same Content-ID field on the returned message that was used in the
+ original message/external-body entity, to facilitate such matching.
+
+7.3.3.5. Examples and Further Explanations
+
+ With the emerging possibility of very wide-area file systems, it
+ becomes very hard to know in advance the set of machines where a file
+ will and will not be accessible directly from the file system.
+ Therefore it may make sense to provide both a file name, to be tried
+ directly, and the name of one or more sites from which the file is
+ known to be accessible. An implementation can try to retrieve remote
+ files using FTP or any other protocol, using anonymous file retrieval
+ or prompting the user for the necessary name and password. If an
+ external body is accessible via multiple mechanisms, the sender may
+ include multiple parts of type message/external-body within an entity
+ of type multipart/alternative.
+
+ However, the external-body mechanism is not intended to be limited to
+ file retrieval, as shown by the mail-server access-type. Beyond
+ this, one can imagine, for example, using a video server for external
+ references to video clips.
+
+ If an entity is of type "message/external-body", then the body of the
+ entity will contain the header fields of the encapsulated message.
+ The body itself is to be found in the external location. This means
+ that if the body of the "message/external-body" message contains two
+ consecutive CRLFs, everything after those pairs is NOT part of the
+ message itself. For most message/external-body messages, this
+ trailing area must simply be ignored. However, it is a convenient
+
+
+
+Borenstein & Freed [Page 46]
+
+RFC 1521 MIME September 1993
+
+
+ place for additional data that cannot be included in the content-type
+ header field. In particular, if the "access-type" value is "mail-
+ server", then the trailing area must contain commands to be sent to
+ the mail server at the address given by the value of the SERVER
+ parameter.
+
+ The embedded message header fields which appear in the body of the
+ message/external-body data must be used to declare the Content-type
+ of the external body if it is anything other than plain ASCII text,
+ since the external body does not have a header section to declare its
+ type. Similarly, any Content-transfer-encoding other than "7bit"
+ must also be declared here. Thus a complete message/external-body
+ message, referring to a document in PostScript format, might look
+ like this:
+
+ From: Whomever
+ To: Someone
+ Subject: whatever
+ MIME-Version: 1.0
+ Message-ID: <id1@host.com>
+ Content-Type: multipart/alternative; boundary=42
+ Content-ID: <id001@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body;
+ name="BodyFormats.ps";
+ site="thumper.bellcore.com";
+ access-type=ANON-FTP;
+ directory="pub";
+ mode="image";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body;
+ name="/u/nsb/writing/rfcs/RFC-MIME.ps";
+ site="thumper.bellcore.com";
+ access-type=AFS
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ --42
+ Content-Type: message/external-body;
+ access-type=mail-server
+
+
+
+Borenstein & Freed [Page 47]
+
+RFC 1521 MIME September 1993
+
+
+ server="listserv@bogus.bitnet";
+ expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
+
+ Content-type: application/postscript
+ Content-ID: <id42@guppylake.bellcore.com>
+
+ get RFC-MIME.DOC
+
+ --42--
+
+ Note that in the above examples, the default Content-transfer-
+ encoding of "7bit" is assumed for the external postscript data.
+
+ Like the message/partial type, the message/external-body type is
+ intended to be transparent, that is, to convey the data type in the
+ external body rather than to convey a message with a body of that
+ type. Thus the headers on the outer and inner parts must be merged
+ using the same rules as for message/partial. In particular, this
+ means that the Content-type header is overridden, but the From and
+ Subject headers are preserved.
+
+ Note that since the external bodies are not transported as mail, they
+ need not conform to the 7-bit and line length requirements, but might
+ in fact be binary files. Thus a Content-Transfer-Encoding is not
+ generally necessary, though it is permitted.
+
+ Note that the body of a message of type "message/external-body" is
+ governed by the basic syntax for an RFC 822 message. In particular,
+ anything before the first consecutive pair of CRLFs is header
+ information, while anything after it is body information, which is
+ ignored for most access-types.
+
+ The formal grammar for content-type header fields for data of type
+ message is given by:
+
+ message-type := "message" "/" message-subtype
+
+ message-subtype := "rfc822"
+ / "partial" 2#3partial-param
+ / "external-body" 1*external-param
+ / extension-token
+
+ partial-param := (";" "id" "=" value)
+ / (";" "number" "=" 1*DIGIT)
+ / (";" "total" "=" 1*DIGIT)
+ ; id & number required; total required for last part
+
+ external-param := (";" "access-type" "=" atype)
+
+
+
+Borenstein & Freed [Page 48]
+
+RFC 1521 MIME September 1993
+
+
+ / (";" "expiration" "=" date-time)
+ ; Note that date-time is quoted
+ / (";" "size" "=" 1*DIGIT)
+ / (";" "permission" "=" ("read" / "read-write"))
+ ; Permission is case-insensitive
+ / (";" "name" "=" value)
+ / (";" "site" "=" value)
+ / (";" "dir" "=" value)
+ / (";" "mode" "=" value)
+ / (";" "server" "=" value)
+ / (";" "subject" "=" value)
+ ; access-type required;others required based on access-type
+
+ atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
+ / "afs" / "mail-server" / extension-token
+ ; Case-insensitive
+
+7.4. The Application Content-Type
+
+ The "application" Content-Type is to be used for data which do not
+ fit in any of the other categories, and particularly for data to be
+ processed by mail-based uses of application programs. This is
+ information which must be processed by an application before it is
+ viewable or usable to a user. Expected uses for Content-Type
+ application include mail-based file transfer, spreadsheets, data for
+ mail-based scheduling systems, and languages for "active"
+ (computational) email. (The latter, in particular, can pose security
+ problems which must be understood by implementors, and are considered
+ in detail in the discussion of the application/PostScript content-
+ type.)
+
+ For example, a meeting scheduler might define a standard
+ representation for information about proposed meeting dates. An
+ intelligent user agent would use this information to conduct a dialog
+ with the user, and might then send further mail based on that dialog.
+ More generally, there have been several "active" messaging languages
+ developed in which programs in a suitably specialized language are
+ sent through the mail and automatically run in the recipient's
+ environment.
+
+ Such applications may be defined as subtypes of the "application"
+ Content-Type. This document defines two subtypes: octet-stream, and
+ PostScript.
+
+ In general, the subtype of application will often be the name of the
+ application for which the data are intended. This does not mean,
+ however, that any application program name may be used freely as a
+ subtype of application. Such usages (other than subtypes beginning
+
+
+
+Borenstein & Freed [Page 49]
+
+RFC 1521 MIME September 1993
+
+
+ with "x-") must be registered with IANA, as described in Appendix E.
+
+7.4.1. The Application/Octet-Stream (primary) subtype
+
+ The primary subtype of application, "octet-stream", may be used to
+ indicate that a body contains binary data. The set of possible
+ parameters includes, but is not limited to:
+
+ TYPE -- the general type or category of binary data. This is
+ intended as information for the human recipient rather than for
+ any automatic processing.
+
+ PADDING -- the number of bits of padding that were appended to the
+ bit-stream comprising the actual contents to produce the enclosed
+ byte-oriented data. This is useful for enclosing a bit-stream in
+ a body when the total number of bits is not a multiple of the byte
+ size.
+
+ An additional parameter, "conversions", was defined in [RFC-1341] but
+ has been removed.
+
+ RFC 1341 also defined the use of a "NAME" parameter which gave a
+ suggested file name to be used if the data were to be written to a
+ file. This has been deprecated in anticipation of a separate
+ Content-Disposition header field, to be defined in a subsequent RFC.
+
+ The recommended action for an implementation that receives
+ application/octet-stream mail is to simply offer to put the data in a
+ file, with any Content-Transfer-Encoding undone, or perhaps to use it
+ as input to a user-specified process.
+
+ To reduce the danger of transmitting rogue programs through the mail,
+ it is strongly recommended that implementations NOT implement a
+ path-search mechanism whereby an arbitrary program named in the
+ Content-Type parameter (e.g., an "interpreter=" parameter) is found
+ and executed using the mail body as input.
+
+7.4.2. The Application/PostScript subtype
+
+ A Content-Type of "application/postscript" indicates a PostScript
+ program. Currently two variants of the PostScript language are
+ allowed; the original level 1 variant is described in [POSTSCRIPT]
+ and the more recent level 2 variant is described in [POSTSCRIPT2].
+
+ PostScript is a registered trademark of Adobe Systems, Inc. Use of
+ the MIME content-type "application/postscript" implies recognition of
+ that trademark and all the rights it entails.
+
+
+
+
+Borenstein & Freed [Page 50]
+
+RFC 1521 MIME September 1993
+
+
+ The PostScript language definition provides facilities for internal
+ labeling of the specific language features a given program uses. This
+ labeling, called the PostScript document structuring conventions, is
+ very general and provides substantially more information than just
+ the language level.
+
+ The use of document structuring conventions, while not required, is
+ strongly recommended as an aid to interoperability. Documents which
+ lack proper structuring conventions cannot be tested to see whether
+ or not they will work in a given environment. As such, some systems
+ may assume the worst and refuse to process unstructured documents.
+
+ The execution of general-purpose PostScript interpreters entails
+ serious security risks, and implementors are discouraged from simply
+ sending PostScript email bodies to "off-the-shelf" interpreters.
+ While it is usually safe to send PostScript to a printer, where the
+ potential for harm is greatly constrained, implementors should
+ consider all of the following before they add interactive display of
+ PostScript bodies to their mail readers.
+
+ The remainder of this section outlines some, though probably not all,
+ of the possible problems with sending PostScript through the mail.
+
+ Dangerous operations in the PostScript language include, but may not
+ be limited to, the PostScript operators deletefile, renamefile,
+ filenameforall, and file. File is only dangerous when applied to
+ something other than standard input or output. Implementations may
+ also define additional nonstandard file operators; these may also
+ pose a threat to security. Filenameforall, the wildcard file search
+ operator, may appear at first glance to be harmless. Note, however,
+ that this operator has the potential to reveal information about what
+ files the recipient has access to, and this information may itself be
+ sensitive. Message senders should avoid the use of potentially
+ dangerous file operators, since these operators are quite likely to
+ be unavailable in secure PostScript implementations. Message-
+ receiving and -displaying software should either completely disable
+ all potentially dangerous file operators or take special care not to
+ delegate any special authority to their operation. These operators
+ should be viewed as being done by an outside agency when interpreting
+ PostScript documents. Such disabling and/or checking should be done
+ completely outside of the reach of the PostScript language itself;
+ care should be taken to insure that no method exists for re-enabling
+ full-function versions of these operators.
+
+ The PostScript language provides facilities for exiting the normal
+ interpreter, or server, loop. Changes made in this "outer"
+ environment are customarily retained across documents, and may in
+ some cases be retained semipermanently in nonvolatile memory. The
+
+
+
+Borenstein & Freed [Page 51]
+
+RFC 1521 MIME September 1993
+
+
+ operators associated with exiting the interpreter loop have the
+ potential to interfere with subsequent document processing. As such,
+ their unrestrained use constitutes a threat of service denial.
+ PostScript operators that exit the interpreter loop include, but may
+ not be limited to, the exitserver and startjob operators. Message-
+ sending software should not generate PostScript that depends on
+ exiting the interpreter loop to operate. The ability to exit will
+ probably be unavailable in secure PostScript implementations.
+ Message-receiving and -displaying software should, if possible,
+ disable the ability to make retained changes to the PostScript
+ environment, and eliminate the startjob and exitserver commands. If
+ these commands cannot be eliminated, the password associated with
+ them should at least be set to a hard-to-guess value.
+
+ PostScript provides operators for setting system-wide and device-
+ specific parameters. These parameter settings may be retained across
+ jobs and may potentially pose a threat to the correct operation of
+ the interpreter. The PostScript operators that set system and device
+ parameters include, but may not be limited to, the setsystemparams
+ and setdevparams operators. Message-sending software should not
+ generate PostScript that depends on the setting of system or device
+ parameters to operate correctly. The ability to set these parameters
+ will probably be unavailable in secure PostScript implementations.
+ Message-receiving and -displaying software should, if possible,
+ disable the ability to change system and device parameters. If these
+ operators cannot be disabled, the password associated with them
+ should at least be set to a hard-to-guess value.
+
+ Some PostScript implementations provide nonstandard facilities for
+ the direct loading and execution of machine code. Such facilities
+ are quite obviously open to substantial abuse. Message-sending
+ software should not make use of such features. Besides being totally
+ hardware- specific, they are also likely to be unavailable in secure
+ implementations of PostScript. Message-receiving and -displaying
+ software should not allow such operators to be used if they exist.
+
+ PostScript is an extensible language, and many, if not most,
+ implementations of it provide a number of their own extensions. This
+ document does not deal with such extensions explicitly since they
+ constitute an unknown factor. Message-sending software should not
+ make use of nonstandard extensions; they are likely to be missing
+ from some implementations. Message-receiving and -displaying software
+ should make sure that any nonstandard PostScript operators are secure
+ and don't present any kind of threat.
+
+ It is possible to write PostScript that consumes huge amounts of
+ various system resources. It is also possible to write PostScript
+ programs that loop infinitely. Both types of programs have the
+
+
+
+Borenstein & Freed [Page 52]
+
+RFC 1521 MIME September 1993
+
+
+ potential to cause damage if sent to unsuspecting recipients.
+ Message-sending software should avoid the construction and
+ dissemination of such programs, which is antisocial. Message-
+ receiving and -displaying software should provide appropriate
+ mechanisms to abort processing of a document after a reasonable
+ amount of time has elapsed. In addition, PostScript interpreters
+ should be limited to the consumption of only a reasonable amount of
+ any given system resource.
+
+ Finally, bugs may exist in some PostScript interpreters which could
+ possibly be exploited to gain unauthorized access to a recipient's
+ system. Apart from noting this possibility, there is no specific
+ action to take to prevent this, apart from the timely correction of
+ such bugs if any are found.
+
+7.4.3. Other Application subtypes
+
+ It is expected that many other subtypes of application will be
+ defined in the future. MIME implementations must generally treat any
+ unrecognized subtypes as being equivalent to application/octet-
+ stream.
+
+ The formal grammar for content-type header fields for application
+ data is given by:
+
+ application-type := "application" "/" application-subtype
+
+ application-subtype := ("octet-stream" *stream-param)
+ / "postscript" / extension-token
+
+ stream-param := (";" "type" "=" value)
+ / (";" "padding" "=" padding)
+
+ padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
+
+7.5. The Image Content-Type
+
+ A Content-Type of "image" indicates that the body contains an image.
+ The subtype names the specific image format. These names are case
+ insensitive. Two initial subtypes are "jpeg" for the JPEG format,
+ JFIF encoding, and "gif" for GIF format [GIF].
+
+ The list of image subtypes given here is neither exclusive nor
+ exhaustive, and is expected to grow as more types are registered with
+ IANA, as described in Appendix E.
+
+ The formal grammar for the content-type header field for data of type
+ image is given by:
+
+
+
+Borenstein & Freed [Page 53]
+
+RFC 1521 MIME September 1993
+
+
+ image-type := "image" "/" ("gif" / "jpeg" / extension-token)
+
+7.6. The Audio Content-Type
+
+ A Content-Type of "audio" indicates that the body contains audio
+ data. Although there is not yet a consensus on an "ideal" audio
+ format for use with computers, there is a pressing need for a format
+ capable of providing interoperable behavior.
+
+ The initial subtype of "basic" is specified to meet this requirement
+ by providing an absolutely minimal lowest common denominator audio
+ format. It is expected that richer formats for higher quality and/or
+ lower bandwidth audio will be defined by a later document.
+
+ The content of the "audio/basic" subtype is audio encoded using 8-bit
+ ISDN mu-law [PCM]. When this subtype is present, a sample rate of
+ 8000 Hz and a single channel is assumed.
+
+ The formal grammar for the content-type header field for data of type
+ audio is given by:
+
+ audio-type := "audio" "/" ("basic" / extension-token)
+
+7.7. The Video Content-Type
+
+ A Content-Type of "video" indicates that the body contains a time-
+ varying-picture image, possibly with color and coordinated sound.
+ The term "video" is used extremely generically, rather than with
+ reference to any particular technology or format, and is not meant to
+ preclude subtypes such as animated drawings encoded compactly. The
+ subtype "mpeg" refers to video coded according to the MPEG standard
+ [MPEG].
+
+ Note that although in general this document strongly discourages the
+ mixing of multiple media in a single body, it is recognized that many
+ so-called "video" formats include a representation for synchronized
+ audio, and this is explicitly permitted for subtypes of "video".
+
+ The formal grammar for the content-type header field for data of type
+ video is given by:
+
+ video-type := "video" "/" ("mpeg" / extension-token)
+
+7.8. Experimental Content-Type Values
+
+ A Content-Type value beginning with the characters "X-" is a private
+ value, to be used by consenting mail systems by mutual agreement.
+ Any format without a rigorous and public definition must be named
+
+
+
+Borenstein & Freed [Page 54]
+
+RFC 1521 MIME September 1993
+
+
+ with an "X-" prefix, and publicly specified values shall never begin
+ with "X-". (Older versions of the widely-used Andrew system use the
+ "X-BE2" name, so new systems should probably choose a different
+ name.)
+
+ In general, the use of "X-" top-level types is strongly discouraged.
+ Implementors should invent subtypes of the existing types whenever
+ possible. The invention of new types is intended to be restricted
+ primarily to the development of new media types for email, such as
+ digital odors or holography, and not for new data formats in general.
+ In many cases, a subtype of application will be more appropriate than
+ a new top-level type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 55]
+
+RFC 1521 MIME September 1993
+
+
+8. Summary
+
+ Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
+ header fields, it is possible to include, in a standardized way,
+ arbitrary types of data objects with RFC 822 conformant mail
+ messages. No restrictions imposed by either RFC 821 or RFC 822 are
+ violated, and care has been taken to avoid problems caused by
+ additional restrictions imposed by the characteristics of some
+ Internet mail transport mechanisms (see Appendix B). The "multipart"
+ and "message" Content-Types allow mixing and hierarchical structuring
+ of objects of different types in a single message. Further Content-
+ Types provide a standardized mechanism for tagging messages or body
+ parts as audio, image, or several other kinds of data. A
+ distinguished parameter syntax allows further specification of data
+ format details, particularly the specification of alternate character
+ sets. Additional optional header fields provide mechanisms for
+ certain extensions deemed desirable by many implementors. Finally, a
+ number of useful Content-Types are defined for general use by
+ consenting user agents, notably message/partial, and
+ message/external-body.
+
+9. Security Considerations
+
+ Security issues are discussed in Section 7.4.2 and in Appendix F.
+ Implementors should pay special attention to the security
+ implications of any mail content-types that can cause the remote
+ execution of any actions in the recipient's environment. In such
+ cases, the discussion of the application/postscript content-type in
+ Section 7.4.2 may serve as a model for considering other content-
+ types with remote execution capabilities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 56]
+
+RFC 1521 MIME September 1993
+
+
+10. Authors' Addresses
+
+ For more information, the authors of this document may be contacted
+ via Internet mail:
+
+ Nathaniel S. Borenstein
+ MRE 2D-296, Bellcore
+ 445 South St.
+ Morristown, NJ 07962-1910
+
+ Phone: +1 201 829 4270
+ Fax: +1 201 829 7019
+ Email: nsb@bellcore.com
+
+
+ Ned Freed
+ Innosoft International, Inc.
+ 250 West First Street
+ Suite 240
+ Claremont, CA 91711
+
+ Phone: +1 909 624 7907
+ Fax: +1 909 621 5319
+ Email: ned@innosoft.com
+
+ MIME is a result of the work of the Internet Engineering Task Force
+ Working Group on Email Extensions. The chairman of that group, Greg
+ Vaudreuil, may be reached at:
+
+ Gregory M. Vaudreuil
+ Tigon Corporation
+ 17060 Dallas Parkway
+ Dallas Texas, 75248
+
+ Phone: +1 214-733-2722
+ EMail: gvaudre@cnri.reston.va.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 57]
+
+RFC 1521 MIME September 1993
+
+
+11. Acknowledgements
+
+ This document is the result of the collective effort of a large
+ number of people, at several IETF meetings, on the IETF-SMTP and
+ IETF-822 mailing lists, and elsewhere. Although any enumeration
+ seems doomed to suffer from egregious omissions, the following are
+ among the many contributors to this effort:
+
+ Harald Tveit Alvestrand Timo Lehtinen
+ Randall Atkinson John R. MacMillan
+ Philippe Brandon Rick McGowan
+ Kevin Carosso Leo Mclaughlin
+ Uhhyung Choi Goli Montaser-Kohsari
+ Cristian Constantinof Keith Moore
+ Mark Crispin Tom Moore
+ Dave Crocker Erik Naggum
+ Terry Crowley Mark Needleman
+ Walt Daniels John Noerenberg
+ Frank Dawson Mats Ohrman
+ Hitoshi Doi Julian Onions
+ Kevin Donnelly Michael Patton
+ Keith Edwards David J. Pepper
+ Chris Eich Blake C. Ramsdell
+ Johnny Eriksson Luc Rooijakkers
+ Craig Everhart Marshall T. Rose
+ Patrik Faeltstroem Jonathan Rosenberg
+ Erik E. Fair Jan Rynning
+ Roger Fajman Harri Salminen
+ Alain Fontaine Michael Sanderson
+ James M. Galvin Masahiro Sekiguchi
+ Philip Gladstone Mark Sherman
+ Thomas Gordon Keld Simonsen
+ Phill Gross Bob Smart
+ James Hamilton Peter Speck
+ Steve Hardcastle-Kille Henry Spencer
+ David Herron Einar Stefferud
+ Bruce Howard Michael Stein
+ Bill Janssen Klaus Steinberger
+ Olle Jaernefors Peter Svanberg
+ Risto Kankkunen James Thompson
+ Phil Karn Steve Uhler
+ Alan Katz Stuart Vance
+ Tim Kehres Erik van der Poel
+ Neil Katin Guido van Rossum
+ Kyuho Kim Peter Vanderbilt
+ Anders Klemets Greg Vaudreuil
+ John Klensin Ed Vielmetti
+ Valdis Kletniek Ryan Waldron
+
+
+
+Borenstein & Freed [Page 58]
+
+RFC 1521 MIME September 1993
+
+
+ Jim Knowles Wally Wedel
+ Stev Knowles Sven-Ove Westberg
+ Bob Kummerfeld Brian Wideen
+ Pekka Kytolaakso John Wobus
+ Stellan Lagerstrom Glenn Wright
+ Vincent Lau Rayan Zachariassen
+ Donald Lindsay David Zimmerman
+ Marc Andreessen Bob Braden
+ Brian Capouch Peter Clitherow
+ Dave Collier-Brown John Coonrod
+ Stephen Crocker Jim Davis
+ Axel Deininger Dana S Emery
+ Martin Forssen Stephen Gildea
+ Terry Gray Mark Horton
+ Warner Losh Carlyn Lowery
+ Laurence Lundblade Charles Lynn
+ Larry Masinter Michael J. McInerny
+ Jon Postel Christer Romson
+ Yutaka Sato Markku Savela
+ Richard Alan Schafer Larry W. Virden
+ Rhys Weatherly Jay Weber
+ Dave Wecker
+
+The authors apologize for any omissions from this list, which are
+certainly unintentional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 59]
+
+RFC 1521 MIME September 1993
+
+
+Appendix A -- Minimal MIME-Conformance
+
+ The mechanisms described in this document are open-ended. It is
+ definitely not expected that all implementations will support all of
+ the Content-Types described, nor that they will all share the same
+ extensions. In order to promote interoperability, however, it is
+ useful to define the concept of "MIME-conformance" to define a
+ certain level of implementation that allows the useful interworking
+ of messages with content that differs from US ASCII text. In this
+ section, we specify the requirements for such conformance.
+
+ A mail user agent that is MIME-conformant MUST:
+
+ 1. Always generate a "MIME-Version: 1.0" header field.
+
+ 2. Recognize the Content-Transfer-Encoding header field, and
+ decode all received data encoded with either the quoted-printable
+ or base64 implementations. Encode any data sent that is not in
+ seven-bit mail-ready representation using one of these
+ transformations and include the appropriate Content-Transfer-
+ Encoding header field, unless the underlying transport mechanism
+ supports non-seven-bit data, as SMTP does not.
+
+ 3. Recognize and interpret the Content-Type header field, and
+ avoid showing users raw data with a Content-Type field other than
+ text. Be able to send at least text/plain messages, with the
+ character set specified as a parameter if it is not US-ASCII.
+
+ 4. Explicitly handle the following Content-Type values, to at
+ least the following extents:
+
+ Text:
+
+ -- Recognize and display "text" mail
+ with the character set "US-ASCII."
+
+ -- Recognize other character sets at
+ least to the extent of being able
+ to inform the user about what
+ character set the message uses.
+
+ -- Recognize the "ISO-8859-*" character
+ sets to the extent of being able to
+ display those characters that are
+ common to ISO-8859-* and US-ASCII,
+ namely all characters represented
+ by octet values 0-127.
+
+
+
+
+Borenstein & Freed [Page 60]
+
+RFC 1521 MIME September 1993
+
+
+ -- For unrecognized subtypes, show or
+ offer to show the user the "raw"
+ version of the data after
+ conversion of the content from
+ canonical form to local form.
+
+ Message:
+
+ -- Recognize and display at least the
+ primary (822) encapsulation.
+
+ Multipart:
+
+ -- Recognize the primary (mixed)
+ subtype. Display all relevant
+ information on the message level
+ and the body part header level and
+ then display or offer to display
+ each of the body parts individually.
+
+ -- Recognize the "alternative" subtype,
+ and avoid showing the user
+ redundant parts of
+ multipart/alternative mail.
+
+ -- Treat any unrecognized subtypes as if
+ they were "mixed".
+
+ Application:
+
+ -- Offer the ability to remove either of
+ the two types of Content-Transfer-
+ Encoding defined in this document
+ and put the resulting information
+ in a user file.
+
+ 5. Upon encountering any unrecognized Content- Type, an
+ implementation must treat it as if it had a Content-Type of
+ "application/octet-stream" with no parameter sub-arguments. How
+ such data are handled is up to an implementation, but likely
+ options for handling such unrecognized data include offering the
+ user to write it into a file (decoded from its mail transport
+ format) or offering the user to name a program to which the
+ decoded data should be passed as input. Unrecognized predefined
+ types, which in a MIME-conformant mailer might still include
+ audio, image, or video, should also be treated in this way.
+
+ A user agent that meets the above conditions is said to be MIME-
+
+
+
+Borenstein & Freed [Page 61]
+
+RFC 1521 MIME September 1993
+
+
+ conformant. The meaning of this phrase is that it is assumed to be
+ "safe" to send virtually any kind of properly-marked data to users of
+ such mail systems, because such systems will at least be able to
+ treat the data as undifferentiated binary, and will not simply splash
+ it onto the screen of unsuspecting users. There is another sense in
+ which it is always "safe" to send data in a format that is MIME-
+ conformant, which is that such data will not break or be broken by
+ any known systems that are conformant with RFC 821 and RFC 822. User
+ agents that are MIME-conformant have the additional guarantee that
+ the user will not be shown data that were never intended to be viewed
+ as text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 62]
+
+RFC 1521 MIME September 1993
+
+
+Appendix B -- General Guidelines For Sending Email Data
+
+ Internet email is not a perfect, homogeneous system. Mail may become
+ corrupted at several stages in its travel to a final destination.
+ Specifically, email sent throughout the Internet may travel across
+ many networking technologies. Many networking and mail technologies
+ do not support the full functionality possible in the SMTP transport
+ environment. Mail traversing these systems is likely to be modified
+ in such a way that it can be transported.
+
+ There exist many widely-deployed non-conformant MTAs in the Internet.
+ These MTAs, speaking the SMTP protocol, alter messages on the fly to
+ take advantage of the internal data structure of the hosts they are
+ implemented on, or are just plain broken.
+
+ The following guidelines may be useful to anyone devising a data
+ format (Content-Type) that will survive the widest range of
+ networking technologies and known broken MTAs unscathed. Note that
+ anything encoded in the base64 encoding will satisfy these rules, but
+ that some well-known mechanisms, notably the UNIX uuencode facility,
+ will not. Note also that anything encoded in the Quoted-Printable
+ encoding will survive most gateways intact, but possibly not some
+ gateways to systems that use the EBCDIC character set.
+
+ (1) Under some circumstances the encoding used for data may change
+ as part of normal gateway or user agent operation. In particular,
+ conversion from base64 to quoted-printable and vice versa may be
+ necessary. This may result in the confusion of CRLF sequences with
+ line breaks in text bodies. As such, the persistence of CRLF as
+ something other than a line break must not be relied on.
+
+ (2) Many systems may elect to represent and store text data using
+ local newline conventions. Local newline conventions may not match
+ the RFC822 CRLF convention -- systems are known that use plain CR,
+ plain LF, CRLF, or counted records. The result is that isolated
+ CR and LF characters are not well tolerated in general; they may
+ be lost or converted to delimiters on some systems, and hence must
+ not be relied on.
+
+ (3) TAB (HT) characters may be misinterpreted or may be
+ automatically converted to variable numbers of spaces. This is
+ unavoidable in some environments, notably those not based on the
+ ASCII character set. Such conversion is STRONGLY DISCOURAGED, but
+ it may occur, and mail formats must not rely on the persistence of
+ TAB (HT) characters.
+
+ (4) Lines longer than 76 characters may be wrapped or truncated in
+ some environments. Line wrapping and line truncation are STRONGLY
+
+
+
+Borenstein & Freed [Page 63]
+
+RFC 1521 MIME September 1993
+
+
+ DISCOURAGED, but unavoidable in some cases. Applications which
+ require long lines must somehow differentiate between soft and
+ hard line breaks. (A simple way to do this is to use the quoted-
+ printable encoding.)
+
+ (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line
+ may be discarded by some transport agents, while other transport
+ agents may pad lines with these characters so that all lines in a
+ mail file are of equal length. The persistence of trailing white
+ space, therefore, must not be relied on.
+
+ (6) Many mail domains use variations on the ASCII character set,
+ or use character sets such as EBCDIC which contain most but not
+ all of the US-ASCII characters. The correct translation of
+ characters not in the "invariant" set cannot be depended on across
+ character converting gateways. For example, this situation is a
+ problem when sending uuencoded information across BITNET, an
+ EBCDIC system. Similar problems can occur without crossing a
+ gateway, since many Internet hosts use character sets other than
+ ASCII internally. The definition of Printable Strings in X.400
+ adds further restrictions in certain special cases. In
+ particular, the only characters that are known to be consistent
+ across all gateways are the 73 characters that correspond to the
+ upper and lower case letters A-Z and a-z, the 10 digits 0-9, and
+ the following eleven special characters:
+
+ "'" (ASCII code 39)
+ "(" (ASCII code 40)
+ ")" (ASCII code 41)
+ "+" (ASCII code 43)
+ "," (ASCII code 44)
+ "-" (ASCII code 45)
+ "." (ASCII code 46)
+ "/" (ASCII code 47)
+ ":" (ASCII code 58)
+ "=" (ASCII code 61)
+ "?" (ASCII code 63)
+
+ A maximally portable mail representation, such as the base64
+ encoding, will confine itself to relatively short lines of text in
+ which the only meaningful characters are taken from this set of 73
+ characters.
+
+ (7) Some mail transport agents will corrupt data that includes
+ certain literal strings. In particular, a period (".") alone on a
+ line is known to be corrupted by some (incorrect) SMTP
+ implementations, and a line that starts with the five characters
+ "From " (the fifth character is a SPACE) are commonly corrupted as
+
+
+
+Borenstein & Freed [Page 64]
+
+RFC 1521 MIME September 1993
+
+
+ well. A careful composition agent can prevent these corruptions
+ by encoding the data (e.g., in the quoted-printable encoding,
+ "=46rom " in place of "From " at the start of a line, and "=2E" in
+ place of "." alone on a line.
+
+ Please note that the above list is NOT a list of recommended
+ practices for MTAs. RFC 821 MTAs are prohibited from altering the
+ character of white space or wrapping long lines. These BAD and
+ illegal practices are known to occur on established networks, and
+ implementations should be robust in dealing with the bad effects they
+ can cause.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 65]
+
+RFC 1521 MIME September 1993
+
+
+Appendix C -- A Complex Multipart Example
+
+ What follows is the outline of a complex multipart message. This
+ message has five parts to be displayed serially: two introductory
+ plain text parts, an embedded multipart message, a richtext part, and
+ a closing encapsulated text message in a non-ASCII character set.
+ The embedded multipart message has two parts to be displayed in
+ parallel, a picture and an audio fragment.
+
+ MIME-Version: 1.0
+ From: Nathaniel Borenstein <nsb@bellcore.com>
+ To: Ned Freed <ned@innosoft.com>
+ Subject: A multipart example
+ Content-Type: multipart/mixed;
+ boundary=unique-boundary-1
+
+ This is the preamble area of a multipart message.
+ Mail readers that understand multipart format
+ should ignore this preamble.
+ If you are reading this text, you might want to
+ consider changing to a mail reader that understands
+ how to properly display multipart messages.
+ --unique-boundary-1
+
+ ...Some text appears here...
+ [Note that the preceding blank line means
+ no header fields were given and this is text,
+ with charset US ASCII. It could have been
+ done with explicit typing as in the next part.]
+
+ --unique-boundary-1
+ Content-type: text/plain; charset=US-ASCII
+
+ This could have been part of the previous part,
+ but illustrates explicit versus implicit
+ typing of body parts.
+
+ --unique-boundary-1
+ Content-Type: multipart/parallel;
+ boundary=unique-boundary-2
+
+
+ --unique-boundary-2
+ Content-Type: audio/basic
+ Content-Transfer-Encoding: base64
+
+ ... base64-encoded 8000 Hz single-channel
+ mu-law-format audio data goes here....
+
+
+
+Borenstein & Freed [Page 66]
+
+RFC 1521 MIME September 1993
+
+
+ --unique-boundary-2
+ Content-Type: image/gif
+ Content-Transfer-Encoding: base64
+
+ ... base64-encoded image data goes here....
+
+ --unique-boundary-2--
+
+ --unique-boundary-1
+ Content-type: text/richtext
+
+ This is <bold><italic>richtext.</italic></bold>
+ <smaller>as defined in RFC 1341</smaller>
+ <nl><nl>Isn't it
+ <bigger><bigger>cool?</bigger></bigger>
+
+ --unique-boundary-1
+ Content-Type: message/rfc822
+
+ From: (mailbox in US-ASCII)
+ To: (address in US-ASCII)
+ Subject: (subject in US-ASCII)
+ Content-Type: Text/plain; charset=ISO-8859-1
+ Content-Transfer-Encoding: Quoted-printable
+
+ ... Additional text in ISO-8859-1 goes here ...
+
+ --unique-boundary-1--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 67]
+
+RFC 1521 MIME September 1993
+
+
+Appendix D -- Collected Grammar
+
+ This appendix contains the complete BNF grammar for all the syntax
+ specified by this document.
+
+ By itself, however, this grammar is incomplete. It refers to several
+ entities that are defined by RFC 822. Rather than reproduce those
+ definitions here, and risk unintentional differences between the two,
+ this document simply refers the reader to RFC 822 for the remaining
+ definitions. Wherever a term is undefined, it refers to the RFC 822
+ definition.
+
+ application-subtype := ("octet-stream" *stream-param)
+ / "postscript" / extension-token
+
+ application-type := "application" "/" application-subtype
+
+ attribute := token ; case-insensitive
+
+ atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
+ / "afs" / "mail-server" / extension-token
+ ; Case-insensitive
+
+ audio-type := "audio" "/" ("basic" / extension-token)
+
+ body-part := <"message" as defined in RFC 822,
+ with all header fields optional, and with the
+ specified delimiter not occurring anywhere in
+ the message body, either on a line by itself
+ or as a substring anywhere.>
+
+ NOTE: In certain transport enclaves, RFC 822 restrictions such as
+ the one that limits bodies to printable ASCII characters may not
+ be in force. (That is, the transport domains may resemble
+ standard Internet mail transport as specified in RFC821 and
+ assumed by RFC822, but without certain restrictions.) The
+ relaxation of these restrictions should be construed as locally
+ extending the definition of bodies, for example to include octets
+ outside of the ASCII range, as long as these extensions are
+ supported by the transport and adequately documented in the
+ Content-Transfer-Encoding header field. However, in no event are
+ headers (either message headers or body-part headers) allowed to
+ contain anything other than ASCII characters.
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 68]
+
+RFC 1521 MIME September 1993
+
+
+ boundary := 0*69<bchars> bcharsnospace
+
+ bchars := bcharsnospace / " "
+
+ bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_"
+ / "," / "-" / "." / "/" / ":" / "=" / "?"
+
+ charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3"
+ / "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7"
+ / "iso-8859-8" / "iso-8859-9" / extension-token
+ ; case insensitive
+
+ close-delimiter := "--" boundary "--" CRLF;Again,no space by "--",
+
+ content := "Content-Type" ":" type "/" subtype *(";" parameter)
+ ; case-insensitive matching of type and subtype
+
+ delimiter := "--" boundary CRLF ;taken from Content-Type field.
+ ; There must be no space
+ ; between "--" and boundary.
+
+ description := "Content-Description" ":" *text
+
+ discard-text := *(*text CRLF)
+
+ encapsulation := delimiter body-part CRLF
+
+ encoding := "Content-Transfer-Encoding" ":" mechanism
+
+ epilogue := discard-text ; to be ignored upon receipt.
+
+ extension-token := x-token / iana-token
+
+ external-param := (";" "access-type" "=" atype)
+ / (";" "expiration" "=" date-time)
+
+ ; Note that date-time is quoted
+ / (";" "size" "=" 1*DIGIT)
+ / (";" "permission" "=" ("read" / "read-write"))
+ ; Permission is case-insensitive
+ / (";" "name" "=" value)
+ / (";" "site" "=" value)
+ / (";" "dir" "=" value)
+ / (";" "mode" "=" value)
+ / (";" "server" "=" value)
+ / (";" "subject" "=" value)
+ ;access-type required; others required based on access-type
+
+
+
+
+Borenstein & Freed [Page 69]
+
+RFC 1521 MIME September 1993
+
+
+ iana-token := <a publicly-defined extension token,
+ registered with IANA, as specified in
+ appendix E>
+
+ id := "Content-ID" ":" msg-id
+
+ image-type := "image" "/" ("gif" / "jpeg" / extension-token)
+
+ mechanism := "7bit" ; case-insensitive
+ / "quoted-printable"
+ / "base64"
+ / "8bit"
+ / "binary"
+ / x-token
+
+ message-subtype := "rfc822"
+ / "partial" 2#3partial-param
+ / "external-body" 1*external-param
+ / extension-token
+
+ message-type := "message" "/" message-subtype
+
+ multipart-body :=preamble 1*encapsulation close-delimiter epilogue
+
+ multipart-subtype := "mixed" / "parallel" / "digest"
+ / "alternative" / extension-token
+
+ multipart-type := "multipart" "/" multipart-subtype
+ ";" "boundary" "=" boundary
+
+ octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
+ ; octet must be used for characters > 127, =, SPACE, or
+ TAB,
+ ; and is recommended for any characters not listed in
+ ; Appendix B as "mail-safe".
+
+ padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
+
+ parameter := attribute "=" value
+
+ partial-param := (";" "id" "=" value)
+ / (";" "number" "=" 1*DIGIT)
+ / (";" "total" "=" 1*DIGIT)
+ ; id & number required;total required for last part
+
+ preamble := discard-text ; to be ignored upon receipt.
+
+ ptext := octet / <any ASCII character except "=", SPACE, or TAB>
+
+
+
+Borenstein & Freed [Page 70]
+
+RFC 1521 MIME September 1993
+
+
+ ; characters not listed as "mail-safe" in Appendix B
+ ; are also not recommended.
+
+ quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
+ ; Maximum line length of 76 characters excluding CRLF
+
+ stream-param := (";" "type" "=" value)
+ / (";" "padding" "=" padding)
+
+ subtype := token ; case-insensitive
+
+ text-subtype := "plain" / extension-token
+
+ text-type := "text" "/" text-subtype [";" "charset" "=" charset]
+
+ token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
+
+ tspecials := "(" / ")" / "<" / ">" / "@"
+ / "," / ";" / ":" / "\" / <">
+ / "/" / "[" / "]" / "?" / "="
+ ; Must be in quoted-string,
+ ; to use within parameter values
+
+
+ type := "application" / "audio" ; case-insensitive
+ / "image" / "message"
+ / "multipart" / "text"
+ / "video" / extension-token
+ ; All values case-insensitive
+
+ value := token / quoted-string
+
+ version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ video-type := "video" "/" ("mpeg" / extension-token)
+
+ x-token := <The two characters "X-" or "x-" followed, with no
+ intervening white space, by any token>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 71]
+
+RFC 1521 MIME September 1993
+
+
+Appendix E -- IANA Registration Procedures
+
+ MIME has been carefully designed to have extensible mechanisms, and
+ it is expected that the set of content-type/subtype pairs and their
+ associated parameters will grow significantly with time. Several
+ other MIME fields, notably character set names, access-type
+ parameters for the message/external-body type, and possibly even
+ Content-Transfer-Encoding values, are likely to have new values
+ defined over time. In order to ensure that the set of such values is
+ developed in an orderly, well-specified, and public manner, MIME
+ defines a registration process which uses the Internet Assigned
+ Numbers Authority (IANA) as a central registry for such values.
+
+ In general, parameters in the content-type header field are used to
+ convey supplemental information for various content types, and their
+ use is defined when the content-type and subtype are defined. New
+ parameters should not be defined as a way to introduce new
+ functionality.
+
+ In order to simplify and standardize the registration process, this
+ appendix gives templates for the registration of new values with
+ IANA. Each of these is given in the form of an email message
+ template, to be filled in by the registering party.
+
+ E.1 Registration of New Content-type/subtype Values
+
+ Note that MIME is generally expected to be extended by subtypes. If
+ a new fundamental top-level type is needed, its specification must be
+ published as an RFC or submitted in a form suitable to become an RFC,
+ and be subject to the Internet standards process.
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME
+ content-type/subtype
+
+ MIME type name:
+
+ (If the above is not an existing top-level MIME type,
+ please explain why an existing type cannot be used.)
+
+ MIME subtype name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Encoding considerations:
+
+
+
+
+Borenstein & Freed [Page 72]
+
+RFC 1521 MIME September 1993
+
+
+ Security considerations:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be if a new top-level type is being defined, and
+ must be a publicly available specification in any
+ case.)
+
+ Person & email address to contact for further information:
+
+ E.2 Registration of New Access-type Values
+ for Message/external-body
+
+ To: IANA@isi.edu
+ Subject: Registration of new MIME Access-type for
+ Message/external-body content-type
+
+ MIME access-type name:
+
+ Required parameters:
+
+ Optional parameters:
+
+ Published specification:
+
+ (The published specification must be an Internet RFC or
+ RFC-to-be.)
+
+ Person & email address to contact for further information:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 73]
+
+RFC 1521 MIME September 1993
+
+
+Appendix F -- Summary of the Seven Content-types
+
+ Content-type: text
+
+ Subtypes defined by this document: plain
+
+ Important Parameters: charset
+
+ Encoding notes: quoted-printable generally preferred if an encoding
+ is needed and the character set is mostly an ASCII superset.
+
+ Security considerations: Rich text formats such as TeX and Troff
+ often contain mechanisms for executing arbitrary commands or file
+ system operations, and should not be used automatically unless
+ these security problems have been addressed. Even plain text may
+ contain control characters that can be used to exploit the
+ capabilities of "intelligent" terminals and cause security
+ violations. User interfaces designed to run on such terminals
+ should be aware of and try to prevent such problems.
+
+ ________________________________________________________
+ Content-type: multipart
+
+ Subtypes defined by this document: mixed, alternative,
+ digest, parallel.
+
+ Important Parameters: boundary
+
+ Encoding notes: No content-transfer-encoding is permitted.
+
+ ________________________________________________________
+ Content-type: message
+
+ Subtypes defined by this document: rfc822, partial, external-body
+
+ Important Parameters: id, number, total, access-type, expiration,
+ size, permission, name, site, directory, mode, server, subject
+
+ Encoding notes: No content-transfer-encoding is permitted.
+ Specifically, only "7bit" is permitted for "message/partial" or
+ "message/external-body", and only "7bit", "8bit", or "binary" are
+ permitted for other subtypes of "message".
+ ______________________________________________________________
+ Content-type: application
+
+ Subtypes defined by this document: octet-stream, postscript
+
+ Important Parameters: type, padding
+
+
+
+Borenstein & Freed [Page 74]
+
+RFC 1521 MIME September 1993
+
+
+ Deprecated Parameters: name and conversions were
+ defined in RFC 1341.
+
+ Encoding notes: base64 preferred for unreadable subtypes.
+
+ Security considerations: This type is intended for the
+ transmission of data to be interpreted by locally-installed
+ programs. If used, for example, to transmit executable
+ binary programs or programs in general-purpose interpreted
+ languages, such as LISP programs or shell scripts, severe
+ security problems could result. Authors of mail-reading
+ agents are cautioned against giving their systems the power
+ to execute mail-based application data without carefully
+ considering the security implications. While it is
+ certainly possible to define safe application formats and
+ even safe interpreters for unsafe formats, each interpreter
+ should be evaluated separately for possible security
+ problems.
+ ________________________________________________________________
+ Content-type: image
+
+ Subtypes defined by this document: jpeg, gif
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+ ________________________________________________________________
+ Content-type: audio
+
+ Subtypes defined by this document: basic
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+ ________________________________________________________________
+ Content-type: video
+
+ Subtypes defined by this document: mpeg
+
+ Important Parameters: none
+
+ Encoding notes: base64 generally preferred
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 75]
+
+RFC 1521 MIME September 1993
+
+
+Appendix G -- Canonical Encoding Model
+
+ There was some confusion, in earlier drafts of this memo, regarding
+ the model for when email data was to be converted to canonical form
+ and encoded, and in particular how this process would affect the
+ treatment of CRLFs, given that the representation of newlines varies
+ greatly from system to system. For this reason, a canonical model
+ for encoding is presented below.
+
+ The process of composing a MIME entity can be modeled as being done
+ in a number of steps. Note that these steps are roughly similar to
+ those steps used in RFC 1421 and are performed for each 'innermost
+ level' body:
+
+ Step 1. Creation of local form.
+
+ The body to be transmitted is created in the system's native format.
+ The native character set is used, and where appropriate local end of
+ line conventions are used as well. The body may be a UNIX-style text
+ file, or a Sun raster image, or a VMS indexed file, or audio data in
+ a system-dependent format stored only in memory, or anything else
+ that corresponds to the local model for the representation of some
+ form of information. Fundamentally, the data is created in the
+ "native" form specified by the type/subtype information.
+
+ Step 2. Conversion to canonical form.
+
+ The entire body, including "out-of-band" information such as record
+ lengths and possibly file attribute information, is converted to a
+ universal canonical form. The specific content type of the body as
+ well as its associated attributes dictate the nature of the canonical
+ form that is used. Conversion to the proper canonical form may
+ involve character set conversion, transformation of audio data,
+ compression, or various other operations specific to the various
+ content types. If character set conversion is involved, however,
+ care must be taken to understand the semantics of the content-type,
+ which may have strong implications for any character set conversion,
+ e.g. with regard to syntactically meaningful characters in a text
+ subtype other than "plain".
+
+ For example, in the case of text/plain data, the text must be
+ converted to a supported character set and lines must be delimited
+ with CRLF delimiters in accordance with RFC822. Note that the
+ restriction on line lengths implied by RFC822 is eliminated if the
+ next step employs either quoted-printable or base64 encoding.
+
+
+
+
+
+
+Borenstein & Freed [Page 76]
+
+RFC 1521 MIME September 1993
+
+
+ Step 3. Apply transfer encoding.
+
+ A Content-Transfer-Encoding appropriate for this body is applied.
+ Note that there is no fixed relationship between the content type and
+ the transfer encoding. In particular, it may be appropriate to base
+ the choice of base64 or quoted-printable on character frequency
+ counts which are specific to a given instance of a body.
+
+ Step 4. Insertion into entity.
+
+ The encoded object is inserted into a MIME entity with appropriate
+ headers. The entity is then inserted into the body of a higher-level
+ entity (message or multipart) if needed.
+
+ It is vital to note that these steps are only a model; they are
+ specifically NOT a blueprint for how an actual system would be built.
+ In particular, the model fails to account for two common designs:
+
+ 1. In many cases the conversion to a canonical form prior to
+ encoding will be subsumed into the encoder itself, which
+ understands local formats directly. For example, the local
+ newline convention for text bodies might be carried through to the
+ encoder itself along with knowledge of what that format is.
+
+ 2. The output of the encoders may have to pass through one or
+ more additional steps prior to being transmitted as a message. As
+ such, the output of the encoder may not be conformant with the
+ formats specified by RFC822. In particular, once again it may be
+ appropriate for the converter's output to be expressed using local
+ newline conventions rather than using the standard RFC822 CRLF
+ delimiters.
+
+ Other implementation variations are conceivable as well. The vital
+ aspect of this discussion is that, in spite of any optimizations,
+ collapsings of required steps, or insertion of additional processing,
+ the resulting messages must be consistent with those produced by the
+ model described here. For example, a message with the following
+ header fields:
+
+ Content-type: text/foo; charset=bar
+ Content-Transfer-Encoding: base64
+
+ must be first represented in the text/foo form, then (if necessary)
+ represented in the "bar" character set, and finally transformed via
+ the base64 algorithm into a mail-safe form.
+
+
+
+
+
+
+Borenstein & Freed [Page 77]
+
+RFC 1521 MIME September 1993
+
+
+Appendix H -- Changes from RFC 1341
+
+ This document is a relatively minor revision of RFC 1341. For
+ the convenience of those familiar with RFC 1341, the technical
+ changes from that document are summarized in this appendix.
+
+ 1. The definition of "tspecials" has been changed to no longer
+ include ".".
+
+ 2. The Content-ID field is now mandatory for message/external-body
+ parts.
+
+ 3. The text/richtext type (including the old Section 7.1.3 and
+ Appendix D) has been moved to a separate document.
+
+ 4. The rules on header merging for message/partial data have been
+ changed to treat the Encrypted and MIME-Version headers as special
+ cases.
+
+ 5. The definition of the external-body access-type parameter has
+ been changed so that it can only indicate a single access method
+ (which was all that made sense).
+
+ 6. There is a new "Subject" parameter for message/external-body,
+ access-type mail-server, to permit MIME-based use of mail servers
+ that rely on Subject field information.
+
+ 7. The "conversions" parameter for application/octet-stream has been
+ removed.
+
+ 8. Section 7.4.1 now deprecates the use of the "name" parameter for
+ application/octet-stream, as this will be superseded in the future by
+ a Content-Disposition header.
+
+ 9. The formal grammar for multipart bodies has been changed so that
+ a CRLF is no longer required before the first boundary line.
+
+ 10. MIME entities of type "message/partial" and "message/external-
+ body" are now required to use only the "7bit" transfer-encoding.
+ (Specifically, "binary" and "8bit" are not permitted.)
+
+ 11. The "application/oda" content-type has been removed.
+
+ 12. A note has been added to the end of section 7.2.3, explaining
+ the semantics of Content-ID in a multipart/alternative MIME entity.
+
+ 13. The formal syntax for the "MIME-Version" field has been
+ tightened, but in a way that is completely compatible with the only
+
+
+
+Borenstein & Freed [Page 78]
+
+RFC 1521 MIME September 1993
+
+
+ version number defined in RFC 1341.
+
+ 14. In Section 7.3.1, the definition of message/rfc822 has been
+ relaxed regarding mandatory fields.
+
+ All other changes from RFC 1341 were editorial changes and do not
+ affect the technical content of MIME. Considerable formal grammar
+ has been added, but this reflects the prose specification that was
+ already in place.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Borenstein & Freed [Page 79]
+
+RFC 1521 MIME September 1993
+
+
+References
+
+ [US-ASCII] Coded Character Set--7-Bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [ATK] Borenstein, Nathaniel S., Multimedia Applications Development
+ with the Andrew Toolkit, Prentice-Hall, 1990.
+
+ [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc.,
+ Columbus, Ohio, 1990.
+
+ [ISO-2022] International Standard--Information Processing--ISO 7-bit
+ and 8-bit coded character sets--Code extension techniques, ISO
+ 2022:1986.
+
+ [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic
+ Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part
+ 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet
+ No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4,
+ 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
+ Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek
+ alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO
+ 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
+
+ [ISO-646] International Standard--Information Processing--ISO 7-bit
+ coded character set for information interchange, ISO 646:1983.
+
+ [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11
+ (Motion Picture Experts Group), May, 1991.
+
+ [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972,
+ "Pulse Code Modulation (PCM) of Voice Frequencies".
+
+ [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference
+ Manual, Addison-Wesley, 1985.
+
+ [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference
+ Manual, Addison-Wesley, Second Edition, 1990.
+
+ [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message
+ Handling Systems and Distributed Applications, E. Stefferud, O-j.
+ Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.
+
+ [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT,
+ June 1981.
+
+ [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, USC/Information Sciences Institute, August 1982.
+
+
+
+Borenstein & Freed [Page 80]
+
+RFC 1521 MIME September 1993
+
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message
+ Encapsulation", RFC 934, Delaware and NMA, January 1985.
+
+ [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol",
+ STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
+
+ [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet
+ Messages", STD 11, RFC 1049, CMU, March 1988.
+
+ [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
+ Part I - Message Encryption and Authentication Procedures", RFC
+ 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.
+
+ [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for
+ Internet Messages", RFC 1154, Prime Computer, Inc., April 1990.
+
+ [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
+ Mail Extensions): Mechanisms for Specifying and Describing the Format
+ of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.
+
+ [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet
+ Message Headers", RFC 1342, University of Tennessee, June 1992.
+
+ [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism
+ for Multimedia Mail Format Information", RFC 1343, Bellcore, June
+ 1992.
+
+ [RFC-1344] Borenstein, N., "Implications of MIME for Internet
+ Mail Gateways", RFC 1344, Bellcore, June 1992.
+
+ [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets",
+ RFC 1345, Rationel Almen Planlaegning, June 1992.
+
+ [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
+ Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME
+ transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach
+ Consulting, Inc., Network Management Associates, Inc., The Branch
+ Office, February 1993.
+
+ [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet
+ Message Headers" RFC 1522, University of Tennessee, September 1993.
+
+ [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1340, USC/Information Sciences Institute, July 1992.
+
+
+
+
+Borenstein & Freed [Page 81]
+
\ No newline at end of file diff --git a/RFC/rfc1725.txt b/RFC/rfc1725.txt new file mode 100644 index 00000000..43fcc518 --- /dev/null +++ b/RFC/rfc1725.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 1725 Carnegie Mellon +Obsoletes: 1460 M. Rose +Category: Standards Track Dover Beach Consulting, Inc. + November 1994 + + + Post Office Protocol - Version 3 + +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. + +Overview + + This memo is a revision to RFC 1460, a Draft Standard. It makes the + following changes from that document: + + - removed text regarding "split-UA model", which didn't add + anything to the understanding of POP + + - clarified syntax of commands, keywords, and arguments + + - clarified behavior on broken connection + + - explicitly permitted an inactivity autologout timer + + - clarified the requirements of the "exclusive-access lock" + + - removed implementation-specific wording regarding the parsing of + the maildrop + + - allowed servers to close the connection after a failed + authentication command + + - removed the LAST command + + - fixed typo in example of TOP command + + - clarified that the second argument to the TOP command is non- + negative + + - added the optional UIDL command + + + + +Myers & Rose [Page 1] + +RFC 1725 POP3 November 1994 + + + - added warning regarding length of shared secrets with APOP + + - added additional warnings to the security considerations section + +1. Introduction + + On certain types of smaller nodes in the Internet it is often + impractical to maintain a message transport system (MTS). For + example, a workstation may not have sufficient resources (cycles, + disk space) in order to permit a SMTP server [RFC821] and associated + local mail delivery system to be kept resident and continuously + running. Similarly, it may be expensive (or impossible) to keep a + personal computer interconnected to an IP-style network for long + amounts of time (the node is lacking the resource known as + "connectivity"). + + Despite this, it is often very useful to be able to manage mail on + these smaller nodes, and they often support a user agent (UA) to aid + the tasks of mail handling. To solve this problem, a node which can + support an MTS entity offers a maildrop service to these less endowed + nodes. The Post Office Protocol - Version 3 (POP3) is intended to + permit a workstation to dynamically access a maildrop on a server + host in a useful fashion. Usually, this means that the POP3 is used + to allow a workstation to retrieve mail that the server is holding + for it. + + For the remainder of this memo, the term "client host" refers to a + host making use of the POP3 service, while the term "server host" + refers to a host which offers the POP3 service. + +2. A Short Digression + + This memo does not specify how a client host enters mail into the + transport system, although a method consistent with the philosophy of + this memo is presented here: + + When the user agent on a client host wishes to enter a message + into the transport system, it establishes an SMTP connection to + its relay host (this relay host could be, but need not be, the + POP3 server host for the client host). + +3. Basic Operation + + Initially, the server host starts the POP3 service by listening on + TCP port 110. When a client host wishes to make use of the service, + it establishes a TCP connection with the server host. When the + connection is established, the POP3 server sends a greeting. The + client and POP3 server then exchange commands and responses + + + +Myers & Rose [Page 2] + +RFC 1725 POP3 November 1994 + + + (respectively) until the connection is closed or aborted. + + Commands in the POP3 consist of a keyword, possibly followed by one + or more arguments. All commands are terminated by a CRLF pair. + Keywords and arguments consist of printable ASCII characters. + Keywords and arguments are each separated by a single SPACE + character. Keywords are three or four characters long. Each argument + may be up to 40 characters long. + + Responses in the POP3 consist of a status indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. There are currently two status + indicators: positive ("+OK") and negative ("-ERR"). + + Responses to certain commands are multi-line. In these cases, which + are clearly indicated below, after sending the first line of the + response and a CRLF, any additional lines are sent, each terminated + by a CRLF pair. When all lines of the response have been sent, a + final line is sent, consisting of a termination octet (decimal code + 046, ".") and a CRLF pair. If any line of the multi-line response + begins with the termination octet, the line is "byte-stuffed" by + pre-pending the termination octet to that line of the response. + Hence a multi-line response is terminated with the five octets + "CRLF.CRLF". When examining a multi-line response, the client checks + to see if the line begins with the termination octet. If so and if + octets other than CRLF follow, the the first octet of the line (the + termination octet) is stripped away. If so and if CRLF immediately + follows the termination character, then the response from the POP + server is ended and the line containing ".CRLF" is not considered + part of the multi-line response. + + A POP3 session progresses through a number of states during its + lifetime. Once the TCP connection has been opened and the POP3 + server has sent the greeting, the session enters the AUTHORIZATION + state. In this state, the client must identify itself to the POP3 + server. Once the client has successfully done this, the server + acquires resources associated with the client's maildrop, and the + session enters the TRANSACTION state. In this state, the client + requests actions on the part of the POP3 server. When the client has + issued the QUIT command, the session enters the UPDATE state. In + this state, the POP3 server releases any resources acquired during + the TRANSACTION state and says goodbye. The TCP connection is then + closed. + + A POP3 server MAY have an inactivity autologout timer. Such a timer + MUST be of at least 10 minutes' duration. The receipt of any command + from the client during that interval should suffice to reset the + autologout timer. When the timer expires, the session does NOT enter + + + +Myers & Rose [Page 3] + +RFC 1725 POP3 November 1994 + + + the UPDATE state--the server should close the TCP connection without + removing any messages or sending any response to the client. + +4. The AUTHORIZATION State + + Once the TCP connection has been opened by a POP3 client, the POP3 + server issues a one line greeting. This can be any string terminated + by CRLF. An example might be: + + S: +OK POP3 server ready + + Note that this greeting is a POP3 reply. The POP3 server should + always give a positive response as the greeting. + + The POP3 session is now in the AUTHORIZATION state. The client must + now identify and authenticate itself to the POP3 server. Two + possible mechanisms for doing this are described in this document, + the USER and PASS command combination and the APOP command. The APOP + command is described later in this document. + + To authenticate using the USER and PASS command combination, the + client must first issue the USER command. If the POP3 server + responds with a positive status indicator ("+OK"), then the client + may issue either the PASS command to complete the authentication, or + the QUIT command to terminate the POP3 session. If the POP3 server + responds with a negative status indicator ("-ERR") to the USER + command, then the client may either issue a new authentication + command or may issue the QUIT command. + + When the client issues the PASS command, the POP3 server uses the + argument pair from the USER and PASS commands to determine if the + client should be given access to the appropriate maildrop. + + Once the POP3 server has determined through the use of any + authentication command that the client should be given access to the + appropriate maildrop, the POP3 server then acquires an exclusive- + access lock on the maildrop, as necessary to prevent messages from + being modified or removed before the session enters the UPDATE state. + If the lock is successfully acquired, the POP3 server responds with a + positive status indicator. The POP3 session now enters the + TRANSACTION state, with no messages marked as deleted. If the the + maildrop cannot be opened for some reason (for example, a lock can + not be acquired, the client is denied access to the appropriate + maildrop, or the maildrop cannot be parsed), the POP3 server responds + with a negative status indicator. (If a lock was acquired but the + POP3 server intends to respond with a negative status indicator, the + POP3 server must release the lock prior to rejecting the command.) + After returning a negative status indicator, the server may close the + + + +Myers & Rose [Page 4] + +RFC 1725 POP3 November 1994 + + + connection. If the server does not close the connection, the client + may either issue a new authentication command and start again, or the + client may issue the QUIT command. + + After the POP3 server has opened the maildrop, it assigns a message- + number to each message, and notes the size of each message in octets. + The first message in the maildrop is assigned a message-number of + "1", the second is assigned "2", and so on, so that the n'th message + in a maildrop is assigned a message-number of "n". In POP3 commands + and responses, all message-number's and message sizes are expressed + in base-10 (i.e., decimal). + + Here are summaries for the three POP3 commands discussed thus far: + + USER name + + Arguments: + a string identifying a mailbox (required), which is of + significance ONLY to the server + + Restrictions: + may only be given in the AUTHORIZATION state after the POP3 + greeting or after an unsuccessful USER or PASS command + + Possible Responses: + +OK name is a valid mailbox + -ERR never heard of mailbox name + + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + ... + C: USER frated + S: -ERR sorry, no mailbox for frated here + + PASS string + + Arguments: + a server/mailbox-specific password (required) + + Restrictions: + may only be given in the AUTHORIZATION state after a + successful USER command + + Discussion: + Since the PASS command has exactly one argument, a POP3 + server may treat spaces in the argument as part of the + password, instead of as argument separators. + + + +Myers & Rose [Page 5] + +RFC 1725 POP3 November 1994 + + + Possible Responses: + +OK maildrop locked and ready + -ERR invalid password + -ERR unable to lock maildrop + + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages (320 octets) + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR maildrop already locked + + QUIT + + Arguments: none + + Restrictions: none + + Possible Responses: + +OK + + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + +5. The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and opened the appropriate maildrop, + the POP3 session is now in the TRANSACTION state. The client may now + issue any of the following POP3 commands repeatedly. After each + command, the POP3 server issues a response. Eventually, the client + issues the QUIT command and the POP3 session enters the UPDATE state. + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + + + + +Myers & Rose [Page 6] + +RFC 1725 POP3 November 1994 + + + Discussion: + The POP3 server issues a positive response with a line + containing information for the maildrop. This line is + called a "drop listing" for that maildrop. + + In order to simplify parsing, all POP3 servers required to + use a certain format for drop listings. The positive + response consists of "+OK" followed by a single space, the + number of messages in the maildrop, a single space, and the + size of the maildrop in octets. This memo makes no + requirement on what follows the maildrop size. Minimal + implementations should just end that line of the response + with a CRLF pair. More advanced implementations may + include other information. + + NOTE: This memo STRONGLY discourages implementations + from supplying additional information in the drop + listing. Other, optional, facilities are discussed + later on which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not counted in + either total. + + Possible Responses: + +OK nn mm + + Examples: + C: STAT + S: +OK 2 320 + + LIST [msg] + + Arguments: + a message-number (optional), which, if present, may NOT + refer to a message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If an argument was given and the POP3 server issues a + positive response with a line containing information for + that message. This line is called a "scan listing" for + that message. + + If no argument was given and the POP3 server issues a + positive response, then the response given is multi-line. + + + +Myers & Rose [Page 7] + +RFC 1725 POP3 November 1994 + + + After the initial +OK, for each message in the maildrop, + the POP3 server responds with a line containing information + for that message. This line is also called a "scan + listing" for that message. + + In order to simplify parsing, all POP3 servers are required + to use a certain format for scan listings. A scan listing + consists of the message-number of the message, followed by + a single space and the exact size of the message in octets. + This memo makes no requirement on what follows the message + size in the scan listing. Minimal implementations should + just end that line of the response with a CRLF pair. More + advanced implementations may include other information, as + parsed from the message. + + NOTE: This memo STRONGLY discourages implementations + from supplying additional information in the scan + listing. Other, optional, facilities are discussed + later on which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not listed. + + Possible Responses: + +OK scan listing follows + -ERR no such message + + Examples: + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + ... + C: LIST 2 + S: +OK 2 200 + ... + C: LIST 3 + S: -ERR no such message, only 2 messages in maildrop + + RETR msg + + Arguments: + a message-number (required) which may not refer to a + message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state + + + +Myers & Rose [Page 8] + +RFC 1725 POP3 November 1994 + + + Discussion: + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, the + POP3 server sends the message corresponding to the given + message-number, being careful to byte-stuff the termination + character (as with all multi-line responses). + + Possible Responses: + +OK message follows + -ERR no such message + + Examples: + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends the entire message here> + S: . + + DELE msg + + Arguments: + a message-number (required) which may not refer to a + message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + The POP3 server marks the message as deleted. Any future + reference to the message-number associated with the message + in a POP3 command generates an error. The POP3 server does + not actually delete the message until the POP3 session + enters the UPDATE state. + + Possible Responses: + +OK message deleted + -ERR no such message + + Examples: + C: DELE 1 + S: +OK message 1 deleted + ... + C: DELE 2 + S: -ERR message 2 already deleted + + NOOP + + Arguments: none + + + + +Myers & Rose [Page 9] + +RFC 1725 POP3 November 1994 + + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + The POP3 server does nothing, it merely replies with a + positive response. + + Possible Responses: + +OK + + Examples: + C: NOOP + S: +OK + + RSET + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If any messages have been marked as deleted by the POP3 + server, they are unmarked. The POP3 server then replies + with a positive response. + + Possible Responses: + +OK + + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + +6. The UPDATE State + + When the client issues the QUIT command from the TRANSACTION state, + the POP3 session enters the UPDATE state. (Note that if the client + issues the QUIT command from the AUTHORIZATION state, the POP3 + session terminates but does NOT enter the UPDATE state.) + + If a session terminates for some reason other than a client-issued + QUIT command, the POP3 session does NOT enter the UPDATE state and + MUST not remove any messages from the maildrop. + + QUIT + + Arguments: none + + + + +Myers & Rose [Page 10] + +RFC 1725 POP3 November 1994 + + + Restrictions: none + + Discussion: + The POP3 server removes all messages marked as deleted from + the maildrop. It then releases any exclusive-access lock + on the maildrop and replies as to the status of these + operations. The TCP connection is then closed. + + Possible Responses: + +OK + + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + ... + C: QUIT + S: +OK dewey POP3 server signing off (2 messages left) + ... + +7. Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + implementations of POP3 servers. + + The optional POP3 commands described below permit a POP3 client + greater freedom in message handling, while preserving a simple POP3 + server implementation. + + NOTE: This memo STRONGLY encourages implementations to support + these commands in lieu of developing augmented drop and scan + listings. In short, the philosophy of this memo is to put + intelligence in the part of the POP3 client and not the POP3 + server. + + TOP msg n + + Arguments: + a message-number (required) which may NOT refer to to a + message marked as deleted, and a non-negative number + (required) + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, the + POP3 server sends the headers of the message, the blank + + + +Myers & Rose [Page 11] + +RFC 1725 POP3 November 1994 + + + line separating the headers from the body, and then the + number of lines indicated message's body, being careful to + byte-stuff the termination character (as with all multi- + line responses). + + Note that if the number of lines requested by the POP3 + client is greater than than the number of lines in the + body, then the POP3 server sends the entire message. + + Possible Responses: + +OK top of message follows + -ERR no such message + + Examples: + C: TOP 1 10 + S: +OK + S: <the POP3 server sends the headers of the + message, a blank line, and the first 10 lines + of the body of the message> + S: . + ... + C: TOP 100 3 + S: -ERR no such message + + UIDL [msg] + + Arguments: + a message-number (optionally) If a message-number is given, + it may NOT refer to a message marked as deleted. + + Restrictions: + may only be given in the TRANSACTION state. + + Discussion: + If an argument was given and the POP3 server issues a positive + response with a line containing information for that message. + This line is called a "unique-id listing" for that message. + + If no argument was given and the POP3 server issues a positive + response, then the response given is multi-line. After the + initial +OK, for each message in the maildrop, the POP3 server + responds with a line containing information for that message. + This line is called a "unique-id listing" for that message. + + In order to simplify parsing, all POP3 servers are required to + use a certain format for unique-id listings. A unique-id + listing consists of the message-number of the message, + followed by a single space and the unique-id of the message. + + + +Myers & Rose [Page 12] + +RFC 1725 POP3 November 1994 + + + No information follows the unique-id in the unique-id listing. + + The unique-id of a message is an arbitrary server-determined + string, consisting of characters in the range 0x21 to 0x7E, + which uniquely identifies a message within a maildrop and + which persists across sessions. The server should never reuse + an unique-id in a given maildrop, for as long as the entity + using the unique-id exists. + + Note that messages marked as deleted are not listed. + + Possible Responses: + +OK unique-id listing follows + -ERR no such message + + Examples: + C: UIDL + S: +OK + S: 1 whqtswO00WBw418f9t5JxYwZ + S: 2 QhdPYR:00WBw1Ph7x7 + S: . + ... + C: UIDL 2 + S: +OK 2 QhdPYR:00WBw1Ph7x7 + ... + C: UIDL 3 + S: -ERR no such message, only 2 messages in maildrop + + APOP name digest + + Arguments: + a string identifying a mailbox and a MD5 digest string + (both required) + + Restrictions: + may only be given in the AUTHORIZATION state after the POP3 + greeting + + Discussion: + Normally, each POP3 session starts with a USER/PASS + exchange. This results in a server/user-id specific + password being sent in the clear on the network. For + intermittent use of POP3, this may not introduce a sizable + risk. However, many POP3 client implementations connect to + the POP3 server on a regular basis -- to check for new + mail. Further the interval of session initiation may be on + the order of five minutes. Hence, the risk of password + capture is greatly enhanced. + + + +Myers & Rose [Page 13] + +RFC 1725 POP3 November 1994 + + + An alternate method of authentication is required which + provides for both origin authentication and replay + protection, but which does not involve sending a password + in the clear over the network. The APOP command provides + this functionality. + + A POP3 server which implements the APOP command will + include a timestamp in its banner greeting. The syntax of + the timestamp corresponds to the `msg-id' in [RFC822], and + MUST be different each time the POP3 server issues a banner + greeting. For example, on a UNIX implementation in which a + separate UNIX process is used for each instance of a POP3 + server, the syntax of the timestamp might be: + + <process-ID.clock@hostname> + + where `process-ID' is the decimal value of the process's + PID, clock is the decimal value of the system clock, and + hostname is the fully-qualified domain-name corresponding + to the host where the POP3 server is running. + + The POP3 client makes note of this timestamp, and then + issues the APOP command. The `name' parameter has + identical semantics to the `name' parameter of the USER + command. The `digest' parameter is calculated by applying + the MD5 algorithm [RFC1321] to a string consisting of the + timestamp (including angle-brackets) followed by a shared + secret. This shared secret is a string known only to the + POP3 client and server. Great care should be taken to + prevent unauthorized disclosure of the secret, as knowledge + of the secret will allow any entity to successfully + masquerade as the named user. The `digest' parameter + itself is a 16-octet value which is sent in hexadecimal + format, using lower-case ASCII characters. + + When the POP3 server receives the APOP command, it verifies + the digest provided. If the digest is correct, the POP3 + server issues a positive response, and the POP3 session + enters the TRANSACTION state. Otherwise, a negative + response is issued and the POP3 session remains in the + AUTHORIZATION state. + + Note that as the length of the shared secret increases, so + does the difficulty of deriving it. As such, shared + secrets should be long strings (considerably longer than + the 8-character example shown below). + + + + + +Myers & Rose [Page 14] + +RFC 1725 POP3 November 1994 + + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + + Examples: + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK maildrop has 1 message (369 octets) + + In this example, the shared secret is the string `tan- + staaf'. Hence, the MD5 algorithm is applied to the string + + <1896.697170952@dbc.mtview.ca.us>tanstaaf + + which produces a digest value of + + c4c9334bac560ecc979e58001b3e22fb + +8. POP3 Command Summary + + Minimal POP3 Commands: + + USER name valid in the AUTHORIZATION state + PASS string + QUIT + + STAT valid in the TRANSACTION state + LIST [msg] + RETR msg + DELE msg + NOOP + RSET + + QUIT valid in the UPDATE state + + Optional POP3 Commands: + + APOP name digest valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + UIDL [msg] + + POP3 Replies: + + +OK + -ERR + + + + + +Myers & Rose [Page 15] + +RFC 1725 POP3 November 1994 + + + Note that with the exception of the STAT, LIST, and UIDL commands, + the reply given by the POP3 server to any command is significant only + to "+OK" and "-ERR". Any text occurring after this reply may be + ignored by the client. + +9. Example POP3 Session + + S: <wait for connection on TCP port 110> + C: <open connection> + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK mrose's maildrop has 2 messages (320 octets) + C: STAT + S: +OK 2 320 + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends message 1> + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: <the POP3 server sends message 2> + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: <close connection> + S: <wait for next connection> + +10. Message Format + + All messages transmitted during a POP3 session are assumed to conform + to the standard for the format of Internet text messages [RFC822]. + + It is important to note that the octet count for a message on the + server host may differ from the octet count assigned to that message + due to local conventions for designating end-of-line. Usually, + during the AUTHORIZATION state of the POP3 session, the POP3 server + can calculate the size of each message in octets when it opens the + maildrop. For example, if the POP3 server host internally represents + end-of-line as a single character, then the POP3 server simply counts + + + +Myers & Rose [Page 16] + +RFC 1725 POP3 November 1994 + + + each occurrence of this character in a message as two octets. Note + that lines in the message which start with the termination octet need + not be counted twice, since the POP3 client will remove all byte- + stuffed termination characters when it receives a multi-line + response. + +11. References + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text + Messages", STD 11, RFC 822, University of Delaware, August 1982. + + [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, + MIT Laboratory for Computer Science, April, 1992. + +12. Security Considerations + + It is conjectured that use of the APOP command provides origin + identification and replay protection for a POP3 session. + Accordingly, a POP3 server which implements both the PASS and APOP + commands must not allow both methods of access for a given user; that + is, for a given "USER name" either the PASS or APOP command is + allowed, but not both. + + Further, note that as the length of the shared secret increases, so + does the difficulty of deriving it. + + Servers that answer -ERR to the USER command are giving potential + attackers clues about which names are valid + + Use of the PASS command sends passwords in the clear over the + network. + + Use of the RETR and TOP commands sends mail in the clear over the + network. + + Otherwise, security issues are not discussed in this memo. + +13. Acknowledgements + + The POP family has a long and checkered history. Although primarily + a minor revision to RFC 1460, POP3 is based on the ideas presented in + RFCs 918, 937, and 1081. + + In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff + provided significant comments on the APOP command. + + + +Myers & Rose [Page 17] + +RFC 1725 POP3 November 1994 + + +14. Authors' Addresses + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave + Pittsburgh, PA 15213 + + EMail: jgm+@cmu.edu + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Mountain View, CA 94043-2186 + + EMail: mrose@dbc.mtview.ca.us + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers & Rose [Page 18] + diff --git a/RFC/rfc1730.txt b/RFC/rfc1730.txt new file mode 100644 index 00000000..fcf72ad7 --- /dev/null +++ b/RFC/rfc1730.txt @@ -0,0 +1,4318 @@ +
+
+
+
+
+
+Network Working Group M. Crispin
+Request for Comments: 1730 University of Washington
+Category: Standards Track December 1994
+
+
+ INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
+
+
+
+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 Internet Message Access Protocol, Version 4 (IMAP4) allows a
+ client to access and manipulate electronic mail messages on a server.
+ IMAP4 permits manipulation of remote message folders, called
+ "mailboxes", in a way that is functionally equivalent to local
+ mailboxes. IMAP4 also provides the capability for an offline client
+ to resynchronize with the server (see also [IMAP-DISC]).
+
+ IMAP4 includes operations for creating, deleting, and renaming
+ mailboxes; checking for new messages; permanently removing messages;
+ setting and clearing flags; RFC 822 and MIME parsing; searching; and
+ selective fetching of message attributes, texts, and portions
+ thereof. Messages in IMAP4 are accessed by the use of numbers.
+ These numbers are either message sequence numbers (relative position
+ from 1 to the number of messages in the mailbox) or unique
+ identifiers (immutable, strictly ascending values assigned to each
+ message, but which are not necessarily contiguous).
+
+ IMAP4 supports a single server. A mechanism for supporting multiple
+ IMAP4 servers is discussed in [IMSP].
+
+ IMAP4 does not specify a means of posting mail; this function is
+ handled by a mail transfer protocol such as [SMTP].
+
+ IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
+ Compatibility issues are discussed in [IMAP-COMPAT].
+
+
+
+
+
+
+Crispin [Page i]
+
+RFC 1730 IMAP4 December 1994
+
+
+
+
+
+Table of Contents
+
+
+
+IMAP4 Protocol Specification ...................................... 1
+1. Organization of this Document ............................. 1
+1.1. How to Read This Document ................................. 1
+1.2. Conventions Used in this Document ......................... 1
+2. Protocol Overview ......................................... 1
+2.1. Link Level ................................................ 1
+2.2. Commands and Responses .................................... 1
+2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2
+2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2
+3. State and Flow Diagram .................................... 4
+3.1. Non-Authenticated State ................................... 4
+3.2. Authenticated State ....................................... 4
+3.3. Selected State ............................................ 4
+3.4. Logout State .............................................. 4
+4. Data Formats .............................................. 6
+4.1. Atom ...................................................... 6
+4.2. Number .................................................... 6
+4.3. String .................................................... 6
+4.3.1. 8-bit and Binary Strings .................................. 7
+4.4. Parenthesized List ........................................ 7
+4.5. NIL ....................................................... 7
+5. Operational Considerations ................................ 8
+5.1. Mailbox Naming ............................................ 8
+5.2. Mailbox Size and Message Status Updates ................... 8
+5.3. Response when no Command in Progress ...................... 8
+5.4. Autologout Timer .......................................... 9
+5.5. Multiple Commands in Progress ............................. 9
+6. Client Commands ........................................... 10
+6.1. Client Commands - Any State ............................... 10
+6.1.1. CAPABILITY Command ........................................ 10
+6.1.2. NOOP Command .............................................. 11
+6.1.3. LOGOUT Command ............................................ 11
+6.2. Client Commands - Non-Authenticated State ................. 12
+6.2.1. AUTHENTICATE Command ...................................... 12
+6.2.2. LOGIN Command ............................................. 14
+6.3. Client Commands - Authenticated State ..................... 14
+6.3.1. SELECT Command ............................................ 15
+6.3.2. EXAMINE Command ........................................... 16
+6.3.3. CREATE Command ............................................ 17
+6.3.4. DELETE Command ............................................ 18
+6.3.5. RENAME Command ............................................ 18
+
+
+
+Crispin [Page ii]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.3.6. SUBSCRIBE Command ......................................... 19
+6.3.7. UNSUBSCRIBE Command ....................................... 19
+6.3.8. LIST Command .............................................. 20
+6.3.9. LSUB Command .............................................. 22
+6.3.10. APPEND Command ............................................ 22
+6.4. Client Commands - Selected State .......................... 23
+6.4.1. CHECK Command ............................................. 23
+6.4.2. CLOSE Command ............................................. 24
+6.4.3. EXPUNGE Command ........................................... 25
+6.4.4. SEARCH Command ............................................ 25
+6.4.5. FETCH Command ............................................. 29
+6.4.6. PARTIAL Command ........................................... 32
+6.4.7. STORE Command ............................................. 33
+6.4.8. COPY Command .............................................. 34
+6.4.9. UID Command ............................................... 35
+6.5. Client Commands - Experimental/Expansion .................. 37
+6.5.1. X<atom> Command ........................................... 37
+7. Server Responses .......................................... 38
+7.1. Server Responses - Status Responses ....................... 39
+7.1.1. OK Response ............................................... 40
+7.1.2. NO Response ............................................... 40
+7.1.3. BAD Response .............................................. 41
+7.1.4. PREAUTH Response .......................................... 41
+7.1.5. BYE Response .............................................. 41
+7.2. Server Responses - Server and Mailbox Status .............. 42
+7.2.1. CAPABILITY Response ....................................... 42
+7.2.2. LIST Response ............................................. 43
+7.2.3. LSUB Response ............................................. 44
+7.2.4. SEARCH Response ........................................... 44
+7.2.5. FLAGS Response ............................................ 44
+7.3. Server Responses - Message Status ......................... 45
+7.3.1. EXISTS Response ........................................... 45
+7.3.2. RECENT Response ........................................... 45
+7.3.3. EXPUNGE Response .......................................... 45
+7.3.4. FETCH Response ............................................ 46
+7.3.5. Obsolete Responses ........................................ 51
+7.4. Server Responses - Command Continuation Request ........... 51
+8. Sample IMAP4 session ...................................... 52
+9. Formal Syntax ............................................. 53
+10. Author's Note ............................................. 64
+11. Security Considerations ................................... 64
+12. Author's Address .......................................... 64
+Appendices ........................................................ 65
+A. Obsolete Commands ......................................... 65
+A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65
+A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65
+A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66
+A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66
+
+
+
+Crispin [Page iii]
+
+RFC 1730 IMAP4 December 1994
+
+
+B. Obsolete Responses ........................................ 68
+B.7.2.OBS.1. MAILBOX Response .................................. 68
+B.7.3.OBS.1. COPY Response ..................................... 68
+B.7.3.OBS.2. STORE Response .................................... 69
+C. References ................................................ 70
+E. IMAP4 Keyword Index ....................................... 71
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page iv]
+
+RFC 1730 IMAP4 December 1994
+
+
+IMAP4 Protocol Specification
+
+1. Organization of this Document
+
+1.1. How to Read This Document
+
+ This document is written from the point of view of the implementor of
+ an IMAP4 client or server. Beyond the protocol overview in section
+ 2, it is not optimized for someone trying to understand the operation
+ of the protocol. The material in sections 3 through 5 provides the
+ general context and definitions with which IMAP4 operates.
+
+ Sections 6, 7, and 9 describe the IMAP commands, responses, and
+ syntax, respectively. The relationships among these are such that it
+ is almost impossible to understand any of them separately. In
+ particular, one should not attempt to deduce command syntax from the
+ command section alone; one should instead refer to the formal syntax
+ section.
+
+
+1.2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+
+2. Protocol Overview
+
+2.1. Link Level
+
+ The IMAP4 protocol assumes a reliable data stream such as provided by
+ TCP. When TCP is used, an IMAP4 server listens on port 143.
+
+
+2.2. Commands and Responses
+
+ An IMAP4 session consists of the establishment of a client/server
+ connection, an initial greeting from the server, and client/server
+ interactions. These client/server interactions consist of a client
+ command, server data, and a server completion result response.
+
+ All interactions transmitted by client and server are in the form of
+ lines; that is, strings that end with a CRLF. The protocol receiver
+ of an IMAP4 client or server is either reading a line, or is reading
+ a sequence of octets with a known count followed by a line.
+
+
+
+
+
+
+Crispin [Page 1]
+
+RFC 1730 IMAP4 December 1994
+
+
+2.2.1. Client Protocol Sender and Server Protocol Receiver
+
+ The client command begins an operation. Each client command is
+ prefixed with a identifier (typically a short alphanumeric string,
+ e.g. A0001, A0002, etc.) called a "tag". A different tag is
+ generated by the client for each command.
+
+ There are two cases in which a line from the client does not
+ represent a complete command. In one case, a command argument is
+ quoted with an octet count (see the description of literal in String
+ under Data Formats); in the other case, the command arguments require
+ server feedback (see the AUTHENTICATE command). In either case, the
+ server sends a command continuation request response if it is ready
+ for the octets (if appropriate) and the remainder of the command.
+ This response is prefixed with the token "+".
+
+ Note: If, instead, the server detected an error in the
+ command, it sends a BAD completion response with tag
+ matching the command (as described below) to reject the
+ command and prevent the client from sending any more of the
+ command.
+
+ It is also possible for the server to send a completion
+ response for some other command (if multiple commands are
+ in progress), or untagged data. In either case, the
+ command continuation request is still pending; the client
+ takes the appropriate action for the response, and reads
+ another response from the server.
+
+ The protocol receiver of an IMAP4 server reads a command line from
+ the client, parses the command and its arguments, and transmits
+ server data and a server command completion result response.
+
+
+2.2.2. Server Protocol Sender and Client Protocol Receiver
+
+ Data transmitted by the server to the client and status responses
+ that do not indicate command completion are prefixed with the token
+ "*", and are called untagged responses.
+
+ Server data may be sent as a result of a client command, or may be
+ sent unilaterally by the server. There is no syntactic difference
+ between server data that resulted from a specific command and server
+ data that were sent unilaterally.
+
+ The server completion result response indicates the success or
+ failure of the operation. It is tagged with the same tag as the
+ client command which began the operation. Thus, if more than one
+
+
+
+Crispin [Page 2]
+
+RFC 1730 IMAP4 December 1994
+
+
+ command is in progress, the tag in a server completion response
+ identifies the command to which the response applies. There are
+ three possible server completion responses: OK (indicating success),
+ NO (indicating failure), or BAD (indicating protocol error such as
+ unrecognized command or command syntax error).
+
+ The protocol receiver of an IMAP4 client reads a response line from
+ the server. It then takes action on the response based upon the
+ first token of the response, which may be a tag, a "*", or a "+". As
+ described above.
+
+ A client MUST be prepared to accept any server response at all times.
+ This includes server data that it may not have requested. Server
+ data SHOULD be recorded, so that the client can reference its
+ recorded copy rather than sending a command to the server to request
+ the data. In the case of certain server data, recording the data is
+ mandatory.
+
+ This topic is discussed in greater detail in the Server Responses
+ section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 3]
+
+RFC 1730 IMAP4 December 1994
+
+
+3. State and Flow Diagram
+
+ An IMAP4 server is in one of four states. Most commands are valid in
+ only certain states. It is a protocol error for the client to
+ attempt a command while the command is in an inappropriate state. In
+ this case, a server will respond with a BAD or NO (depending upon
+ server implementation) command completion result.
+
+
+3.1. Non-Authenticated State
+
+ In non-authenticated state, the user must supply authentication
+ credentials before most commands will be permitted. This state is
+ entered when a connection starts unless the connection has been
+ pre-authenticated.
+
+
+3.2. Authenticated State
+
+ In authenticated state, the user is authenticated and must select a
+ mailbox to access before commands that affect messages will be
+ permitted. This state is entered when a pre-authenticated connection
+ starts, when acceptable authentication credentials have been
+ provided, or after an error in selecting a mailbox.
+
+
+3.3. Selected State
+
+ In selected state, a mailbox has been selected to access. This state
+ is entered when a mailbox has been successfully selected.
+
+
+3.4. Logout State
+
+ In logout state, the session is being terminated, and the server will
+ close the connection. This state can be entered as a result of a
+ client request or by unilateral server decision.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 4]
+
+RFC 1730 IMAP4 December 1994
+
+
+ +--------------------------------------+
+ |initial connection and server greeting|
+ +--------------------------------------+
+ || (1) || (2) || (3)
+ VV || ||
+ +-----------------+ || ||
+ |non-authenticated| || ||
+ +-----------------+ || ||
+ || (7) || (4) || ||
+ || VV VV ||
+ || +----------------+ ||
+ || | authenticated |<=++ ||
+ || +----------------+ || ||
+ || || (7) || (5) || (6) ||
+ || || VV || ||
+ || || +--------+ || ||
+ || || |selected|==++ ||
+ || || +--------+ ||
+ || || || (7) ||
+ VV VV VV VV
+ +--------------------------------------+
+ | logout and close connection |
+ +--------------------------------------+
+
+ (1) connection without pre-authentication (OK greeting)
+ (2) pre-authenticated connection (PREAUTH greeting)
+ (3) rejected connection (BYE greeting)
+ (4) successful LOGIN or AUTHENTICATE command
+ (5) successful SELECT or EXAMINE command
+ (6) CLOSE command, or failed SELECT or EXAMINE command
+ (7) LOGOUT command, server shutdown, or connection closed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 5]
+
+RFC 1730 IMAP4 December 1994
+
+
+4. Data Formats
+
+ IMAP4 uses textual commands and responses. Data in IMAP4 can be in
+ one of several forms: atom, number, string, parenthesized list, or
+ NIL.
+
+
+4.1. Atom
+
+ An atom consists of one or more non-special characters.
+
+
+4.2. Number
+
+ A number consists of one or more digit characters, and represents a
+ numeric value.
+
+
+4.3. String
+
+ A string is in one of two forms: literal and quoted string. The
+ literal form is the general form of string. The quoted string form
+ is an alternative that avoids the overhead of processing a literal at
+ the cost of restrictions of what may be in a quoted string.
+
+ A literal is a sequence of zero or more octets (including CR and LF),
+ prefix-quoted with an octet count in the form of an open brace ("{"),
+ the number of octets, close brace ("}"), and CRLF. In the case of
+ literals transmitted from server to client, the CRLF is immediately
+ followed by the octet data. In the case of literals transmitted from
+ client to server, the client must wait to receive a command
+ continuation request (described later in this document) before
+ sending the octet data (and the remainder of the command).
+
+ A quoted string is a sequence of zero or more 7-bit characters,
+ excluding CR and LF, with double quote (<">) characters at each end.
+
+ The empty string is respresented as either "" (a quoted string with
+ zero characters between double quotes) or as {0} followed by CRLF (a
+ literal with an octet count of 0).
+
+ Note: Even if the octet count is 0, a client transmitting a
+ literal must wait to receive a command continuation
+ request.
+
+
+
+
+
+
+
+Crispin [Page 6]
+
+RFC 1730 IMAP4 December 1994
+
+
+4.3.1. 8-bit and Binary Strings
+
+ 8-bit textual and binary mail is supported through the use of
+ [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or
+ multi-octet characters in literals, but should do so only when the
+ character set is identified.
+
+ Although a BINARY body encoding is defined, unencoded binary strings
+ are not permitted. A "binary string" is any string with NUL
+ characters. Implementations MUST encode binary data into a textual
+ form such as BASE64 before transmitting the data. A string with an
+ excessive amount of CTL characters may also be considered to be
+ binary, although this is not required.
+
+
+4.4. Parenthesized List
+
+ Data structures are represented as a "parenthesized list"; a sequence
+ of data items, delimited by space, and bounded at each end by
+ parentheses. A parenthesized list may itself contain other
+ parenthesized lists, using multiple levels of parentheses to indicate
+ nesting.
+
+ The empty list is represented as () -- a parenthesized list with no
+ members.
+
+
+4.5. NIL
+
+ The special atom "NIL" represents the non-existence of a particular
+ data item that is represented as a string or parenthesized list, as
+ distinct from the empty string "" or the empty parenthesized list ().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 7]
+
+RFC 1730 IMAP4 December 1994
+
+
+5. Operational Considerations
+
+5.1. Mailbox Naming
+
+ The interpretation of mailbox names is implementation-dependent.
+ However, the mailbox name INBOX is a special name reserved to mean
+ "the primary mailbox for this user on this server". If it is desired
+ to export hierarchical mailbox names, mailbox names must be
+ left-to-right hierarchical using a single character to separate
+ levels of hierarchy. The same hierarchy separator character is used
+ for all levels of hierarchy within a single name.
+
+5.2. Mailbox Size and Message Status Updates
+
+ At any time, a server can send data that the client did not request.
+ Sometimes, such behavior is required. For example, agents other than
+ the server may add messages to the mailbox (e.g. new mail delivery),
+ change the flags of message in the mailbox (e.g. simultaneous access
+ to the same mailbox by multiple agents), or even remove messages from
+ the mailbox. A server MUST send mailbox size updates automatically
+ if a mailbox size change is observed during the processing of a
+ command. A server SHOULD send message flag updates automatically,
+ without requiring the client to request such updates explicitly.
+ Special rules exist for server notification of a client about the
+ removal of messages to prevent synchronization errors; see the
+ description of the EXPUNGE response for more details.
+
+ Regardless of what implementation decisions a client may take on
+ remembering data from the server, a client implementation MUST record
+ mailbox size updates. It MUST NOT assume that any command after
+ initial mailbox selection will return the size of the mailbox.
+
+
+5.3. Response when no Command in Progress
+
+ Server implementations are permitted to send an untagged response
+ (except for EXPUNGE) while there is no command in progress. Server
+ implementations that send such responses MUST deal with flow control
+ considerations. Specifically, they must either (1) verify that the
+ size of the data does not exceed the underlying transport's available
+ window size, or (2) use non-blocking writes.
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 8]
+
+RFC 1730 IMAP4 December 1994
+
+
+5.4. Autologout Timer
+
+ If a server has an inactivity autologout timer, that timer MUST be of
+ at least 30 minutes' duration. The receipt of ANY command from the
+ client during that interval should suffice to reset the autologout
+ timer.
+
+
+5.5. Multiple Commands in Progress
+
+ The client is not required to wait for the completion result response
+ of a command before sending another command, subject to flow control
+ constraints on the underlying data stream. Similarly, a server is
+ not required to process a command to completion before beginning
+ processing of the next command, unless an ambiguity would result
+ because of a command that would affect the results of other commands.
+ If there is such an ambiguity, the server executes commands to
+ completion in the order given by the client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 9]
+
+RFC 1730 IMAP4 December 1994
+
+
+6. Client Commands
+
+ IMAP4 commands are described in this section. Commands are organized
+ by the state in which the command is permitted. Commands which are
+ permitted in multiple states are listed in the minimum permitted
+ state (for example, commands valid in authenticated and selected
+ state are listed in the authenticated state commands).
+
+ Command arguments, identified by "Arguments:" in the command
+ descriptions below, are described by function, not by syntax. The
+ precise syntax of command arguments is described in the Formal Syntax
+ section.
+
+ Some commands cause specific server data to be returned; these are
+ identified by "Data:" in the command descriptions below. See the
+ response descriptions in the Responses section for information on
+ these responses, and the Formal Syntax section for the precise syntax
+ of these responses. It is possible for server data to be transmitted
+ as a result of any command; thus, commands that do not specifically
+ require server data specify "no specific data for this command"
+ instead of "none".
+
+ The "Result:" in the command description refers to the possible
+ tagged status responses to a command, and any special interpretation
+ of these status responses.
+
+
+6.1. Client Commands - Any State
+
+ The following commands are valid in any state: CAPABILITY, NOOP, and
+ LOGOUT.
+
+6.1.1. CAPABILITY Command
+
+ Arguments: none
+
+ Data: mandatory untagged response: CAPABILITY
+
+ Result: OK - capability completed
+ BAD - command unknown or arguments invalid
+
+ The CAPABILITY command requests a listing of capabilities that the
+ server supports. The server MUST send a single untagged
+ CAPABILITY response with "IMAP4" as the first listed capability
+ before the (tagged) OK response. This listing of capabilities is
+ not dependent upon connection state or user. It is therefore not
+ necessary to issue a CAPABILITY command more than once in a
+ session.
+
+
+
+Crispin [Page 10]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Capability names other than "IMAP4" refer to extensions,
+ revisions, or amendments to this specification. See the
+ documentation of the CAPABILITY response for additional
+ information. No capabilities are enabled without explicit client
+ action to invoke the capability. See the section entitled "Client
+ Commands - Experimental/Expansion" for information about the form
+ of site or implementation-specific capabilities.
+
+ Example: C: abcd CAPABILITY
+ S: * CAPABILITY IMAP4
+ S: abcd OK CAPABILITY completed
+
+
+6.1.2. NOOP Command
+
+ Arguments: none
+
+ Data: no specific data for this command (but see below)
+
+ Result: OK - noop completed
+ BAD - command unknown or arguments invalid
+
+ The NOOP command always succeeds. It does nothing.
+
+ Since any command can return a status update as untagged data, the
+ NOOP command can be used as a periodic poll for new messages or
+ message status updates during a period of inactivity. The NOOP
+ command can also be used to reset any inactivity autologout timer
+ on the server.
+
+ Example: C: a002 NOOP
+ S: a002 OK NOOP completed
+ . . .
+ C: a047 NOOP
+ S: * 22 EXPUNGE
+ S: * 23 EXISTS
+ S: * 3 RECENT
+ S: * 14 FETCH (FLAGS (\Seen \Deleted))
+ S: a047 OK NOOP completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 11]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.1.3. LOGOUT Command
+
+ Arguments: none
+
+ Data: mandatory untagged response: BYE
+
+ Result: OK - logout completed
+ BAD - command unknown or arguments invalid
+
+ The LOGOUT command informs the server that the client is done with
+ the session. The server must send a BYE untagged response before
+ the (tagged) OK response, and then close the network connection.
+
+ Example: C: A023 LOGOUT
+ S: * BYE IMAP4 Server logging out
+ S: A023 OK LOGOUT completed
+ (Server and client then close the connection)
+
+
+
+6.2. Client Commands - Non-Authenticated State
+
+ In non-authenticated state, the AUTHENTICATE or LOGIN command
+ establishes authentication and enter authenticated state. The
+ AUTHENTICATE command provides a general mechanism for a variety of
+ authentication techniques, whereas the LOGIN command uses the
+ traditional user name and plaintext password pair.
+
+ Server implementations may allow non-authenticated access to certain
+ mailboxes. The convention is to use a LOGIN command with the userid
+ "anonymous". A password is required. It is implementation-dependent
+ what requirements, if any, are placed on the password and what access
+ restrictions are placed on anonymous users.
+
+ Once authenticated (including as anonymous), it is not possible to
+ re-enter non-authenticated state.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in non-authenticated state:
+ AUTHENTICATE and LOGIN.
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 12]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.2.1. AUTHENTICATE Command
+
+ Arguments: authentication mechanism name
+
+ Data: continuation data may be requested
+
+ Result: OK - authenticate completed, now in authenticated state
+ NO - authenticate failure: unsupported authentication
+ mechanism, credentials rejected
+ BAD - command unknown or arguments invalid,
+ authentication exchange cancelled
+
+ The AUTHENTICATE command indicates an authentication mechanism,
+ such as described in [IMAP-AUTH], 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 should reject the
+ AUTHENTICATE command by sending a tagged NO 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 consists of a
+ command continuation request response with the "+" token followed
+ by a BASE64 encoded string. The client answer consists of a line
+ consisting of 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 AUTHENTICATE command by sending a tagged BAD 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 tagged OK 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 AUTHENTICATE
+ command fails with a NO response, the client may try another
+
+
+
+Crispin [Page 13]
+
+RFC 1730 IMAP4 December 1994
+
+
+ authentication mechanism by issuing another AUTHENTICATE command,
+ or may attempt to authenticate by using the LOGIN command. In
+ other words, the client may request authentication types in
+ decreasing order of preference, with the LOGIN command as a last
+ resort.
+
+ Example: S: * OK KerberosV4 IMAP4 Server
+ C: A001 AUTHENTICATE KERBEROS_V4
+ S: + AmFYig==
+ C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+ +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+ WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+ S: + or//EoAADZI=
+ C: DiAF5A4gA+oOIALuBkAAmw==
+ S: A001 OK Kerberos V4 authentication successful
+
+ Note: the line breaks in the first client answer are for
+ editorial clarity and are not in real authenticators.
+
+
+6.2.2. LOGIN Command
+
+ Arguments: user name
+ password
+
+ Data: no specific data for this command
+
+ Result: OK - login completed, now in authenticated state
+ NO - login failure: user name or password rejected
+ BAD - command unknown or arguments invalid
+
+ The LOGIN command identifies the user to the server and carries
+ the plaintext password authenticating this user.
+
+ Example: C: a001 LOGIN SMITH SESAME
+ S: a001 OK LOGIN completed
+
+
+
+6.3. Client Commands - Authenticated State
+
+ In authenticated state, commands that manipulate mailboxes as atomic
+ entities are permitted. Of these commands, the SELECT and EXAMINE
+ commands will select a mailbox for access and enter selected state.
+
+
+
+
+
+
+
+Crispin [Page 14]
+
+RFC 1730 IMAP4 December 1994
+
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in authenticated state: SELECT,
+ EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
+ and APPEND.
+
+6.3.1. SELECT Command
+
+ Arguments: mailbox name
+
+ Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
+ optional OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+ Result: OK - select completed, now in selected state
+ NO - select failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The SELECT command selects a mailbox so that messages in the
+ mailbox can be accessed. Before returning an OK to the client,
+ the server MUST send the following untagged data to the client:
+
+ FLAGS Defined flags in the mailbox
+
+ <n> EXISTS The number of messages in the mailbox
+
+ <n> RECENT The number of messages added to the mailbox since
+ the previous time this mailbox was read
+
+ OK [UIDVALIDITY <n>]
+ The unique identifier validity value. See the
+ description of the UID command for more detail.
+
+ to define the initial state of the mailbox at the client. If it
+ is not possible to determine the messages that were added since
+ the previous time a mailbox was read, then all messages SHOULD be
+ considered recent.
+
+ The server SHOULD also send an UNSEEN response code in an OK
+ untagged response, indicating the message sequence number of the
+ first unseen message in the mailbox.
+
+ If the client can not change the permanent state of one or more of
+ the flags listed in the FLAGS untagged response, the server SHOULD
+ send a PERMANENTFLAGS response code in an OK untagged response,
+ listing the flags that the client may change permanently.
+
+ Only one mailbox may be selected at a time in a session;
+ simultaneous access to multiple mailboxes requires multiple
+
+
+
+Crispin [Page 15]
+
+RFC 1730 IMAP4 December 1994
+
+
+ sessions. The SELECT command automatically deselects any
+ currently selected mailbox before attempting the new selection.
+ Consequently, if a mailbox is selected and a SELECT command that
+ fails is attempted, no mailbox is selected.
+
+ If the user is permitted to modify the mailbox, the server SHOULD
+ prefix the text of the tagged OK response with the "[READ-WRITE]"
+ response code.
+
+ If the user is not permitted to modify the mailbox but is
+ permitted read access, the mailbox is selected as read-only, and
+ the server MUST prefix the text of the tagged OK response to
+ SELECT with the "[READ-ONLY]" response code. Read-only access
+ through SELECT differs from the EXAMINE command in that certain
+ read-only mailboxes may permit the change of permanent state on a
+ per-user (as opposed to global) basis. Netnews messages marked in
+ a user's .newsrc file are an example of such per-user permanent
+ state that can be modified with read-only mailboxes.
+
+ Example: C: A142 SELECT INBOX
+ S: * 172 EXISTS
+ S: * 1 RECENT
+ S: * OK [UNSEEN 12] Message 12 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+ S: A142 OK [READ-WRITE] SELECT completed
+
+
+6.3.2. EXAMINE Command
+
+ Arguments: mailbox name
+
+ Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
+ optional OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+ Result: OK - examine completed, now in selected state
+ NO - examine failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The EXAMINE command is identical to SELECT and returns the same
+ output; however, the selected mailbox is identified as read-only.
+ No changes to the permanent state of the mailbox, including
+ per-user state, are permitted.
+
+
+
+
+
+
+Crispin [Page 16]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The text of the tagged OK response to the EXAMINE command MUST
+ begin with the "[READ-ONLY]" response code.
+
+ Example: C: A932 EXAMINE blurdybloop
+ S: * 17 EXISTS
+ S: * 2 RECENT
+ S: * OK [UNSEEN 8] Message 8 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
+ S: A932 OK [READ-ONLY] EXAMINE completed
+
+
+6.3.3. CREATE Command
+
+ Arguments: mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - create completed
+ NO - create failure: can't create mailbox with that name
+ BAD - command unknown or arguments invalid
+
+ The CREATE command creates a mailbox with the given name. An OK
+ response is returned only if a new mailbox with that name has been
+ created. It is an error to attempt to create INBOX or a mailbox
+ with a name that refers to an extant mailbox. Any error in
+ creation will return a tagged NO response.
+
+ If the mailbox name is suffixed with the server's hierarchy
+ separator character (as returned from the server by a LIST
+ command), this is a declaration that the client may, in the
+ future, create mailbox names under this name in the hierarchy.
+ Server implementations that do not require this declaration MUST
+ ignore it.
+
+ If a new mailbox is created with the same name as a mailbox which
+ was deleted, its unique identifiers MUST be greater than any
+ unique identifiers used in the previous incarnation of the mailbox
+ UNLESS the new incarnation has a different unique identifier
+ validity value. See the description of the UID command for more
+ detail.
+
+ Example: C: A003 CREATE owatagusiam/
+ S: A003 OK CREATE completed
+ C: A004 CREATE owatagusiam/blurdybloop
+ S: A004 OK CREATE completed
+
+
+
+
+Crispin [Page 17]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Note: the interpretation of this example depends on whether
+ "/" was returned as the hierarchy separator from LIST. If
+ "/" is the hierarchy separator, a new level of hierarchy
+ named "owatagusiam" with a member called "blurdybloop" is
+ created. Otherwise, two mailboxes at the same hierarchy
+ level are created.
+
+
+6.3.4. DELETE Command
+
+ Arguments: mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - delete completed
+ NO - delete failure: can't delete mailbox with that name
+ BAD - command unknown or arguments invalid
+
+ The DELETE command permanently removes the mailbox with the given
+ name. A tagged OK response is returned only if the mailbox has
+ been deleted. It is an error to attempt to delete INBOX or a
+ mailbox name that does not exist. Any error in deletion will
+ return a tagged NO response.
+
+ The value of the highest-used unique indentifier of the deleted
+ mailbox MUST be preserved so that a new mailbox created with the
+ same name will not reuse the identifiers of the former
+ incarnation, UNLESS the new incarnation has a different unique
+ identifier validity value. See the description of the UID command
+ for more detail.
+
+ Example: C: A683 DELETE blurdybloop
+ S: A683 OK DELETE completed
+
+
+6.3.5. RENAME Command
+
+ Arguments: existing mailbox name
+ new mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - rename completed
+ NO - rename failure: can't rename mailbox with that name,
+ can't rename to mailbox with that name
+ BAD - command unknown or arguments invalid
+
+
+
+
+
+Crispin [Page 18]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The RENAME command changes the name of a mailbox. A tagged OK
+ response is returned only if the mailbox has been renamed. It is
+ an error to attempt to rename from a mailbox name that does not
+ exist or to a mailbox name that already exists. Any error in
+ renaming will return a tagged NO response.
+
+ Renaming INBOX is permitted; a new, empty INBOX is created in its
+ place.
+
+ Example: C: Z4S9 RENAME blurdybloop owatagusiam
+ S: Z4S9 OK RENAME completed
+
+
+6.3.6. SUBSCRIBE Command
+
+ Arguments: mailbox
+
+ 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 command adds the specified mailbox name to the
+ server's set of "active" or "subscribed" mailboxes as returned by
+ the LSUB command. This command returns a tagged OK response only
+ if the subscription is successful.
+
+ Example: C: A002 SUBSCRIBE #news.comp.mail.mime
+ S: A002 OK SUBSCRIBE completed
+
+
+6.3.7. UNSUBSCRIBE 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 command removes the specified mailbox name from
+ the server's set of "active" or "subscribed" mailboxes as returned
+ by the LSUB command. This command returns a tagged OK response
+ only if the unsubscription is successful.
+
+
+
+
+
+Crispin [Page 19]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
+ S: A002 OK UNSUBSCRIBE completed
+
+
+6.3.8. LIST Command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Data: untagged responses: LIST
+
+ Result: OK - list completed
+ NO - list failure: can't list that reference or name
+ BAD - command unknown or arguments invalid
+
+ The LIST command returns a subset of names from the complete set
+ of all names available to the user. Zero or more untagged LIST
+ replies are returned, containing the name attributes, hierarchy
+ delimiter, and name; see the description of the LIST reply for
+ more detail.
+
+ An empty ("" string) reference name argument indicates that the
+ mailbox name is interpreted as by SELECT. The returned mailbox
+ names MUST match the supplied mailbox name pattern. A non-empty
+ reference name argument is the name of a mailbox or a level of
+ mailbox hierarchy, and indicates a context in which the mailbox
+ name is interpreted in an implementation-defined manner.
+
+ The reference and mailbox name arguments are interpreted, in an
+ implementation-dependent fashion, into a canonical form that
+ represents an unambiguous left-to-right hierarchy. The returned
+ mailbox names will be in the interpreted form.
+
+ Any part of the reference argument that is included in the
+ interpreted form SHOULD prefix the interpreted form. It should
+ also be in the same form as the reference name argument. This
+ rule permits the client to determine if the returned mailbox name
+ is in the context of the reference argument, or if something about
+ the mailbox argument overrode the reference argument. Without
+ this rule, the client would have to have knowledge of the server's
+ naming semantics including what characters are "breakouts" that
+ override a naming context.
+
+
+
+
+
+
+
+
+
+Crispin [Page 20]
+
+RFC 1730 IMAP4 December 1994
+
+
+ For example, here are some examples of how references
+ and mailbox names might be interpreted on a UNIX-based
+ server:
+
+ Reference Mailbox Name Interpretation
+ ------------ ------------ --------------
+ ~smith/Mail/ foo.* ~smith/Mail/foo.*
+ archive/ % archive/%
+ #news. comp.mail.* #news.comp.mail.*
+ ~smith/Mail/ /usr/doc/foo /usr/doc/foo
+ archive/ ~fred/Mail/* ~fred/Mail/*
+
+ The first three examples demonstrate interpretations in
+ the context of the reference argument. Note that
+ "~smith/Mail" should not be transformed into something
+ like "/u2/users/smith/Mail", or it would be impossible
+ for the client to determine that the interpretation was
+ in the context of the reference.
+
+ The character "*" is a wildcard, and matches zero or more
+ characters at this position. The character "%" is similar to "*",
+ but it does not match a hierarchy delimiter. If the "%" wildcard
+ is the last character of a mailbox name argument, matching levels
+ of hierarchy are also returned. If these levels of hierarchy are
+ not also selectable mailboxes, they are returned with the
+ \Noselect mailbox name attribute (see the description of the LIST
+ response for more detail).
+
+ Server implementations are permitted to "hide" otherwise
+ accessible mailboxes from the wildcard characters, by preventing
+ certain characters or names from matching a wildcard in certain
+ situations. For example, a UNIX-based server might restrict the
+ interpretation of "*" so that an initial "/" character does not
+ match.
+
+ The special name INBOX is included in the output from LIST if it
+ matches the input arguments and INBOX is supported by this server
+ for this user. The criteria for omitting INBOX is whether SELECT
+ INBOX will return failure; it is not relevant whether the user's
+ real INBOX resides on this or some other server.
+
+ Example: C: A002 LIST "~/Mail/" "%"
+ S: * LIST (\Noselect) "/" ~/Mail/foo
+ S: * LIST () "/" ~/Mail/meetings
+ S: A002 OK LIST completed
+
+
+
+
+
+
+Crispin [Page 21]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.3.9. LSUB Command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Data: untagged responses: LSUB
+
+ Result: OK - lsub completed
+ NO - lsub failure: can't list that reference or name
+ BAD - command unknown or arguments invalid
+
+ The LSUB command returns a subset of names from the set of names
+ that the user has declared as being "active" or "subscribed".
+ Zero or more untagged LSUB replies are returned. The arguments to
+ LSUB are in the same form as those for LIST.
+
+ Example: C: A002 LSUB "#news." "comp.mail.*"
+ S: * LSUB () "." #news.comp.mail.mime
+ S: * LSUB () "." #news.comp.mail.misc
+ S: A002 OK LSUB completed
+
+
+6.3.10. APPEND Command
+
+ Arguments: mailbox name
+ optional flag parenthesized list
+ optional date/time string
+ message literal
+
+ Data: no specific data 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
+ BAD - command unknown or arguments invalid
+
+ The APPEND command appends the literal argument as a new message
+ in the specified destination mailbox. This argument is in the
+ format of an [RFC-822] 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 [MIME-1] encoding.
+
+ If a flag parenthesized list or date_time are specified, that data
+ SHOULD be set in the resulting message; otherwise, the defaults of
+ empty flags and the current date/time are used.
+
+
+
+
+
+Crispin [Page 22]
+
+RFC 1730 IMAP4 December 1994
+
+
+ If the append is unsuccessful for any reason, the mailbox MUST be
+ restored to its state before the APPEND attempt; no partial
+ appending is permitted. If the mailbox is currently selected, the
+ normal new mail actions should occur.
+
+ 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.
+
+ Example: C: A003 APPEND saved-messages (\Seen) {310}
+ C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+ C: From: Fred Foobar <foobar@Blurdybloop.COM>
+ C: Subject: afternoon meeting
+ C: To: mooch@owatagu.siam.edu
+ C: Message-Id: <B27397-0100000@Blurdybloop.COM>
+ C: MIME-Version: 1.0
+ C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+ C:
+ C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+ C:
+ S: A003 OK APPEND completed
+
+ Note: the APPEND command is not used for message delivery,
+ because it does not provide a mechanism to transfer [SMTP]
+ envelope information.
+
+
+
+6.4. Client Commands - Selected State
+
+ In selected state, commands that manipulate messages in a mailbox are
+ permitted.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ and the authenticated state commands (SELECT, EXAMINE, CREATE,
+ DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
+ ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
+ are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
+ FETCH, PARTIAL, STORE, COPY, and UID.
+
+
+
+
+
+
+
+
+Crispin [Page 23]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.4.1. CHECK Command
+
+ Arguments: none
+
+ Data: no specific data for this command
+
+ Result: OK - check completed
+ BAD - command unknown or arguments invalid
+
+ The CHECK command requests a checkpoint of the currently selected
+ mailbox. A checkpoint refers to any implementation-dependent
+ housekeeping associated with the mailbox (e.g. resolving the
+ server's in-memory state of the mailbox with the state on its
+ disk) that is not normally executed as part of each command. A
+ checkpoint may take a non-instantaneous amount of real time to
+ complete. If a server implementation has no such housekeeping
+ considerations, CHECK is equivalent to NOOP.
+
+ There is no guarantee that an EXISTS untagged response will happen
+ as a result of CHECK. NOOP, not CHECK, should be used for new
+ mail polling.
+
+ Example: C: FXXZ CHECK
+ S: FXXZ OK CHECK Completed
+
+
+6.4.2. CLOSE Command
+
+ Arguments: none
+
+ Data: no specific data for this command
+
+ Result: OK - close completed, now in authenticated state
+ NO - close failure: no mailbox selected
+ BAD - command unknown or arguments invalid
+
+ The CLOSE command permanently removes from the currently selected
+ mailbox all messages that have the \Deleted flag set, and returns
+ to authenticated state from selected state. No untagged EXPUNGE
+ responses are sent.
+
+ No messages are removed, and no error is given, if the mailbox is
+ selected by an EXAMINE command or is otherwise selected read-only.
+
+ Even when a mailbox is selected, it is not required to send a
+ CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The
+ SELECT, EXAMINE, and LOGOUT commands implicitly close the
+ currently selected mailbox without doing an expunge. However,
+
+
+
+Crispin [Page 24]
+
+RFC 1730 IMAP4 December 1994
+
+
+ when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
+ sequence is considerably faster than an EXPUNGE-LOGOUT or
+ EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
+ client would probably ignore) are sent.
+
+ Example: C: A341 CLOSE
+ S: A341 OK CLOSE completed
+
+
+6.4.3. EXPUNGE Command
+
+ Arguments: none
+
+ Data: untagged responses: EXPUNGE
+
+ Result: OK - expunge completed
+ NO - expunge failure: can't expunge (e.g. permission
+ denied)
+ BAD - command unknown or arguments invalid
+
+ The EXPUNGE command permanently removes from the currently
+ selected mailbox all messages that have the \Deleted flag set.
+ Before returning an OK to the client, an untagged EXPUNGE response
+ is sent for each message that is removed.
+
+ Example: C: A202 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 5 EXPUNGE
+ S: * 8 EXPUNGE
+ S: A202 OK EXPUNGE completed
+
+ Note: in this example, messages 3, 4, 7, and 11 had the
+ \Deleted flag set. See the description of the EXPUNGE
+ response for further explanation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 25]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.4.4. SEARCH Command
+
+ Arguments: optional character set specification
+ searching criteria (one or more)
+
+ Data: mandatory untagged response: SEARCH
+
+ Result: OK - search completed
+ NO - search error: can't search that character set or
+ criteria
+ BAD - command unknown or arguments invalid
+
+ The SEARCH command searches the mailbox for messages that match
+ the given searching criteria. Searching criteria consist of one
+ or more search keys. The untagged SEARCH response from the server
+ contains a listing of message sequence numbers corresponding to
+ those messages that match the searching criteria.
+
+ When multiple keys are specified, the result is the intersection
+ (AND function) of all the messages that match those keys. For
+ example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
+ to all deleted messages from Smith that were placed in the mailbox
+ since February 1, 1994. A search key may also be a parenthesized
+ list of one or more search keys (e.g. for use with the OR and NOT
+ keys).
+
+ Server implementations MAY exclude [MIME-1] body parts with
+ terminal content types other than TEXT and MESSAGE from
+ consideration in SEARCH matching.
+
+ The optional character set specification consists of the word
+ "CHARSET" followed by a registered MIME character set. It
+ indicates the character set of the strings that appear in the
+ search criteria. [MIME-2] strings that appear in RFC 822/MIME
+ message headers, and [MIME-1] content transfer encodings, MUST be
+ decoded before matching. Except for US-ASCII, it is not required
+ that any particular character set be supported. If the server
+ does not support the specified character set, it MUST return a
+ tagged NO response (not a BAD).
+
+ In all search keys that use strings, a message matches the key if
+ the string is a substring of the field. The matching is
+ case-insensitive.
+
+
+
+
+
+
+
+
+Crispin [Page 26]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The defined search keys are as follows. Refer to the Formal
+ Syntax section for the precise syntactic definitions of the
+ arguments.
+
+ <message set> Messages with message sequence numbers
+ corresponding to the specified message sequence
+ number set
+
+ ALL All messages in the mailbox; the default initial
+ key for ANDing.
+
+ ANSWERED Messages with the \Answered flag set.
+
+ BCC <string> Messages that contain the specified string in the
+ envelope structure's BCC field.
+
+ BEFORE <date> Messages whose internal date is earlier than the
+ specified date.
+
+ BODY <string> Messages that contain the specified string in the
+ body of the message.
+
+ CC <string> Messages that contain the specified string in the
+ envelope structure's CC field.
+
+ DELETED Messages with the \Deleted flag set.
+
+ DRAFT Messages with the \Draft flag set.
+
+ FLAGGED Messages with the \Flagged flag set.
+
+ FROM <string> Messages that contain the specified string in the
+ envelope structure's FROM field.
+
+ HEADER <field-name> <string>
+ Messages that have a header with the specified
+ field-name (as defined in [RFC-822]) and that
+ contains the specified string in the [RFC-822]
+ field-body.
+
+ KEYWORD <flag> Messages with the specified keyword set.
+
+ LARGER <n> Messages with an RFC822.SIZE larger than the
+ specified number of octets.
+
+ NEW Messages that have the \Recent flag set but not the
+ \Seen flag. This is functionally equivalent to
+ "(RECENT UNSEEN)".
+
+
+
+Crispin [Page 27]
+
+RFC 1730 IMAP4 December 1994
+
+
+ NOT <search-key>
+ Messages that do not match the specified search
+ key.
+
+ OLD Messages that do not have the \Recent flag set.
+ This is functionally equivalent to "NOT RECENT" (as
+ opposed to "NOT NEW").
+
+ ON <date> Messages whose internal date is within the
+ specified date.
+
+ OR <search-key1> <search-key2>
+ Messages that match either search key.
+
+ RECENT Messages that have the \Recent flag set.
+
+ SEEN Messages that have the \Seen flag set.
+
+ SENTBEFORE <date>
+ Messages whose [RFC-822] Date: header is earlier
+ than the specified date.
+
+ SENTON <date> Messages whose [RFC-822] Date: header is within the
+ specified date.
+
+ SENTSINCE <date>
+ Messages whose [RFC-822] Date: header is within or
+ later than the specified date.
+
+ SINCE <date> Messages whose internal date is within or later
+ than the specified date.
+
+ SMALLER <n> Messages with an RFC822.SIZE smaller than the
+ specified number of octets.
+
+ SUBJECT <string>
+ Messages that contain the specified string in the
+ envelope structure's SUBJECT field.
+
+ TEXT <string> Messages that contain the specified string in the
+ header or body of the message.
+
+ TO <string> Messages that contain the specified string in the
+ envelope structure's TO field.
+
+ UID <message set>
+ Messages with unique identifiers corresponding to
+ the specified unique identifier set.
+
+
+
+Crispin [Page 28]
+
+RFC 1730 IMAP4 December 1994
+
+
+ UNANSWERED Messages that do not have the \Answered flag set.
+
+ UNDELETED Messages that do not have the \Deleted flag set.
+
+ UNDRAFT Messages that do not have the \Draft flag set.
+
+ UNFLAGGED Messages that do not have the \Flagged flag set.
+
+ UNKEYWORD <flag>
+ Messages that do not have the specified keyword
+ set.
+
+ UNSEEN Messages that do not have the \Seen flag set.
+
+
+ Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
+ S: * SEARCH 2 84 882
+ S: A282 OK SEARCH completed
+
+
+6.4.5. FETCH Command
+
+ Arguments: message set
+ message data item names
+
+ Data: untagged responses: FETCH
+
+ Result: OK - fetch completed
+ NO - fetch error: can't fetch that data
+ BAD - command unknown or arguments invalid
+
+ The FETCH command retrieves data associated with a message in the
+ mailbox. The data items to be fetched may be either a single atom
+ or a parenthesized list. The currently defined data items that
+ can be fetched are:
+
+ ALL Macro equivalent to: (FLAGS INTERNALDATE
+ RFC822.SIZE ENVELOPE)
+
+ BODY Non-extensible form of BODYSTRUCTURE.
+
+ BODY[<section>]
+ The text of a particular body section. The section
+ specification is a set of one or more part numbers
+ delimited by periods.
+
+ Single-part messages only have a part 1.
+
+
+
+
+Crispin [Page 29]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Multipart messages are assigned consecutive part
+ numbers, as they occur in the message. If a
+ particular part is of type message or multipart,
+ its parts must be indicated by a period followed by
+ the part number within that nested multipart part.
+ It is not permitted to fetch a multipart part
+ itself, only its individual members.
+
+ A part of type MESSAGE and subtype RFC822 also has
+ nested parts. These are the parts of the MESSAGE
+ part's body. Nested part 0 of a part of type
+ MESSAGE and subtype RFC822 is the [RFC-822] header
+ of the message.
+
+ Every message has at least one part.
+
+ Here is an example of a complex message
+ with its associated section
+ specifications:
+
+ 0 ([RFC-822] header of the message)
+ MULTIPART/MIXED
+ 1 TEXT/PLAIN
+ 2 APPLICATION/OCTET-STREAM
+ 3 MESSAGE/RFC822
+ 3.0 ([RFC-822] header of the message)
+ 3.1 TEXT/PLAIN
+ 3.2 APPLICATION/OCTET-STREAM
+ MULTIPART/MIXED
+ 4.1 IMAGE/GIF
+ 4.2 MESSAGE/RFC822
+ 4.2.0 ([RFC-822] header of the message)
+ 4.2.1 TEXT/PLAIN
+ MULTIPART/ALTERNATIVE
+ 4.2.2.1 TEXT/PLAIN
+ 4.2.2.2 TEXT/RICHTEXT
+
+ Note that there is no section
+ specification for the Multi-part parts
+ (no section 4 or 4.2.2).
+
+ The \Seen flag is implicitly set; if this causes
+ the flags to change they should be included as part
+ of the fetch responses.
+
+ BODY.PEEK[<section>]
+ An alternate form of BODY[section] that does not
+ implicitly set the \Seen flag.
+
+
+
+Crispin [Page 30]
+
+RFC 1730 IMAP4 December 1994
+
+
+ BODYSTRUCTURE The [MIME-1] body structure of the message. This
+ is computed by the server by parsing the [MIME-1]
+ header lines.
+
+ ENVELOPE The envelope structure of the message. This is
+ computed by the server by parsing the [RFC-822]
+ header into the component parts, defaulting various
+ fields as necessary.
+
+ FAST Macro equivalent to: (FLAGS INTERNALDATE
+ RFC822.SIZE)
+
+ FLAGS The flags that are set for this message.
+
+ FULL Macro equivalent to: (FLAGS INTERNALDATE
+ RFC822.SIZE ENVELOPE BODY)
+
+ INTERNALDATE The date and time of final delivery of the message
+ as defined by RFC 821.
+
+ RFC822 The message in [RFC-822] format. The \Seen flag is
+ implicitly set; if this causes the flags to change
+ they should be included as part of the fetch
+ responses. This is the concatenation of
+ RFC822.HEADER and RFC822.TEXT.
+
+ RFC822.PEEK An alternate form of RFC822 that does not
+ implicitly set the \Seen flag.
+
+ RFC822.HEADER The [RFC-822] format header of the message as
+ stored on the server including the delimiting blank
+ line between the header and the body.
+
+ RFC822.HEADER.LINES <header_list>
+ All header lines (including continuation lines) of
+ the [RFC-822] format header of the message with a
+ field-name (as defined in [RFC-822]) that matches
+ any of the strings in header_list. The matching is
+ case-insensitive but otherwise exact. The
+ delimiting blank line between the header and the
+ body is always included.
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 31]
+
+RFC 1730 IMAP4 December 1994
+
+
+ RFC822.HEADER.LINES.NOT <header_list>
+ All header lines (including continuation lines) of
+ the [RFC-822] format header of the message with a
+ field-name (as defined in [RFC-822]) that does not
+ match any of the strings in header_list. The
+ matching is case-insensitive but otherwise exact.
+ The delimiting blank line between the header and
+ the body is always included.
+
+ RFC822.SIZE The number of octets in the message, as expressed
+ in [RFC-822] format.
+
+ RFC822.TEXT The text body of the message, omitting the
+ [RFC-822] header. The \Seen flag is implicitly
+ set; if this causes the flags to change they should
+ be included as part of the fetch responses.
+
+ RFC822.TEXT.PEEK
+ An alternate form of RFC822.TEXT that does not
+ implicitly set the \Seen flag.
+
+ UID The unique identifier for the message.
+
+
+ Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
+ S: * 2 FETCH ....
+ S: * 3 FETCH ....
+ S: * 4 FETCH ....
+ S: A003 OK FETCH completed
+
+
+6.4.6. 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
+
+
+
+Crispin [Page 32]
+
+RFC 1730 IMAP4 December 1994
+
+
+ of a message, and hence the minimum for the starting octet, is
+ octet 1.
+
+ 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.7. STORE Command
+
+ Arguments: message set
+ message data item name
+ value for message data item
+
+ Data: untagged responses: FETCH
+
+ Result: OK - store completed
+ NO - store error: can't store that data
+ BAD - command unknown or arguments invalid
+
+ The STORE command alters data associated with a message in the
+ mailbox. Normally, STORE will return the updated value of the
+ data with an untagged FETCH response. A suffix of ".SILENT" in
+
+
+
+Crispin [Page 33]
+
+RFC 1730 IMAP4 December 1994
+
+
+ the data item name prevents the untagged FETCH, and the server
+ should assume that the client has determined the updated value
+ itself or does not care about the updated value.
+
+ The currently defined data items that can be stored are:
+
+ FLAGS <flag list>
+ Replace the flags for the message with the
+ argument. The new value of the flags are returned
+ as if a FETCH of those flags was done.
+
+ FLAGS.SILENT <flag list>
+ Equivalent to FLAGS, but without returning a new
+ value.
+
+ +FLAGS <flag list>
+ Add the argument to the flags for the message. The
+ new value of the flags are returned as if a FETCH
+ of those flags was done.
+
+ +FLAGS.SILENT <flag list>
+ Equivalent to +FLAGS, but without returning a new
+ value.
+
+ -FLAGS <flag list>
+ Remove the argument from the flags for the message.
+ The new value of the flags are returned as if a
+ FETCH of those flags was done.
+
+ -FLAGS.SILENT <flag list>
+ Equivalent to -FLAGS, but without returning a new
+ value.
+
+
+ Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
+ S: * 2 FETCH FLAGS (\Deleted \Seen)
+ S: * 3 FETCH FLAGS (\Deleted)
+ S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
+ S: A003 OK STORE completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 34]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.4.8. COPY Command
+
+ Arguments: message set
+ mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - copy completed
+ NO - copy error: can't copy those messages or to that
+ name
+ BAD - command unknown or arguments invalid
+
+ The COPY command copies the specified message(s) to the specified
+ destination mailbox. The flags and internal date of the
+ message(s) SHOULD be preserved in the copy.
+
+ If the destination mailbox does not exist, a server SHOULD return
+ an error. It SHOULD 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 COPY if
+ the CREATE is successful.
+
+ If the COPY command is unsuccessful for any reason, server
+ implementations MUST restore the destination mailbox to its state
+ before the COPY attempt.
+
+ Example: C: A003 COPY 2:4 MEETING
+ S: A003 OK COPY completed
+
+
+6.4.9. UID Command
+
+ Arguments: command name
+ command arguments
+
+ Data: untagged responses: FETCH, SEARCH
+
+ Result: OK - UID command completed
+ NO - UID command error
+ BAD - command unknown or arguments invalid
+
+ The UID command has two forms. In the first form, it takes as its
+ arguments a COPY, FETCH, or STORE command with arguments
+ appropriate for the associated command. However, the numbers in
+ the message set argument are unique identifiers instead of message
+ sequence numbers.
+
+
+
+Crispin [Page 35]
+
+RFC 1730 IMAP4 December 1994
+
+
+ In the second form, the UID command takes a SEARCH command with
+ SEARCH command arguments. The interpretation of the arguments is
+ the same as with SEARCH; however, the numbers returned in a SEARCH
+ response for a UID SEARCH command are unique identifiers instead
+ of message sequence numbers. For example, the command UID SEARCH
+ 1:100 UID 443:557 returns the unique identifiers corresponding to
+ the intersection of the message sequence number set 1:100 and the
+ UID set 443:557.
+
+ A unique identifier of a message is a number, and is guaranteed
+ not to refer to any other message in the mailbox. Unique
+ identifiers are assigned in a strictly ascending fashion for each
+ message added to the mailbox. Unlike message sequence numbers,
+ unique identifiers persist across sessions. This permits a client
+ to resynchronize its state from a previous session with the server
+ (e.g. disconnected or offline access clients); this is discussed
+ further in [IMAP-DISC].
+
+ Associated with every mailbox is a unique identifier validity
+ value, which is sent in an UIDVALIDITY response code in an OK
+ untagged response at message selection time. If unique
+ identifiers from an earlier session fail to persist to this
+ session, the unique identifier validity value MUST be greater than
+ in the earlier session.
+
+ Note: An example of a good value to use for the unique
+ identifier validity value would be a 32-bit
+ representation of the creation date/time of the mailbox.
+ It is alright to use a constant such as 1, but only if
+ it guaranteed that unique identifers will never be
+ reused, even in the case of a mailbox being deleted and
+ a new mailbox by the same name created at some future
+ time.
+
+
+ Message set ranges are permitted; however, there is no guarantee
+ that unique identifiers be contiguous. A non-existent unique
+ identifier within a message set range is ignored without any error
+ message generated.
+
+ The number after the "*" in an untagged FETCH response is always a
+ message sequence number, not a unique identifier, even for a UID
+ command response. However, server implementations MUST implicitly
+ include the UID message data item as part of any FETCH response
+ caused by a UID command, regardless of whether UID was specified
+ as a message data item to the FETCH.
+
+
+
+
+
+Crispin [Page 36]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Example: C: A003 UID FETCH 4827313:4828442 FLAGS
+ S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
+ S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
+ S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
+ S: A999 UID FETCH completed
+
+
+
+6.5. Client Commands - Experimental/Expansion
+
+
+6.5.1. X<atom> Command
+
+ Arguments: implementation defined
+
+ Data: implementation defined
+
+ Result: OK - command completed
+ NO - failure
+ BAD - command unknown or arguments invalid
+
+ Any command prefixed with an X is an experimental command.
+ Commands which are not part of this specification, or a standard
+ or standards-track revision of this specification, MUST use the X
+ prefix.
+
+ Any added untagged responses issued by an experimental command
+ MUST also be prefixed with an X. Server implementations MUST NOT
+ send any such untagged responses, unless the client requested it
+ by issuing the associated experimental command.
+
+ Example: C: a441 CAPABILITY
+ S: * CAPABILITY IMAP4 XPIG-LATIN
+ S: a441 OK CAPABILITY completed
+ C: A442 XPIG-LATIN
+ S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
+ S: A442 OK XPIG-LATIN ompleted-cay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 37]
+
+RFC 1730 IMAP4 December 1994
+
+
+7. Server Responses
+
+ Server responses are in three forms: status responses, server data,
+ and command continuation request.
+
+ Server response data, identified by "Data:" in the response
+ descriptions below, are described by function, not by syntax. The
+ precise syntax of server response data is described in the Formal
+ Syntax section.
+
+ The client MUST be prepared to accept any response at all times.
+
+ Status responses that are tagged indicate the completion result of a
+ client command, and have a tag matching the command.
+
+ Some status responses, and all server data, are untagged. An
+ untagged response is indicated by the token "*" instead of a tag.
+ Untagged status responses indicate server greeting, or server status
+ that does not indicate the completion of a command. For historical
+ reasons, untagged server data responses are also called "unsolicited
+ data", although strictly speaking only unilateral server data is
+ truly "unsolicited".
+
+ Certain server data MUST be recorded by the client when it is
+ received; this is noted in the description of that data. Such data
+ conveys critical information which affects the interpretation of all
+ subsequent commands and responses (e.g. updates reflecting the
+ creation or destruction of messags).
+
+ Other server data SHOULD be recorded for later reference; if the
+ client does not need to record the data, or if recording the data has
+ no obvious purpose (e.g. a SEARCH response when no SEARCH command is
+ in progress), the data SHOULD be ignored.
+
+ An example of unilateral untagged responses occurs when the IMAP
+ connection is in selected state. In selected state, the server
+ checks the mailbox for new messages as part of the execution of each
+ command. If new messages are found, the server sends untagged EXISTS
+ and RECENT responses reflecting the new size of the mailbox. Server
+ implementations that offer multiple simultaneous access to the same
+ mailbox should also send appropriate unilateral untagged FETCH and
+ EXPUNGE responses if another agent changes the state of any message
+ flags or expunges any messages.
+
+ Command continuation request responses use the token "+" instead of a
+ tag. These responses are sent by the server to indicate acceptance
+ of an incomplete client command and readiness for the remainder of
+ the command.
+
+
+
+Crispin [Page 38]
+
+RFC 1730 IMAP4 December 1994
+
+
+7.1. Server Responses - Status Responses
+
+ Status responses may include an optional response code. A response
+ code consists of data inside square brackets in the form of an atom,
+ possibly followed by a space and arguments. The response code
+ contains additional information or status codes for client software
+ beyond the OK/NO/BAD condition, and are defined when there is a
+ specific action that a client can take based upon the additional
+ information.
+
+ The currently defined response codes are:
+
+ ALERT The human-readable text contains a special alert
+ that MUST be presented to the user in a fashion
+ that calls the user's attention to the message.
+
+ PARSE The human-readable text represents an error in
+ parsing the [RFC-822] or [MIME-1] headers of a
+ message in the mailbox.
+
+ PERMANENTFLAGS Followed by a parenthesized list of flags,
+ indicates which of the known flags that the client
+ may change permanently. Any flags that are in the
+ FLAGS untagged response, but not the PERMANENTFLAGS
+ list, can not be set permanently. If the client
+ attempts to STORE a flag that is not in the
+ PERMANENTFLAGS list, the server will either reject
+ it with a NO reply or store the state for the
+ remainder of the current session only. The
+ PERMANENTFLAGS list may also include the special
+ flag \*, which indicates that it is possible to
+ create new keywords by attempting to store those
+ flags in the mailbox.
+
+ READ-ONLY The mailbox is selected read-only, or its access
+ while selected has changed from read-write to
+ read-only.
+
+ READ-WRITE The mailbox is selected read-write, or its access
+ while selected has changed from read-only to
+ read-write.
+
+ TRYCREATE An APPEND or COPY attempt is failing because the
+ target mailbox does not exist (as opposed to some
+ other reason). This is a hint to the client that
+ the operation may succeed if the mailbox is first
+ created by the CREATE command.
+
+
+
+
+Crispin [Page 39]
+
+RFC 1730 IMAP4 December 1994
+
+
+ UIDVALIDITY Followed by a decimal number, indicates the unique
+ identifier validity value. See the description of
+ the UID command for more detail.
+
+ UNSEEN Followed by a decimal number, indicates the number
+ of the first message without the \Seen flag set.
+
+ Additional response codes defined by particular client or server
+ implementations should be prefixed with an "X" until they are
+ added to a revision of this protocol. Client implementations
+ should ignore response codes that they do not recognize.
+
+
+7.1.1. OK Response
+
+ Data: optional response code
+ human-readable text
+
+ The OK response indicates an information message from the server.
+ When tagged, it indicates successful completion of the associated
+ command. The human-readable text may be presented to the user as
+ an information message. The untagged form indicates an
+ information-only message; the nature of the information may be
+ indicated by a response code.
+
+ The untagged form is also used as one of three possible greetings
+ at session startup. It indicates that the session is not yet
+ authenticated and that a LOGIN command is needed.
+
+ Example: S: * OK IMAP4 server ready
+ C: A001 LOGIN fred blurdybloop
+ S: * OK [ALERT] System shutdown in 10 minutes
+ S: A001 OK LOGIN Completed
+
+
+7.1.2. NO Response
+
+ Data: optional response code
+ human-readable text
+
+ The NO response indicates an operational error message from the
+ server. When tagged, it indicates unsuccessful completion of the
+ associated command. The untagged form indicates a warning; the
+ command may still complete successfully. The human-readable text
+ describes the condition.
+
+
+
+
+
+
+Crispin [Page 40]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Example: C: A222 COPY 1:2 owatagusiam
+ S: * NO Disk is 98% full, please delete unnecessary data
+ S: A222 OK COPY completed
+ C: A222 COPY 3:200 blurdybloop
+ S: * NO Disk is 98% full, please delete unnecessary data
+ S: * NO Disk is 99% full, please delete unnecessary data
+ S: A222 NO COPY failed: disk is full
+
+
+7.1.3. BAD Response
+
+ Data: optional response code
+ human-readable text
+
+ The BAD response indicates an error message from the server. When
+ tagged, it reports a protocol-level error in the client's command;
+ the tag indicates the command that caused the error. The untagged
+ form indicates a protocol-level error for which the associated
+ command can not be determined; it may also indicate an internal
+ server failure. The human-readable text describes the condition.
+
+ Example: C: ...very long command line...
+ S: * BAD Command line too long
+ C: ...empty line...
+ S: * BAD Empty command line
+ C: A443 EXPUNGE
+ S: * BAD Disk crash, attempting salvage to a new disk!
+ S: * OK Salvage successful, no data lost
+ S: A443 OK Expunge completed
+
+
+7.1.4. PREAUTH Response
+
+ Data: optional response code
+ human-readable text
+
+ The PREAUTH response is always untagged, and is one of three
+ possible greetings at session startup. It indicates that the
+ session has already been authenticated by external means and thus
+ no LOGIN command is needed.
+
+ Example: S: * PREAUTH IMAP4 server ready and logged in as Smith
+
+
+
+
+
+
+
+
+
+Crispin [Page 41]
+
+RFC 1730 IMAP4 December 1994
+
+
+7.1.5. BYE Response
+
+ Data: optional response code
+ human-readable text
+
+ The BYE response is always untagged, and indicates that the server
+ is about to close the connection. The human-readable text may be
+ displayed to the user in a status report by the client. The BYE
+ response may be sent as part of a normal logout sequence, or as a
+ panic shutdown announcement by the server. It is also used by
+ some server implementations as an announcement of an inactivity
+ autologout.
+
+ This response is also used as one of three possible greetings at
+ session startup. It indicates that the server is not willing to
+ accept a session from this client.
+
+ Example: S: * BYE Autologout; idle for too long
+
+
+
+7.2. Server Responses - Server and Mailbox Status
+
+ These responses are always untagged. This is how server data are
+ transmitted from the server to the client, often as a result of a
+ command with the same name.
+
+7.2.1. CAPABILITY Response
+
+ Data: capability listing
+
+ The CAPABILITY response occurs as a result of a CAPABILITY
+ command. The capability listing contains a space-separated
+ listing of capability names that the server supports. The first
+ name in the capability listing MUST be the atom "IMAP4".
+
+ A capability name other than IMAP4 indicates that the server
+ supports an extension, revision, or amendment to the IMAP4
+ protocol. Server responses MUST conform to this document until
+ the client issues a command that uses the associated capability.
+
+ Capability names MUST either begin with "X" or be standard or
+ standards-track IMAP4 extensions, revisions, or amendments
+ registered with IANA. A server MUST NOT offer unregistered or
+ non-standard capability names, unless such names are prefixed with
+ an "X".
+
+
+
+
+
+Crispin [Page 42]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Client implementations SHOULD NOT require any capability name
+ other than "IMAP4", and MUST ignore any unknown capability names.
+
+ Example: S: * CAPABILITY IMAP4 XPIG-LATIN
+
+
+7.2.2. LIST Response
+
+ Data: name attributes
+ hierarchy delimiter
+ name
+
+ The LIST response occurs as a result of a LIST command. It
+ returns a single name that matches the LIST specification. There
+ may be multiple LIST responses for a single LIST command.
+
+ Four name attributes are defined:
+
+ \Noinferiors It is not possible for any child levels of
+ hierarchy to exist under this name; no child levels
+ exist now and none can be created in the future.
+
+ \Noselect It is not possible to use this name as a selectable
+ mailbox.
+
+ \Marked The mailbox has been marked "interesting" by the
+ server; the mailbox probably contains messages that
+ have been added since the last time the mailbox was
+ selected.
+
+ \Unmarked The mailbox does not contain any additional
+ messages since the last time the mailbox was
+ selected.
+
+ If it is not feasible for the server to determine whether the
+ mailbox is "interesting" or not, or if the name is a \Noselect
+ name, the server should not send either \Marked or \Unmarked.
+
+ The hierarchy delimiter is a character used to delimit levels of
+ hierarchy in a mailbox name. A client may use it to create child
+ mailboxes, and to search higher or lower levels of naming
+ hierarchy. All children of a top-level hierarchy node must use
+ the same separator character. A NIL hierarchy delimiter means
+ that no hierarchy exists; the name is a "flat" name.
+
+
+
+
+
+
+
+Crispin [Page 43]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The name represents an unambiguous left-to-right hierarchy, and
+ MUST be valid for use as a reference in LIST and LSUB commands.
+ Unless \Noselect is indicated, the name must also be valid as an
+ argument for commands, such as SELECT, that accept mailbox names.
+
+ Example: S: * LIST (\Noselect) "/" ~/Mail/foo
+
+
+7.2.3. LSUB Response
+
+ Data: name attributes
+ hierarchy delimiter
+ name
+
+ The LSUB response occurs as a result of an LSUB command. It
+ returns a single name that matches the LSUB specification. There
+ may be multiple LSUB responses for a single LSUB command. The
+ data is identical in format to the LIST response.
+
+ Example: S: * LSUB () "." #news.comp.mail.misc
+
+
+7.2.4. SEARCH Response
+
+ Data: zero or more numbers
+
+ The SEARCH response occurs as a result of a SEARCH or UID SEARCH
+ command. The number(s) refer to those messages that match the
+ search criteria. For SEARCH, these are message sequence numbers;
+ for UID SEARCH, these are unique identifiers. Each number is
+ delimited by a space.
+
+ Example: S: * SEARCH 2 3 6
+
+
+7.2.5. FLAGS Response
+
+ Data: flag parenthesized list
+
+ The FLAGS response occurs as a result of a SELECT or EXAMINE
+ command. The flag parenthesized list identifies the flags (at a
+ minimum, the system-defined flags) that are applicable for this
+ mailbox. Flags other than the system flags may also exist,
+ depending on server implementation.
+
+ The update from the FLAGS response MUST be recorded by the client.
+
+ Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+
+
+
+Crispin [Page 44]
+
+RFC 1730 IMAP4 December 1994
+
+
+7.3. Server Responses - Message Status
+
+ These responses are always untagged. This is how message data are
+ transmitted from the server to the client, often as a result of a
+ command with the same name. Immediately following the "*" token is a
+ number that represents either a message sequence number or a message
+ count.
+
+7.3.1. EXISTS Response
+
+ Data: none
+
+ The EXISTS response reports the number of messages in the mailbox.
+ This response occurs as a result of a SELECT or EXAMINE command,
+ and if the size of the mailbox changes (e.g. new mail).
+
+ The update from the EXISTS response MUST be recorded by the
+ client.
+
+ Example: S: * 23 EXISTS
+
+
+7.3.2. RECENT Response
+
+ Data: none
+
+ The RECENT response reports the number of messages that have
+ arrived since the previous time a SELECT command was done on this
+ mailbox. This response occurs as a result of a SELECT or EXAMINE
+ command, and if the size of the mailbox changes (e.g. new mail).
+
+ The update from the RECENT response MUST be recorded by the
+ client.
+
+ Example: S: * 5 RECENT
+
+
+7.3.3. EXPUNGE Response
+
+ Data: none
+
+ The EXPUNGE response reports that the specified message sequence
+ number has been permanently removed from the mailbox. The message
+ sequence number for each successive message in the mailbox is
+ immediately decremented by 1, and this decrement is reflected in
+ message sequence numbers in subsequent responses (including other
+ untagged EXPUNGE responses).
+
+
+
+
+Crispin [Page 45]
+
+RFC 1730 IMAP4 December 1994
+
+
+ As a result of the immediate decrement rule, message sequence
+ numbers that appear in a set of successive EXPUNGE responses
+ depend upon whether the messages are removed starting from lower
+ numbers to higher numbers, or from higher numbers to lower
+ numbers. For example, if the last 5 messages in a 9-message
+ mailbox are expunged; a "lower to higher" server will send five
+ untagged EXPUNGE responses for message sequence number 5, whereas
+ a "higher to lower server" will send successive untagged EXPUNGE
+ responses for message sequence numbers 9, 8, 7, 6, and 5.
+
+ An EXPUNGE response MUST NOT be sent when no command is in
+ progress; nor while responding to a FETCH, STORE, or SEARCH
+ command. This rule is necessary to prevent a loss of
+ synchronization of message sequence numbers between client and
+ server.
+
+ The update from the EXPUNGE response MUST be recorded by the
+ client.
+
+ Example: S: * 44 EXPUNGE
+
+
+7.3.4. FETCH Response
+
+ Data: message data
+
+ The FETCH response returns data about a message to the client.
+ The data are pairs of data item names and their values in
+ parentheses. This response occurs as the result of a FETCH or
+ STORE command, as well as by unilateral server decision (e.g. flag
+ updates).
+
+ The current data items are:
+
+ BODY A form of BODYSTRUCTURE without extension data.
+
+ BODY[section] A string expressing the body contents of the
+ specified section. The string should be
+ interpreted by the client according to the content
+ transfer encoding, body type, and subtype.
+
+ 8-bit textual data is permitted if a character set
+ identifier is part of the body parameter
+ parenthesized list for this section.
+
+ Non-textual data such as binary data must be
+ transfer encoded into a textual form such as BASE64
+ prior to being sent to the client. To derive the
+
+
+
+Crispin [Page 46]
+
+RFC 1730 IMAP4 December 1994
+
+
+ original binary data, the client must decode the
+ transfer encoded string.
+
+ BODYSTRUCTURE A parenthesized list that describes the body
+ structure of a message. This is computed by the
+ server by parsing the [RFC-822] header and body
+ into the component parts, defaulting various fields
+ as necessary.
+
+ Multiple parts are indicated by parenthesis
+ nesting. Instead of a body type as the first
+ element of the parenthesized list there is a nested
+ body. The second element of the parenthesized list
+ is the multipart subtype (mixed, digest, parallel,
+ alternative, etc.).
+
+ Extension data follows the multipart subtype.
+ Extension data is never returned with the BODY
+ fetch, but may be returned with a BODYSTRUCTURE
+ fetch. Extension data, if present, must be in the
+ defined order.
+
+ The extension data of a multipart body part are in
+ the following order:
+
+ body parameter parenthesized list
+ A parenthesized list of attribute/value pairs
+ [e.g. (foo bar baz rag) where "bar" is the value
+ of "foo" and "rag" is the value of "baz"] as
+ defined in [MIME-1].
+
+ Any following extension data are not yet defined in
+ this version of the protocol. Such extension data
+ may consist of zero or more NILs, strings, numbers,
+ or potentially nested parenthesized lists of such
+ data. Client implementations that do a
+ BODYSTRUCTURE fetch MUST be prepared to accept such
+ extension data. Server implementations MUST NOT
+ send such extension data until it has been defined
+ by a revision of this protocol.
+
+ The basic fields of a non-multipart body part are
+ in the following order:
+
+ body type
+ A string giving the content type name as defined
+ in [MIME-1].
+
+
+
+
+Crispin [Page 47]
+
+RFC 1730 IMAP4 December 1994
+
+
+ body subtype
+ A string giving the content subtype name as
+ defined in [MIME-1].
+
+ body parameter parenthesized list
+ A parenthesized list of attribute/value pairs
+ [e.g. (foo bar baz rag) where "bar" is the value
+ of "foo" and "rag" is the value of "baz"] as
+ defined in [MIME-1].
+
+ body id
+ A string giving the content id as defined in
+ [MIME-1].
+
+ body description
+ A string giving the content description as
+ defined in [MIME-1].
+
+ body encoding
+ A string giving the content transfer encoding as
+ defined in [MIME-1].
+
+ body size
+ A number giving the size of the body in octets.
+ Note that this size is the size in its transfer
+ encoding and not the resulting size after any
+ decoding.
+
+ A body type of type MESSAGE and subtype RFC822
+ contains, immediately after the basic fields, the
+ envelope structure, body structure, and size in
+ text lines of the encapsulated message.
+
+ A body type of type TEXT contains, immediately
+ after the basic fields, the size of the body in
+ text lines. Note that this size is the size in its
+ transfer encoding and not the resulting size after
+ any decoding.
+
+ Extension data follows the basic fields and the
+ type-specific fields listed above. Extension data
+ is never returned with the BODY fetch, but may be
+ returned with a BODYSTRUCTURE fetch. Extension
+ data, if present, must be in the defined order.
+
+ The extension data of a non-multipart body part are
+ in the following order:
+
+
+
+
+Crispin [Page 48]
+
+RFC 1730 IMAP4 December 1994
+
+
+ body MD5
+ A string giving the content MD5 value as defined
+ in [MIME-1].
+
+ Any following extension data are not yet defined in
+ this version of the protocol, and would be as
+ described above under multipart extension data.
+
+ ENVELOPE A parenthesized list that describes the envelope
+ structure of a message. This is computed by the
+ server by parsing the [RFC-822] header into the
+ component parts, defaulting various fields as
+ necessary.
+
+ The fields of the envelope structure are in the
+ following order: date, subject, from, sender,
+ reply-to, to, cc, bcc, in-reply-to, and message-id.
+ The date, subject, in-reply-to, and message-id
+ fields are strings. The from, sender, reply-to,
+ to, cc, and bcc fields are parenthesized lists of
+ address structures.
+
+ An address structure is a parenthesized list that
+ describes an electronic mail address. The fields
+ of an address structure are in the following order:
+ personal name, [SMTP] at-domain-list (source
+ route), mailbox name, and host name.
+
+ [RFC-822] group syntax is indicated by a special
+ form of address structure in which the host name
+ field is NIL. If the mailbox name field is also
+ NIL, this is an end of group marker (semi-colon in
+ RFC 822 syntax). If the mailbox name field is
+ non-NIL, this is a start of group marker, and the
+ mailbox name field holds the group name phrase.
+
+ Any field of an envelope or address structure that
+ is not applicable is presented as NIL. Note that
+ the server must default the reply-to and sender
+ fields from the from field; a client is not
+ expected to know to do this.
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 49]
+
+RFC 1730 IMAP4 December 1994
+
+
+ FLAGS A parenthesized list of flags that are set for this
+ message. This may include keywords as well as the
+ following system flags:
+
+ \Seen Message has been read
+
+ \Answered Message has been answered
+
+ \Flagged Message is "flagged" for urgent/special
+ attention
+
+ \Deleted Message is "deleted" for removal by
+ later EXPUNGE
+
+ \Draft Message has not completed composition
+ (marked as a draft).
+
+ as well as the following special flag, which may be
+ fetched but not stored:
+
+ \Recent Message has arrived since the previous
+ time this mailbox was selected.
+
+ INTERNALDATE A string containing the date and time of final
+ delivery of the message as defined by [SMTP].
+
+ RFC822 A string expressing the message in [RFC-822]
+ format. The header portion of the message must be
+ 7-bit. 8-bit characters are permitted only in the
+ non-header portion of the message only if there are
+ [MIME-1] data in the message that identify the
+ character set of the message.
+
+ RFC822.HEADER A string expressing the [RFC-822] format header of
+ the message, including the delimiting blank line
+ between the header and the body. The entire string
+ must be 7-bit; 8-bit characters are not permitted
+ in headers. RFC822.HEADER is used to return data
+ for the RFC822.HEADER, RFC822.HEADER.LINES, and
+ RFC822.HEADER.LINES.NOT FETCH data items. Note
+ that a blank line is always included regardless of
+ header line restrictions.
+
+ RFC822.SIZE A number expressing the number of octets in the
+ message in [RFC-822] format.
+
+
+
+
+
+
+Crispin [Page 50]
+
+RFC 1730 IMAP4 December 1994
+
+
+ RFC822.TEXT A string expressing the text body of the message,
+ omitting the [RFC-822] header. 8-bit characters
+ are permitted only if there are [MIME-1] data in
+ the message that identify the character set of the
+ message.
+
+ UID A number expressing the unique identifier of the
+ message.
+
+
+ Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
+
+
+7.3.5. Obsolete Responses
+
+ In addition to the responses listed in here, client implementations
+ MUST accept and implement the obsolete responses described in
+ Appendix B.
+
+
+
+7.4. Server Responses - Command Continuation Request
+
+ The command completion request response is indicated by a "+" token
+ instead of a tag. This form of response indicates that the server is
+ ready to accept the continuation of a command from the client. The
+ remainder of this response is a line of text.
+
+ This response is used in the AUTHORIZATION command to transmit server
+ data to the client, and request additional client data. This
+ response is also used if an argument to any command is a literal.
+
+ The client is not permitted to send the octets of the literal unless
+ the server indicates that it expects it. This permits the server to
+ process commands and reject errors on a line-by-line basis. The
+ remainder of the command, including the CRLF that terminates a
+ command, follows the octets of the literal. If there are any
+ additional command arguments the literal octets are followed by a
+ space and those arguments.
+
+ Example: C: A001 LOGIN {11}
+ S: + Ready for additional command text
+ C: FRED FOOBAR {7}
+ S: + Ready for additional command text
+ C: fat man
+ S: A001 OK LOGIN completed
+ C: A044 BLURDYBLOOP {102856}
+ S: A044 BAD No such command as "BLURDYBLOOP"
+
+
+
+Crispin [Page 51]
+
+RFC 1730 IMAP4 December 1994
+
+
+8. Sample IMAP4 session
+
+ The following is a transcript of an IMAP4 session. A long line in
+ this sample is broken for editorial clarity.
+
+ S: * OK IMAP4 Service Ready
+ C: a001 login mrc secret
+ S: a001 OK LOGIN completed
+ C: a002 select inbox
+ S: * 18 EXISTS
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * 2 RECENT
+ S: * OK [UNSEEN 17] Message 17 is the first unseen message
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: a002 OK [READ-WRITE] SELECT completed
+ C: a003 fetch 12 full
+ S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
+ RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
+ "IMAP4 WG mtg summary and minutes"
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ ((NIL NIL "imap" "cac.washington.edu"))
+ ((NIL NIL "minutes" "CNRI.Reston.VA.US")
+ ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
+ "<B27397-0100000@cac.washington.edu>")
+ BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
+ S: a003 OK FETCH completed
+ C: a004 fetch 12 rfc822.header
+ S: * 12 FETCH (RFC822.HEADER {346}
+ S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
+ S: From: Terry Gray <gray@cac.washington.edu>
+ S: Subject: IMAP4 WG mtg summary and minutes
+ S: To: imap@cac.washington.edu
+ S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
+ S: Message-Id: <B27397-0100000@cac.washington.edu>
+ S: MIME-Version: 1.0
+ S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+ S:
+ S: )
+ S: a004 OK FETCH completed
+ C: a005 store 12 +flags \deleted
+ S: * 12 FETCH (FLAGS (\Seen \Deleted))
+ S: a005 OK +FLAGS completed
+ C: a006 logout
+ S: * BYE IMAP4 server terminating connection
+ S: a006 OK LOGOUT completed
+
+
+
+
+Crispin [Page 52]
+
+RFC 1730 IMAP4 December 1994
+
+
+9. 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 (SPACE) and
+ not a comma.
+
+ 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.
+
+ Syntax marked as obsolete may be encountered with implementations
+ written for an earlier version of this protocol (e.g. IMAP2). New
+ implementations SHOULD accept obsolete syntax as input, but MUST NOT
+ otherwise use such syntax.
+
+ address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
+ SPACE addr_host ")"
+
+ addr_adl ::= nstring
+
+ addr_host ::= nstring
+ ;; NIL indicates [RFC-822] group syntax
+
+ addr_mailbox ::= nstring
+ ;; NIL indicates end of [RFC-822] group; if
+ ;; non-NIL and addr_host is NIL, holds
+ ;; [RFC-822] group name
+
+ addr_name ::= nstring
+
+ alpha ::= "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" /
+ ;; Case-sensitive
+
+ append ::= "APPEND" SPACE mailbox [SPACE flag_list]
+ [SPACE date_time] SPACE literal
+
+ astring ::= atom / string
+
+
+
+
+
+Crispin [Page 53]
+
+RFC 1730 IMAP4 December 1994
+
+
+ atom ::= 1*ATOM_CHAR
+
+ ATOM_CHAR ::= <any CHAR except atom_specials>
+
+ atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /
+ quoted_specials
+
+ authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
+
+ auth_type ::= atom
+
+ base64 ::= *(4base64_char) [base64_terminal]
+
+ base64_char ::= alpha / digit / "+" / "/"
+
+ base64_terminal ::= (2base64_char "==") / (3base64_char "=")
+
+ body ::= "(" body_type_1part / body_type_mpart ")"
+
+ body_extension ::= nstring / number / "(" 1#body_extension ")"
+ ;; Future expansion. Client implementations
+ ;; MUST accept body_extension fields. Server
+ ;; implementations MUST NOT generate
+ ;; body_extension fields except as defined by
+ ;; future standard or standards-track
+ ;; revisions of this specification.
+
+ body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension]
+ ;; MUST NOT be returned on non-extensible
+ ;; "BODY" fetch
+
+ body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]]
+ ;; MUST NOT be returned on non-extensible
+ ;; "BODY" fetch
+
+ body_fields ::= body_fld_param SPACE body_fld_id SPACE
+ body_fld_desc SPACE body_fld_enc SPACE
+ body_fld_octets
+
+ body_fld_desc ::= nstring
+
+ body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
+ "QUOTED-PRINTABLE") <">) / string
+
+ body_fld_id ::= nstring
+
+ body_fld_lines ::= number
+
+
+
+
+Crispin [Page 54]
+
+RFC 1730 IMAP4 December 1994
+
+
+ body_fld_md5 ::= nstring
+
+ body_fld_octets ::= number
+
+ body_fld_param ::= "(" 1#(string string) ")" / nil
+
+ body_fld_subtyp ::= string
+
+ body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
+ [SPACE body_ext_1part]
+
+ body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
+ "MESSAGE" / "VIDEO") <">) / string) SPACE
+ body_fld_subtyp SPACE body_fields
+ ;; MESSAGE subtype MUST NOT be "RFC822"
+
+ body_type_mpart ::= 1*body SPACE body_fld_subtyp
+ [SPACE body_ext_mpart]
+
+ body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE
+ body_fields SPACE envelope SPACE body SPACE
+ body_fld_lines
+
+ body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE
+ body_fields SPACE body_fld_lines
+
+ capability ::= atom
+ ;; Must begin with "X" or be registered with
+ ;; IANA as standard or standards-track
+
+ capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
+
+ CHAR ::= <any 7-bit US-ASCII character except NUL,
+ 0x01 - 0x7f>
+
+ CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff>
+
+ command ::= tag SPACE (command_any / command_auth /
+ command_nonauth / command_select) CRLF
+ ;; Modal based on state
+
+ command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
+ ;; Valid in all states
+
+ command_auth ::= append / create / delete / examine / find / list /
+ lsub / rename / select / subscribe / unsubscribe /
+ ;; Valid only in Authenticated or Selected state
+
+
+
+
+Crispin [Page 55]
+
+RFC 1730 IMAP4 December 1994
+
+
+ command_nonauth ::= login / authenticate
+ ;; Valid only when in Non-Authenticated state
+
+ command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /
+ copy / fetch / partial / store / uid / search
+ ;; Valid only when in Selected state
+
+ continue_req ::= "+" SPACE (resp_text / base64)
+
+ copy ::= "COPY" SPACE set SPACE mailbox
+
+ CR ::= <ASCII CR, carriage return, 0x0C>
+
+ create ::= "CREATE" SPACE mailbox
+ ;; Use of INBOX gives a NO error
+
+ CRLF ::= CR LF
+
+ CTL ::= <any ASCII control character and DEL,
+ 0x00 - 0x1f, 0x7f>
+
+ date ::= date_text / <"> date_text <">
+
+ date_day ::= 1*2digit
+ ;; Day of month
+
+ date_day_fixed ::= (SPACE digit) / 2digit
+ ;; Fixed-format version of date_day
+
+ date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
+ "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
+
+ date_text ::= date_day "-" date_month "-" (date_year /
+ date_year_old)
+
+ date_year ::= 4digit
+
+ date_year_old ::= 2digit
+ ;; OBSOLETE, (year - 1900)
+
+ date_time ::= <"> (date_time_new / date_time_old) <">
+
+ date_time_new ::= date_day_fixed "-" date_month "-" date_year
+ SPACE time SPACE zone
+
+ date_time_old ::= date_day_fixed "-" date_month "-" date_year_old
+ SPACE time "-" zone_old
+ ;; OBSOLETE
+
+
+
+Crispin [Page 56]
+
+RFC 1730 IMAP4 December 1994
+
+
+ delete ::= "DELETE" SPACE mailbox
+ ;; Use of INBOX gives a NO error
+
+ digit ::= "0" / digit_nz
+
+ digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
+ "9"
+
+ envelope ::= "(" env_date SPACE env_subject SPACE env_from
+ SPACE env_sender SPACE env_reply-to SPACE env_to
+ SPACE env_cc SPACE env_bcc SPACE env_in-reply-to
+ SPACE env_message-id ")"
+
+ env_bcc ::= "(" 1*address ")" / nil
+
+ env_cc ::= "(" 1*address ")" / nil
+
+ env_date ::= nstring
+
+ env_from ::= "(" 1*address ")" / nil
+
+ env_in-reply-to ::= nstring
+
+ env_message-id ::= nstring
+
+ env_reply-to ::= "(" 1*address ")" / nil
+
+ env_sender ::= "(" 1*address ")" / nil
+
+ env_subject ::= nstring
+
+ env_to ::= "(" 1*address ")" / nil
+
+ examine ::= "EXAMINE" SPACE mailbox
+
+ fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
+ "FAST" / fetch_att / "(" 1#fetch_att ")")
+
+ fetch_att ::= "BODY" / "BODYSTRUCTURE" /
+ "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /
+ "FLAGS" / "INTERNALDATE" / "UID" /
+ "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /
+ (".HEADER" [".LINES" [".NOT"] SPACE header_list])
+
+ find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
+ list_mailbox
+ ;; OBSOLETE
+
+
+
+
+Crispin [Page 57]
+
+RFC 1730 IMAP4 December 1994
+
+
+ flag ::= "\Answered" / "\Flagged" / "\Deleted" /
+ "\Seen" / "\Draft" / flag_keyword /
+ flag_extension
+
+ flag_extension ::= "\" atom
+ ;; Future expansion. Client implementations
+ ;; MUST accept flag_extension flags. Server
+ ;; implementations MUST NOT generate
+ ;; flag_extension flags except as defined by
+ ;; future standard or standards-track
+ ;; revisions of this specification.
+
+ flag_keyword ::= atom
+
+ flag_list ::= "(" #flag ")"
+
+ greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
+
+ header_line ::= astring
+
+ header_list ::= "(" 1#header_line ")"
+
+ LF ::= <ASCII LF, line feed, 0x0A>
+
+ list ::= "LIST" SPACE mailbox SPACE list_mailbox
+
+ list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string
+
+ list_wildcards ::= "%" / "*"
+
+ literal ::= "{" number "}" CRLF *CHAR8
+ ;; Number represents the number of CHAR8 octets
+
+ login ::= "LOGIN" SPACE userid SPACE password
+
+ lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox
+
+ mailbox ::= "INBOX" / astring
+ ;; INBOX is case-insensitive; other names may be
+ ;; case-sensitive depending on implementation.
+
+ mailbox_data ::= "FLAGS" SPACE flag_list /
+ "LIST" SPACE mailbox_list /
+ "LSUB" SPACE mailbox_list /
+ "MAILBOX" SPACE text /
+ "SEARCH" [SPACE 1#nz_number] /
+ number SPACE "EXISTS" / number SPACE "RECENT"
+
+
+
+
+Crispin [Page 58]
+
+RFC 1730 IMAP4 December 1994
+
+
+ mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /
+ "\Noselect" / "\Unmarked" / flag_extension) ")"
+ SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
+
+ message_data ::= nz_number SPACE ("EXPUNGE" /
+ ("FETCH" SPACE msg_fetch) / msg_obsolete)
+
+ msg_fetch ::= "(" 1#("BODY" SPACE body /
+ "BODYSTRUCTURE" SPACE body /
+ "BODY[" section "]" SPACE nstring /
+ "ENVELOPE" SPACE envelope /
+ "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
+ "INTERNALDATE" SPACE date_time /
+ "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
+ "RFC822.SIZE" SPACE number /
+ "UID" SPACE uniqueid) ")"
+
+ msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch)
+ ;; OBSOLETE untagged data responses
+
+ nil ::= "NIL"
+
+ nstring ::= string / nil
+
+ number ::= 1*digit
+ ;; Unsigned 32-bit integer
+ ;; (0 <= n < 4,294,967,296)
+
+ nz_number ::= digit_nz *digit
+ ;; Non-zero unsigned 32-bit integer
+ ;; (0 < n < 4,294,967,296)
+
+ partial ::= "PARTIAL" SPACE nz_number SPACE
+ ("BODY" [".PEEK"] "[" section "]" /
+ "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")
+ SPACE number SPACE number
+
+ password ::= astring
+
+ quoted ::= <"> *QUOTED_CHAR <">
+
+ QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> /
+ "\" quoted_specials
+
+ quoted_specials ::= <"> / "\"
+
+ rename ::= "RENAME" SPACE mailbox SPACE mailbox
+ ;; Use of INBOX as a destination gives a NO error
+
+
+
+Crispin [Page 59]
+
+RFC 1730 IMAP4 December 1994
+
+
+ response ::= *response_data response_done
+
+ response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
+ mailbox_data / message_data / capability_data)
+ CRLF
+
+ response_done ::= response_tagged / response_fatal
+
+ response_fatal ::= "*" SPACE resp_cond_bye CRLF
+
+ response_tagged ::= tag SPACE resp_cond_state CRLF
+
+ resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
+ ;; Authentication condition
+
+ resp_cond_bye ::= "BYE" SPACE resp_text
+ ;; Server will disconnect condition
+
+ resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
+ ;; Status condition
+
+ resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
+
+ resp_text_code ::= "ALERT" / "PARSE" /
+ "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
+ "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
+ "UIDVALIDITY" SPACE nz_number /
+ "UNSEEN" SPACE nz_number /
+ atom [SPACE 1*<any TEXT_CHAR except "]">]
+
+ search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
+ search_criteria
+ ;; Character set must be registered with IANA
+ ;; as a MIME character set
+
+ search_criteria ::= 1#search_key
+
+ search_key ::= search_new / search_old
+
+ search_new ::= "DRAFT" /
+ "HEADER" SPACE header_line SPACE astring /
+ "LARGER" SPACE number / "NOT" SPACE search_key /
+ "OR" SPACE search_key SPACE search_key /
+ "SENTBEFORE" SPACE date / "SENTON" SPACE date /
+ "SENTSINCE" SPACE date / "SMALLER" SPACE number /
+ "UID" SPACE set / "UNDRAFT" / set /
+ "(" search_criteria ")"
+ ;; New in IMAP4
+
+
+
+Crispin [Page 60]
+
+RFC 1730 IMAP4 December 1994
+
+
+ search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
+ "BEFORE" SPACE date / "BODY" SPACE astring /
+ "CC" SPACE astring / "DELETED" / "FLAGGED" /
+ "FROM" SPACE astring /
+ "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
+ "ON" SPACE date / "RECENT" / "SEEN" /
+ "SINCE" SPACE date / "SUBJECT" SPACE astring /
+ "TEXT" SPACE astring / "TO" SPACE astring /
+ "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
+ "UNKEYWORD" SPACE flag_keyword / "UNSEEN"
+ ;; Defined in [IMAP2]
+
+ section ::= "0" / nz_number ["." section]
+
+ select ::= "SELECT" SPACE mailbox
+
+ sequence_num ::= nz_number / "*"
+ ;; * is the largest number in use. For message
+ ;; sequence numbers, it is the number of messages
+ ;; in the mailbox. For unique identifiers, it is
+ ;; the unique identifier of the last message in
+ ;; the mailbox.
+
+ set ::= sequence_num / (sequence_num ":" sequence_num) /
+ (set "," set)
+ ;; Identifies a set of messages. For message
+ ;; sequence numbers, these are consecutive
+ ;; numbers from 1 to the number of messages in
+ ;; the mailbox
+ ;; Comma delimits individual numbers, colon
+ ;; delimits between two numbers inclusive.
+ ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
+ ;; 14,15 for a mailbox with 15 messages.
+
+ SPACE ::= <ASCII SP, space, 0x20>
+
+ store ::= "STORE" SPACE set SPACE store_att_flags
+
+ store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
+ (flag_list / #flag)
+
+ string ::= quoted / literal
+
+ subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs
+
+ subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+ ;;OBSOLETE
+
+
+
+
+Crispin [Page 61]
+
+RFC 1730 IMAP4 December 1994
+
+
+ tag ::= 1*<any ATOM_CHAR except "+">
+
+ text ::= 1*TEXT_CHAR
+
+ text_mime2 ::= "=?" <charset> "?" <encoding> "?"
+ <encoded-text> "?="
+ ;; Syntax defined in [MIME-2]
+
+ TEXT_CHAR ::= <any CHAR except CR and LF>
+
+ time ::= 2digit ":" 2digit ":" 2digit
+ ;; Hours minutes seconds
+
+ uid ::= "UID" SPACE (copy / fetch / search / store)
+ ;; Unique identifiers used instead of message
+ ;; sequence numbers
+
+ uniqueid ::= nz_number
+ ;; Strictly ascending
+
+ unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
+
+ unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+ ;;OBSOLETE
+
+ userid ::= astring
+
+ x_command ::= "X" atom <experimental command arguments>
+
+ zone ::= ("+" / "-") 4digit
+ ;; Signed four-digit value of hhmm representing
+ ;; hours and minutes west of Greenwich (that is,
+ ;; (the amount that the given time differs from
+ ;; Universal Time). Subtracting the timezone
+ ;; from the given time will give the UT form.
+ ;; The Universal Time zone is "+0000".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 62]
+
+RFC 1730 IMAP4 December 1994
+
+
+ zone_old ::= "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
+ ;; OBSOLETE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 63]
+
+RFC 1730 IMAP4 December 1994
+
+
+10. Author's Note
+
+ This document is a revision or rewrite of earlier documents, and
+ supercedes the protocol specification in those documents: IMAP4
+ Internet drafts, the IMAP2bis Internet drafts, unpublished
+ IMAP2bis.TXT document, RFC 1176, and RFC 1064.
+
+
+11. Security Considerations
+
+ IMAP4 protocol transactions, including electronic mail data, are sent
+ in the clear over the network unless the optional privacy protection
+ is negotiated in the AUTHENTICATE command.
+
+ A server error message for an AUTHENTICATE command which fails due to
+ invalid credentials should not detail why the credentials are
+ invalid.
+
+ Use of the LOGIN command sends passwords in the clear. This can be
+ avoided by using the AUTHENTICATE command instead.
+
+ A server error message for a failing LOGIN command should not specify
+ that the user name, as opposed to the password, is invalid.
+
+ Additional security considerations are discussed in the section
+ discussing the AUTHENTICATE and LOGIN commands.
+
+
+12. 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 64]
+
+RFC 1730 IMAP4 December 1994
+
+
+Appendices
+
+A. Obsolete Commands
+
+ The following commands are OBSOLETE. It is NOT required to support
+ any of these commands 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.
+
+
+A.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
+
+ 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
+
+
+A.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
+
+
+
+Crispin [Page 65]
+
+RFC 1730 IMAP4 December 1994
+
+
+ "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
+
+
+A.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".
+
+ 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
+
+
+A.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".
+
+
+
+
+Crispin [Page 66]
+
+RFC 1730 IMAP4 December 1994
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 67]
+
+RFC 1730 IMAP4 December 1994
+
+
+B. Obsolete Responses
+
+ The following responses are OBSOLETE. Except as noted below, these
+ responses MUST NOT be transmitted by new server implementations.
+
+ 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.
+
+
+B.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
+
+
+B.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
+
+
+
+
+
+
+
+Crispin [Page 68]
+
+RFC 1730 IMAP4 December 1994
+
+
+B.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))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 69]
+
+RFC 1730 IMAP4 December 1994
+
+
+C. References
+
+
+ [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
+ Carnegie-Mellon University, December 1994.
+
+ [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and
+ IMAP2bis", RFC 1732, University of Washington, December 1994.
+
+ [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected
+ IMAP4 Clients", Work in Progress.
+
+ [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in
+ IMAP4", RFC 1733, University of Washington, December 1994.
+
+ [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work
+ in Progress.
+
+ [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
+ RFC 1176, University of Washington, August 1990.
+
+ [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in
+ Progress.
+
+ [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet
+ Mail Extensions) Part One: Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
+ September 1993.
+
+ [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+ Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
+ University of Tennessee, September 1993.
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,
+ RFC 821, USC/Information Sciences Institute, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 70]
+
+RFC 1730 IMAP4 December 1994
+
+
+E. IMAP4 Keyword Index
+
+
+ +FLAGS <flag list> (store command data item) ............... 34
+ +FLAGS.SILENT <flag list> (store command data item) ........ 34
+ -FLAGS <flag list> (store command data item) ............... 34
+ -FLAGS.SILENT <flag list> (store command data item) ........ 34
+ ALERT (response code) ...................................... 39
+ ALL (fetch item) ........................................... 29
+ ALL (search key) ........................................... 27
+ ANSWERED (search key) ...................................... 27
+ APPEND (command) ........................................... 22
+ AUTHENTICATE (command) ..................................... 12
+ BAD (response) ............................................. 41
+ BCC <string> (search key) .................................. 27
+ BEFORE <date> (search key) ................................. 27
+ BODY (fetch item) .......................................... 29
+ BODY (fetch result) ........................................ 46
+ BODY <string> (search key) ................................. 27
+ BODY.PEEK[<section>] (fetch item) .......................... 30
+ BODYSTRUCTURE (fetch item) ................................. 31
+ BODYSTRUCTURE (fetch result) ............................... 47
+ BODY[<section>] (fetch item) ............................... 29
+ BODY[section] (fetch result) ............................... 46
+ BYE (response) ............................................. 41
+ CAPABILITY (command) ....................................... 10
+ CAPABILITY (response) ...................................... 42
+ CC <string> (search key) ................................... 27
+ CHECK (command) ............................................ 23
+ CLOSE (command) ............................................ 24
+ COPY (command) ............................................. 34
+ COPY (response) ............................................ 68
+ CREATE (command) ........................................... 17
+ DELETE (command) ........................................... 18
+ DELETED (search key) ....................................... 27
+ DRAFT (search key) ......................................... 27
+ ENVELOPE (fetch item) ...................................... 31
+ ENVELOPE (fetch result) .................................... 49
+ EXAMINE (command) .......................................... 16
+ EXISTS (response) .......................................... 45
+ EXPUNGE (command) .......................................... 25
+ EXPUNGE (response) ......................................... 45
+ FAST (fetch item) .......................................... 31
+ FETCH (command) ............................................ 29
+ FETCH (response) ........................................... 46
+ FIND ALL.MAILBOXES (command) ............................... 65
+ FIND MAILBOXES (command) ................................... 65
+ FLAGGED (search key) ....................................... 27
+ FLAGS (fetch item) ......................................... 31
+
+
+
+Crispin [Page 71]
+
+RFC 1730 IMAP4 December 1994
+
+
+
+ FLAGS (fetch result) ....................................... 50
+ FLAGS (response) ........................................... 44
+ FLAGS <flag list> (store command data item) ................ 34
+ FLAGS.SILENT <flag list> (store command data item) ......... 34
+ FROM <string> (search key) ................................. 27
+ FULL (fetch item) .......................................... 31
+ HEADER <field-name> <string> (search key) .................. 27
+ INTERNALDATE (fetch item) .................................. 31
+ INTERNALDATE (fetch result) ................................ 50
+ KEYWORD <flag> (search key) ................................ 27
+ LARGER <n> (search key) .................................... 27
+ LIST (command) ............................................. 20
+ LIST (response) ............................................ 43
+ LOGIN (command) ............................................ 14
+ LOGOUT (command) ........................................... 11
+ LSUB (command) ............................................. 22
+ LSUB (response) ............................................ 44
+ MAILBOX (response) ......................................... 68
+ NEW (search key) ........................................... 27
+ NO (response) .............................................. 40
+ NOOP (command) ............................................. 11
+ NOT <search-key> (search key) .............................. 28
+ OK (response) .............................................. 40
+ OLD (search key) ........................................... 28
+ ON <date> (search key) ..................................... 28
+ OR <search-key1> <search-key2> (search key) ................ 28
+ PARSE (response code) ...................................... 39
+ PARTIAL (command) .......................................... 32
+ PERMANENTFLAGS (response code) ............................. 39
+ PREAUTH (response) ......................................... 41
+ READ-ONLY (response code) .................................. 39
+ READ-WRITE (response code) ................................. 39
+ RECENT (response) .......................................... 45
+ RECENT (search key) ........................................ 28
+ RENAME (command) ........................................... 18
+ RFC822 (fetch item) ........................................ 31
+ RFC822 (fetch result) ...................................... 50
+ RFC822.HEADER (fetch item) ................................. 31
+ RFC822.HEADER (fetch result) ............................... 50
+ RFC822.HEADER.LINES <header_list> (fetch item) ............. 31
+ RFC822.HEADER.LINES.NOT <header_list> (fetch item) ......... 32
+ RFC822.PEEK (fetch item) ................................... 31
+ RFC822.SIZE (fetch item) ................................... 32
+ RFC822.SIZE (fetch result) ................................. 50
+ RFC822.TEXT (fetch item) ................................... 32
+ RFC822.TEXT (fetch result) ................................. 51
+ RFC822.TEXT.PEEK (fetch item) .............................. 32
+ SEARCH (command) ........................................... 25
+
+
+
+Crispin [Page 72]
+
+RFC 1730 IMAP4 December 1994
+
+
+
+ SEARCH (response) .......................................... 44
+ SEEN (search key) .......................................... 28
+ SELECT (command) ........................................... 15
+ SENTBEFORE <date> (search key) ............................. 28
+ SENTON <date> (search key) ................................. 28
+ SENTSINCE <date> (search key) .............................. 28
+ SINCE <date> (search key) .................................. 28
+ SMALLER <n> (search key) ................................... 28
+ STORE (command) ............................................ 33
+ STORE (response) ........................................... 69
+ SUBJECT <string> (search key) .............................. 28
+ SUBSCRIBE (command) ........................................ 19
+ SUBSCRIBE MAILBOX (command) ................................ 66
+ TEXT <string> (search key) ................................. 28
+ TO <string> (search key) ................................... 28
+ TRYCREATE (response code) .................................. 39
+ UID (command) .............................................. 35
+ UID (fetch item) ........................................... 32
+ UID (fetch result) ......................................... 51
+ UID <message set> (search key) ............................. 28
+ UIDVALIDITY (response code) ................................ 40
+ UNANSWERED (search key) .................................... 29
+ UNDELETED (search key) ..................................... 29
+ UNDRAFT (search key) ....................................... 29
+ UNFLAGGED (search key) ..................................... 29
+ UNKEYWORD <flag> (search key) .............................. 29
+ UNSEEN (response code) ..................................... 40
+ UNSEEN (search key) ........................................ 29
+ UNSUBSCRIBE (command) ...................................... 19
+ UNSUBSCRIBE MAILBOX (command) .............................. 66
+ X<atom> (command) .......................................... 37
+ \Answered (system flag) .................................... 50
+ \Deleted (system flag) ..................................... 50
+ \Draft (system flag) ....................................... 50
+ \Flagged (system flag) ..................................... 50
+ \Marked (mailbox name attribute) ........................... 43
+ \Noinferiors (mailbox name attribute) ...................... 43
+ \Noselect (mailbox name attribute) ......................... 43
+ \Recent (system flag) ...................................... 50
+ \Seen (system flag) ........................................ 50
+ \Unmarked (mailbox name attribute) ......................... 43
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 73]
+
diff --git a/RFC/rfc1731.txt b/RFC/rfc1731.txt new file mode 100644 index 00000000..42215dec --- /dev/null +++ b/RFC/rfc1731.txt @@ -0,0 +1,339 @@ +
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 1731 Carnegie Mellon
+Category: Standards Track December 1994
+
+
+ IMAP4 Authentication Mechanisms
+
+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
+
+ The Internet Message Access Protocol, Version 4 [IMAP4] contains the
+ AUTHENTICATE command, for identifying and authenticating a user to an
+ IMAP4 server and for optionally negotiating a protection mechanism
+ for subsequent protocol interactions. This document describes
+ several authentication mechanisms for use by the IMAP4 AUTHENTICATE
+ command.
+
+
+2. Kerberos version 4 authentication mechanism
+
+ The authentication type associated with Kerberos version 4 is
+ "KERBEROS_V4".
+
+ The data encoded in the first ready response contains a random 32-bit
+ number in network byte order. The client should respond with a
+ Kerberos ticket and an authenticator for the principal
+ "imap.hostname@realm", where "hostname" is the first component of the
+ host name of the server with all letters in lower case and where
+ "realm" is the Kerberos realm of the server. The encrypted checksum
+ field included within the Kerberos authenticator should contain the
+ server provided 32-bit number in network byte order.
+
+ Upon decrypting and verifying the ticket and authenticator, the
+ server should verify that the contained checksum field equals the
+ original server provided random 32-bit number. Should the
+ verification be successful, the server must add one to the checksum
+ and construct 8 octets of data, with the first four octets containing
+ the incremented checksum in network byte order, the fifth octet
+ containing a bit-mask specifying the protection mechanisms supported
+ by the server, and the sixth through eighth octets containing, in
+
+
+
+Myers [Page 1]
+
+RFC 1731 IMAP4 Authentication Mechanisms December 1994
+
+
+ network byte order, the maximum cipher-text buffer size the server is
+ able to receive. The server must encrypt the 8 octets of data in the
+ session key and issue that encrypted data in a second ready response.
+ The client should consider the server authenticated if the first four
+ octets the un-encrypted data is equal to one plus the checksum it
+ previously sent.
+
+ The client must construct data with the first four octets containing
+ the original server-issued checksum in network byte order, the fifth
+ octet containing the bit-mask specifying the selected protection
+ mechanism, the sixth through eighth octets containing in network byte
+ order the maximum cipher-text buffer size the client is able to
+ receive, and the following octets containing a user name string. The
+ client must then append from one to eight octets so that the length
+ of the data is a multiple of eight octets. The client must then PCBC
+ encrypt the data with the session key and respond to the second ready
+ response with the encrypted data. The server decrypts the data and
+ verifies the contained checksum. The username field identifies the
+ user for whom subsequent IMAP operations are to be performed; the
+ server must verify that the principal identified in the Kerberos
+ ticket is authorized to connect as that user. After these
+ verifications, the authentication process is complete.
+
+ The protection mechanisms and their corresponding bit-masks are as
+ follows:
+
+ 1 No protection mechanism
+ 2 Integrity (krb_mk_safe) protection
+ 4 Privacy (krb_mk_priv) protection
+
+
+ EXAMPLE: The following are two Kerberos version 4 login scenarios
+ (note that the line breaks in the sample authenticators are for
+ editorial clarity and are not in real authenticators)
+
+ S: * OK IMAP4 Server
+ C: A001 AUTHENTICATE KERBEROS_V4
+ S: + AmFYig==
+ C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+ +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+ WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+ S: + or//EoAADZI=
+ C: DiAF5A4gA+oOIALuBkAAmw==
+ S: A001 OK Kerberos V4 authentication successful
+
+
+
+
+
+
+
+Myers [Page 2]
+
+RFC 1731 IMAP4 Authentication Mechanisms December 1994
+
+
+ S: * OK IMAP4 Server
+ C: A001 AUTHENTICATE KERBEROS_V4
+ S: + gcfgCA==
+ C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+ +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+ WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+ S: A001 NO Kerberos V4 authentication failed
+
+
+3. GSSAPI authentication mechanism
+
+ The authentication type associated with all mechanisms employing the
+ GSSAPI [RFC1508] is "GSSAPI".
+
+ The first ready response issued by the server contains no data. The
+ client should call GSS_Init_sec_context, passing in 0 for
+ input_context_handle (initially) and a targ_name equal to output_name
+ from GSS_Import_Name called with input_name_type of NULL and
+ input_name_string of "SERVICE:imap@hostname" where "hostname" is the
+ fully qualified host name of the server with all letters in lower
+ case. The client must then respond with the resulting output_token.
+ If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client
+ should expect the server to issue a token in a subsequent ready
+ response. The client must pass the token to another call to
+ GSS_Init_sec_context.
+
+ If GSS_Init_sec_context returns GSS_COMPLETE, then the client should
+ respond with any resulting output_token. If there is no
+ output_token, the client should respond with no data. The client
+ should then expect the server to issue a token in a subsequent ready
+ response. The client should pass this token to GSS_Unseal and
+ interpret the first octet of resulting cleartext as a bit-mask
+ specifying the protection mechanisms supported by the server and the
+ second through fourth octets as the maximum size output_message to
+ send to the server. The client should construct data, with the first
+ octet containing the bit-mask specifying the selected protection
+ mechanism, the second through fourth octets containing in network
+ byte order the maximum size output_message the client is able to
+ receive, and the remaining octets containing a user name string. The
+ client must pass the data to GSS_Seal with conf_flag set to FALSE,
+ and respond with the generated output_message. The client can then
+ consider the server authenticated.
+
+ The server must issue a ready response with no data and pass the
+ resulting client supplied token to GSS_Accept_sec_context as
+ input_token, setting acceptor_cred_handle to NULL (for "use default
+ credentials"), and 0 for input_context_handle (initially). If
+ GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should
+
+
+
+Myers [Page 3]
+
+RFC 1731 IMAP4 Authentication Mechanisms December 1994
+
+
+ return the generated output_token to the client in a ready response
+ and pass the resulting client supplied token to another call to
+ GSS_Accept_sec_context.
+
+ If GSS_Accept_sec_context returns GSS_COMPLETE, then if an
+ output_token is returned, the server should return it to the client
+ in a ready response and expect a reply from the client with no data.
+ Whether or not an output_token was returned, the server then should
+ then construct 4 octets of data, with the first octet containing a
+ bit-mask specifying the protection mechanisms 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. The
+ server must then pass the plaintext to GSS_Seal with conf_flag set to
+ FALSE and issue the generated output_message to the client in a ready
+ response. The server must then pass the resulting client supplied
+ token to GSS_Unseal and interpret the first octet of resulting
+ cleartext as the bit-mask for the selected protection mechanism, the
+ second through fourth octets as the maximum size output_message to
+ send to the client, and the remaining octets as the user name. Upon
+ verifying the src_name is authorized to authenticate as the user
+ name, The server should then consider the client authenticated.
+
+ The protection mechanisms and their corresponding bit-masks are as
+ follows:
+
+ 1 No protection mechanism
+ 2 Integrity protection.
+ Sender calls GSS_Seal with conf_flag set to FALSE
+ 4 Privacy protection.
+ Sender calls GSS_Seal with conf_flag set to TRUE
+
+
+4. S/Key authentication mechanism
+
+ The authentication type associated with S/Key [SKEY] is "SKEY".
+
+ The first ready response issued by the server contains no data. The
+ client responds with the user name string.
+
+ The data encoded in the second ready response contains the decimal
+ sequence number followed by a single space and the seed string for
+ the indicated user. The client responds with the one-time-password,
+ as either a 64-bit value in network byte order or encoded in the "six
+ English words" format.
+
+ Upon successful verification of the one-time-password, the server
+ should consider the client authenticated.
+
+
+
+
+Myers [Page 4]
+
+RFC 1731 IMAP4 Authentication Mechanisms December 1994
+
+
+ S/Key authentication does not provide for any protection mechanisms.
+
+
+ EXAMPLE: The following are two S/Key login scenarios.
+
+ S: * OK IMAP4 Server
+ C: A001 AUTHENTICATE SKEY
+ S: +
+ C: bW9yZ2Fu
+ S: + OTUgUWE1ODMwOA==
+ C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
+ S: A001 OK S/Key authentication successful
+
+
+ S: * OK IMAP4 Server
+ C: A001 AUTHENTICATE SKEY
+ S: +
+ C: c21pdGg=
+ S: + OTUgUWE1ODMwOA==
+ C: BsAY3g4gBNo=
+ S: A001 NO S/Key authentication failed
+
+
+5. References
+
+ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
+ RFC 1730, University of Washington, December 1994.
+
+ [RFC1508] Linn, J., "Generic Security Service Application Program
+ Interface", RFC 1508, Geer Zolot Associates, September 1993.
+
+ [SKEY] Haller, Neil M. "The S/Key One-Time Password System",
+ Bellcore, Morristown, New Jersey, October 1993,
+ thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers [Page 5]
+
+RFC 1731 IMAP4 Authentication Mechanisms December 1994
+
+
+6. Security Considerations
+
+ Security issues are discussed throughout this memo.
+
+
+7. Author's Address
+
+ John G. Myers
+ Carnegie-Mellon University
+ 5000 Forbes Ave.
+ Pittsburgh PA, 15213-3890
+
+ EMail: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers [Page 6]
+
diff --git a/RFC/rfc1732.txt b/RFC/rfc1732.txt new file mode 100644 index 00000000..cfae89c0 --- /dev/null +++ b/RFC/rfc1732.txt @@ -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] + diff --git a/RFC/rfc1734.txt b/RFC/rfc1734.txt new file mode 100644 index 00000000..f37f29e0 --- /dev/null +++ b/RFC/rfc1734.txt @@ -0,0 +1,283 @@ + + + + + + +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] + diff --git a/RFC/rfc1870.txt b/RFC/rfc1870.txt new file mode 100644 index 00000000..e24ccec6 --- /dev/null +++ b/RFC/rfc1870.txt @@ -0,0 +1,507 @@ +
+
+
+
+
+
+Network Working Group J. Klensin, WG Chair
+Request For Comments: 1870 MCI
+STD: 10 N. Freed, Editor
+Obsoletes: 1653 Innosoft International, Inc.
+Category: Standards Track K. Moore
+ University of Tennessee
+ November 1995
+
+
+ SMTP Service Extension
+ for Message Size Declaration
+
+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
+
+ This memo defines an extension to the SMTP service whereby an SMTP
+ client and server may interact to give the server an opportunity to
+ decline to accept a message (perhaps temporarily) based on the
+ client's estimate of the message size.
+
+2. Introduction
+
+ The MIME extensions to the Internet message protocol provide for the
+ transmission of many kinds of data which were previously unsupported
+ in Internet mail. One expected result of the use of MIME is that
+ SMTP will be expected to carry a much wider range of message sizes
+ than was previously the case. This has an impact on the amount of
+ resources (e.g. disk space) required by a system acting as a server.
+
+ This memo uses the mechanism defined in [5] to define extensions to
+ the SMTP service whereby a client ("sender-SMTP") may declare the
+ size of a particular message to a server ("receiver-SMTP"), after
+ which the server may indicate to the client that it is or is not
+ willing to accept the message based on the declared message size and
+ whereby a server ("receiver-SMTP") may declare the maximum message
+ size it is willing to accept to a client ("sender-SMTP").
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 1]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+3. Framework for the Size Declaration Extension
+
+ The following service extension is therefore defined:
+
+ (1) the name of the SMTP service extension is "Message Size
+ Declaration";
+
+ (2) the EHLO keyword value associated with this extension is "SIZE";
+
+ (3) one optional parameter is allowed with this EHLO keyword value, a
+ decimal number indicating the fixed maximum message size in bytes
+ that the server will accept. The syntax of the parameter is as
+ follows, using the augmented BNF notation of [2]:
+
+ size-param ::= [1*DIGIT]
+
+ A parameter value of 0 (zero) indicates that no fixed maximum
+ message size is in force. If the parameter is omitted no
+ information is conveyed about the server's fixed maximum message
+ size;
+
+ (4) one optional parameter using the keyword "SIZE" is added to the
+ MAIL FROM command. The value associated with this parameter is a
+ decimal number indicating the size of the message that is to be
+ transmitted. The syntax of the value is as follows, using the
+ augmented BNF notation of [2]:
+
+ size-value ::= 1*20DIGIT
+
+ (5) the maximum length of a MAIL FROM command line is increased by 26
+ characters by the possible addition of the SIZE keyword and
+ value;
+
+ (6) no additional SMTP verbs are defined by this extension.
+
+ The remainder of this memo specifies how support for the extension
+ affects the behavior of an SMTP client and server.
+
+4. The Message Size Declaration service extension
+
+ An SMTP server may have a fixed upper limit on message size. Any
+ attempt by a client to transfer a message which is larger than this
+ fixed upper limit will fail. In addition, a server normally has
+ limited space with which to store incoming messages. Transfer of a
+ message may therefore also fail due to a lack of storage space, but
+ might succeed at a later time.
+
+
+
+
+
+Klensin, et al Standards Track [Page 2]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+ A client using the unextended SMTP protocol defined in [1], can only
+ be informed of such failures after transmitting the entire message to
+ the server (which discards the transferred message). If, however,
+ both client and server support the Message Size Declaration service
+ extension, such conditions may be detected before any transfer is
+ attempted.
+
+ An SMTP client wishing to relay a large content may issue the EHLO
+ command to start an SMTP session, to determine if the server supports
+ any of several service extensions. If the server responds with code
+ 250 to the EHLO command, and the response includes the EHLO keyword
+ value SIZE, then the Message Size Declaration extension is supported.
+
+ If a numeric parameter follows the SIZE keyword value of the EHLO
+ response, it indicates the size of the largest message that the
+ server is willing to accept. Any attempt by a client to transfer a
+ message which is larger than this limit will be rejected with a
+ permanent failure (552) reply code.
+
+ A server that supports the Message Size Declaration extension will
+ accept the extended version of the MAIL command described below.
+ When supported by the server, a client may use the extended MAIL
+ command (instead of the MAIL command as defined in [1]) to declare an
+ estimate of the size of a message it wishes to transfer. The server
+ may then return an appropriate error code if it determines that an
+ attempt to transfer a message of that size would fail.
+
+5. Definitions
+
+ The message size is defined as the number of octets, including CR-LF
+ pairs, but not the SMTP DATA command's terminating dot or doubled
+ quoting dots, to be transmitted by the SMTP client after receiving
+ reply code 354 to the DATA command.
+
+ The fixed maximum message size is defined as the message size of the
+ largest message that a server is ever willing to accept. An attempt
+ to transfer any message larger than the fixed maximum message size
+ will always fail. The fixed maximum message size may be an
+ implementation artifact of the SMTP server, or it may be chosen by
+ the administrator of the server.
+
+ The declared message size is defined as a client's estimate of the
+ message size for a particular message.
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 3]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+6. The extended MAIL command
+
+ The extended MAIL command is issued by a client when it wishes to
+ inform a server of the size of the message to be sent. The extended
+ MAIL command is identical to the MAIL command as defined in [1],
+ except that a SIZE parameter appears after the address.
+
+ The complete syntax of this extended command is defined in [5]. The
+ esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
+ the syntax for size-value shown above.
+
+ The value associated with the SIZE parameter is a decimal
+ representation of the declared message size in octets. This number
+ should include the message header, body, and the CR-LF sequences
+ between lines, but not the SMTP DATA command's terminating dot or
+ doubled quoting dots. Only one SIZE parameter may be specified in a
+ single MAIL command.
+
+ Ideally, the declared message size is equal to the true message size.
+ However, since exact computation of the message size may be
+ infeasable, the client may use a heuristically-derived estimate.
+ Such heuristics should be chosen so that the declared message size is
+ usually larger than the actual message size. (This has the effect of
+ making the counting or non-counting of SMTP DATA dots largely an
+ academic point.)
+
+ NOTE: Servers MUST NOT use the SIZE parameter to determine end of
+ content in the DATA command.
+
+6.1 Server action on receipt of the extended MAIL command
+
+ Upon receipt of an extended MAIL command containing a SIZE parameter,
+ a server should determine whether the declared message size exceeds
+ its fixed maximum message size. If the declared message size is
+ smaller than the fixed maximum message size, the server may also wish
+ to determine whether sufficient resources are available to buffer a
+ message of the declared message size and to maintain it in stable
+ storage, until the message can be delivered or relayed to each of its
+ recipients.
+
+ A server may respond to the extended MAIL command with any of the
+ error codes defined in [1] for the MAIL command. In addition, one of
+ the following error codes may be returned:
+
+ (1) If the server currently lacks sufficient resources to accept a
+ message of the indicated size, but may be able to accept the
+ message at a later time, it responds with code "452 insufficient
+ system storage".
+
+
+
+Klensin, et al Standards Track [Page 4]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+ (2) If the indicated size is larger than the server's fixed maximum
+ message size, the server responds with code "552 message size
+ exceeds fixed maximium message size".
+
+ A server is permitted, but not required, to accept a message which
+ is, in fact, larger than declared in the extended MAIL command, such
+ as might occur if the client employed a size-estimation heuristic
+ which was inaccurate.
+
+6.2 Client action on receiving response to extended MAIL command
+
+ The client, upon receiving the server's response to the extended MAIL
+ command, acts as follows:
+
+ (1) If the code "452 insufficient system storage" is returned, the
+ client should next send either a RSET command (if it wishes to
+ attempt to send other messages) or a QUIT command. The client
+ should then repeat the attempt to send the message to the server
+ at a later time.
+
+ (2) If the code "552 message exceeds fixed maximum message size" is
+ received, the client should immediately send either a RSET command
+ (if it wishes to attempt to send additional messages), or a QUIT
+ command. The client should then declare the message undeliverable
+ and return appropriate notification to the sender (if a sender
+ address was present in the MAIL command).
+
+ A successful (250) reply code in response to the extended MAIL
+ command does not constitute an absolute guarantee that the message
+ transfer will succeed. SMTP clients using the extended MAIL command
+ must still be prepared to handle both temporary and permanent error
+ reply codes (including codes 452 and 552), either immediately after
+ issuing the DATA command, or after transfer of the message.
+
+6.3 Messages larger than the declared size.
+
+ Once a server has agreed (via the extended MAIL command) to accept a
+ message of a particular size, it should not return a 552 reply code
+ after the transfer phase of the DATA command, unless the actual size
+ of the message transferred is greater than the declared message size.
+ A server may also choose to accept a message which is somewhat larger
+ than the declared message size.
+
+ A client is permitted to declare a message to be smaller than its
+ actual size. However, in this case, a successful (250) reply code is
+ no assurance that the server will accept the message or has
+ sufficient resources to do so. The server may reject such a message
+ after its DATA transfer.
+
+
+
+Klensin, et al Standards Track [Page 5]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+6.4 Per-recipient rejection based on message size.
+
+ A server that implements this extension may return a 452 or 552 reply
+ code in response to a RCPT command, based on its unwillingness to
+ accept a message of the declared size for a particular recipient.
+
+ (1) If a 452 code is returned, the client may requeue the message for
+ later delivery to the same recipient.
+
+ (2) If a 552 code is returned, the client may not requeue the message
+ for later delivery to the same recipient.
+
+7. Minimal usage
+
+ A "minimal" client may use this extension to simply compare its
+ (perhaps estimated) size of the message that it wishes to relay, with
+ the server's fixed maximum message size (from the parameter to the
+ SIZE keyword in the EHLO response), to determine whether the server
+ will ever accept the message. Such an implementation need not
+ declare message sizes via the extended MAIL command. However,
+ neither will it be able to discover temporary limits on message size
+ due to server resource limitations, nor per-recipient limitations on
+ message size.
+
+ A minimal server that employs this service extension may simply use
+ the SIZE keyword value to inform the client of the size of the
+ largest message it will accept, or to inform the client that there is
+ no fixed limit on message size. Such a server must accept the
+ extended MAIL command and return a 552 reply code if the client's
+ declared size exceeds its fixed size limit (if any), but it need not
+ detect "temporary" limitations on message size.
+
+ The numeric parameter to the EHLO SIZE keyword is optional. If the
+ parameter is omitted entirely it indicates that the server does not
+ advertise a fixed maximum message size. A server that returns the
+ SIZE keyword with no parameter in response to the EHLO command may
+ not issue a positive (250) response to an extended MAIL command
+ containing a SIZE specification without first checking to see if
+ sufficient resources are available to transfer a message of the
+ declared size, and to retain it in stable storage until it can be
+ relayed or delivered to its recipients. If possible, the server
+ should actually reserve sufficient storage space to transfer the
+ message.
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 6]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+8. Example
+
+ The following example illustrates the use of size declaration with
+ some permanent and temporary failures.
+
+ S: <wait for connection on TCP port 25>
+ C: <open connection to server>
+ S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+ C: EHLO ymir.claremont.edu
+ S: 250-sigurd.innosoft.com
+ S: 250-EXPN
+ S: 250-HELP
+ S: 250 SIZE 1000000
+ C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
+ S: 250 Address Ok.
+ C: RCPT TO:<ned@innosoft.com>
+ S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
+ C: RCPT TO:<ned@ymir.claremont.edu>
+ S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
+ C: RCPT TO:<ned@hmcvax.claremont.edu>
+ S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
+ C: DATA
+ S: 354 Send message, ending in CRLF.CRLF.
+ ...
+ C: .
+ S: 250 Some recipients OK
+ C: QUIT
+ S: 221 Goodbye
+
+9. Security Considerations
+
+ The size declaration extensions described in this memo can
+ conceivably be used to facilitate crude service denial attacks.
+ Specifically, both the information contained in the SIZE parameter
+ and use of the extended MAIL command make it somewhat quicker and
+ easier to devise an efficacious service denial attack. However,
+ unless implementations are very weak, these extensions do not create
+ any vulnerability that has not always existed with SMTP. In addition,
+ no issues are addressed involving trusted systems and possible
+ release of information via the mechanisms described in this RFC.
+
+10. Acknowledgements
+
+ This document was derived from an earlier Working Group work in
+ progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot
+ Lear, Marshall T. Rose, and Einar Stefferud provided extensive
+ comments in response to earlier works in progress of both this and
+ the previous memo.
+
+
+
+Klensin, et al Standards Track [Page 7]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+11. References
+
+ [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ USC/Information Sciences Institute, August 1982.
+
+ [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, UDEL, August 1982.
+
+ [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+ Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+ [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
+ Headers", RFC 1522, University of Tennessee, September 1993.
+
+ [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+ "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
+ International, Inc., Dover Beach Consulting, Inc., Network
+ Management Associates, Inc., Brandenburg Consulting, November
+ 1995.
+
+ [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+ 974, BBN, January 1986.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 8]
+
+RFC 1870 SMTP Size Declaration November 1995
+
+
+12. Chair, Editor, and Author Addresses
+
+ John Klensin, WG Chair
+ MCI
+ 2100 Reston Parkway
+ Reston, VA 22091
+
+ Phone: +1 703 715-7361
+ Fax: +1 703 715-7436
+ EMail: klensin@mci.net
+
+
+ Ned Freed, Editor
+ Innosoft International, Inc.
+ 1050 East Garvey Avenue South
+ West Covina, CA 91790
+ USA
+
+ Phone: +1 818 919 3600
+ Fax: +1 818 919 3614
+ EMail: ned@innosoft.com
+
+
+ Keith Moore
+ Computer Science Dept.
+ University of Tennessee
+ 107 Ayres Hall
+ Knoxville, TN 37996-1301
+ USA
+
+ EMail: moore@cs.utk.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin, et al Standards Track [Page 9]
+
diff --git a/RFC/rfc1891.txt b/RFC/rfc1891.txt new file mode 100644 index 00000000..23b58ba9 --- /dev/null +++ b/RFC/rfc1891.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1891 University of Tennessee +Category: Standards Track January 1996 + + + SMTP Service Extension + for Delivery Status Notifications + +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 + + This memo defines an extension to the SMTP service, which allows an + SMTP client to specify (a) that delivery status notifications (DSNs) + should be generated under certain conditions, (b) whether such + notifications should return the contents of the message, and (c) + additional information, to be returned with a DSN, that allows the + sender to identify both the recipient(s) for which the DSN was + issued, and the transaction in which the original message was sent. + + Any questions, comments, and reports of defects or ambiguities in + this specification may be sent to the mailing list for the NOTARY + working group of the IETF, using the address + <notifications@cs.utk.edu>. Requests to subscribe to the mailing + list should be addressed to <notifications-request@cs.utk.edu>. + Implementors of this specification are encouraged to subscribe to the + mailing list, so that they will quickly be informed of any problems + which might hinder interoperability. + + NOTE: This document is a Proposed Standard. If and when this + protocol is submitted for Draft Standard status, any normative text + (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in + this document will be re-evaluated in light of implementation + experience, and are thus subject to change. + +2. Introduction + + The SMTP protocol [1] requires that an SMTP server provide + notification of delivery failure, if it determines that a message + cannot be delivered to one or more recipients. Traditionally, such + notification consists of an ordinary Internet mail message (format + defined by [2]), sent to the envelope sender address (the argument of + + + +Moore Standards Track [Page 1] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + the SMTP MAIL command), containing an explanation of the error and at + least the headers of the failed message. + + Experience with large mail distribution lists [3] indicates that such + messages are often insufficient to diagnose problems, or even to + determine at which host or for which recipients a problem occurred. + In addition, the lack of a standardized format for delivery + notifications in Internet mail makes it difficult to exchange such + notifications with other message handling systems. + + Such experience has demonstrated a need for a delivery status + notification service for Internet electronic mail, which: + +(a) is reliable, in the sense that any DSN request will either be + honored at the time of final delivery, or result in a response + that indicates that the request cannot be honored, + +(b) when both success and failure notifications are requested, + provides an unambiguous and nonconflicting indication of whether + delivery of a message to a recipient succeeded or failed, + +(c) is stable, in that a failed attempt to deliver a DSN should never + result in the transmission of another DSN over the network, + +(d) preserves sufficient information to allow the sender to identify + both the mail transaction and the recipient address which caused + the notification, even when mail is forwarded or gatewayed to + foreign environments, and + +(e) interfaces acceptably with non-SMTP and non-822-based mail + systems, both so that notifications returned from foreign mail + systems may be useful to Internet users, and so that the + notification requests from foreign environments may be honored. + Among the requirements implied by this goal are the ability to + request non-return-of-content, and the ability to specify whether + positive delivery notifications, negative delivery notifications, + both, or neither, should be issued. + + In an attempt to provide such a service, this memo uses the mechanism + defined in [4] to define an extension to the SMTP protocol. Using + this mechanism, an SMTP client may request that an SMTP server issue + or not issue a delivery status notification (DSN) under certain + conditions. The format of a DSN is defined in [5]. + + + + + + + + +Moore Standards Track [Page 2] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +3. Framework for the Delivery Status Notification Extension + + The following service extension is therefore defined: + +(1) The name of the SMTP service extension is "Delivery Status + Notification"; + +(2) the EHLO keyword value associated with this extension is "DSN", + the meaning of which is defined in section 4 of this memo; + +(3) no parameters are allowed with this EHLO keyword value; + +(4) two optional parameters are added to the RCPT command, and two + optional parameters are added to the MAIL command: + + An optional parameter for the RCPT command, using the + esmtp-keyword "NOTIFY", (to specify the conditions under which a + delivery status notification should be generated), is defined in + section 5.1, + + An optional parameter for the RCPT command, using the + esmtp-keyword "ORCPT", (used to convey the "original" + (sender-specified) recipient address), is defined in section 5.2, + and + + An optional parameter for the MAIL command, using the + esmtp-keyword "RET", (to request that DSNs containing an + indication of delivery failure either return the entire contents + of a message or only the message headers), is defined in section + 5.3, + + An optional parameter for the MAIL command, using the + esmtp-keyword "ENVID", (used to propagate an identifier for this + message transmission envelope, which is also known to the sender + and will, if present, be returned in any DSNs issued for this + transmission), is defined in section 5.4; + +(5) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + effects the behavior of a message transfer agent. + +4. The Delivery Status Notification service extension + + An SMTP client wishing to request a DSN for a message may issue the + EHLO command to start an SMTP session, to determine if the server + supports any of several service extensions. If the server responds + with code 250 to the EHLO command, and the response includes the EHLO + + + +Moore Standards Track [Page 3] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + keyword DSN, then the Delivery Status Notification extension (as + described in this memo) is supported. + + Ordinarily, when an SMTP server returns a positive (2xx) reply code + in response to a RCPT command, it agrees to accept responsibility for + either delivering the message to the named recipient, or sending a + notification to the sender of the message indicating that delivery + has failed. However, an extended SMTP ("ESMTP") server which + implements this service extension will accept an optional NOTIFY + parameter with the RCPT command. If present, the NOTIFY parameter + alters the conditions for generation of delivery status notifications + from the default (issue notifications only on failure) specified in + [1]. The ESMTP client may also request (via the RET parameter) + whether the entire contents of the original message should be + returned (as opposed to just the headers of that message), along with + the DSN. + + In general, an ESMTP server which implements this service extension + will propagate delivery status notification requests when relaying + mail to other SMTP-based MTAs which also support this extension, and + make a "best effort" to ensure that such requests are honored when + messages are passed into other environments. + + In order that any delivery status notifications thus generated will + be meaningful to the sender, any ESMTP server which supports this + extension will attempt to propagate the following information to any + other MTAs that are used to relay the message, for use in generating + DSNs: + +(a) for each recipient, a copy of the original recipient address, as + used by the sender of the message. + + This address need not be the same as the mailbox specified in the + RCPT command. For example, if a message was originally addressed + to A@B.C and later forwarded to A@D.E, after such forwarding has + taken place, the RCPT command will specify a mailbox of A@D.E. + However, the original recipient address remains A@B.C. + + Also, if the message originated from an environment which does not + use Internet-style user@domain addresses, and was gatewayed into + SMTP, the original recipient address will preserve the original + form of the recipient address. + +(b) for the entire SMTP transaction, an envelope identification + string, which may be used by the sender to associate any delivery + status notifications with the transaction used to send the + original message. + + + + +Moore Standards Track [Page 4] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +5. Additional parameters for RCPT and MAIL commands + + The extended RCPT and MAIL commands are issued by a client when it + wishes to request a DSN from the server, under certain conditions, + for a particular recipient. The extended RCPT and MAIL commands are + identical to the RCPT and MAIL commands defined in [1], except that + one or more of the following parameters appear after the sender or + recipient address, respectively. The general syntax for extended + SMTP commands is defined in [4]. + + NOTE: Although RFC 822 ABNF is used to describe the syntax of these + parameters, they are not, in the language of that document, + "structured field bodies". Therefore, while parentheses MAY appear + within an emstp-value, they are not recognized as comment delimiters. + + The syntax for "esmtp-value" in [4] does not allow SP, "=", control + characters, or characters outside the traditional ASCII range of 1- + 127 decimal to be transmitted in an esmtp-value. Because the ENVID + and ORCPT parameters may need to convey values outside this range, + the esmtp-values for these parameters are encoded as "xtext". + "xtext" is formally defined as follows: + + xtext = *( xchar / hexchar ) + + xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+" and "=". + +; "hexchar"s are intended to encode octets that cannot appear +; as ASCII characters within an esmtp-value. + + hexchar = ASCII "+" immediately followed by two upper case + hexadecimal digits + +When encoding an octet sequence as xtext: + ++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", + MAY be encoded as itself. (A CHAR in this range MAY instead be + encoded as a "hexchar", at the implementor's discretion.) + ++ ASCII CHARs that fall outside the range above must be encoded as + "hexchar". + +5.1 The NOTIFY parameter of the ESMTP RCPT command + + A RCPT command issued by a client may contain the optional esmtp- + keyword "NOTIFY", to specify the conditions under which the SMTP + server should generate DSNs for that recipient. If the NOTIFY + esmtp-keyword is used, it MUST have an associated esmtp-value, + + + +Moore Standards Track [Page 5] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + formatted according to the following rules, using the ABNF of RFC + 822: + + notify-esmtp-value = "NEVER" / 1#notify-list-element + + notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" + +Notes: + +a. Multiple notify-list-elements, separated by commas, MAY appear in a + NOTIFY parameter; however, the NEVER keyword MUST appear by itself. + +b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled + in any combination of upper and lower case letters. + +The meaning of the NOTIFY parameter values is generally as follows: + ++ A NOTIFY parameter value of "NEVER" requests that a DSN not be + returned to the sender under any conditions. + ++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" + keywords requests that a DSN be issued on successful delivery or + delivery failure, respectively. + ++ A NOTIFY parameter value containing the keyword "DELAY" indicates the + sender's willingness to receive "delayed" DSNs. Delayed DSNs may be + issued if delivery of a message has been delayed for an unusual amount + of time (as determined by the MTA at which the message is delayed), + but the final delivery status (whether successful or failure) cannot + be determined. The absence of the DELAY keyword in a NOTIFY parameter + requests that a "delayed" DSN NOT be issued under any conditions. + + The actual rules governing interpretation of the NOTIFY parameter are + given in section 6. + + For compatibility with SMTP clients that do not use the NOTIFY + facility, the absence of a NOTIFY parameter in a RCPT command may be + interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. + +5.2 The ORCPT parameter to the ESMTP RCPT command + + The ORCPT esmtp-keyword of the RCPT command is used to specify an + "original" recipient address that corresponds to the actual recipient + to which the message is to be delivered. If the ORCPT esmtp-keyword + is used, it MUST have an associated esmtp-value, which consists of + the original recipient address, encoded according to the rules below. + The ABNF for the ORCPT parameter is: + + + + +Moore Standards Track [Page 6] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + orcpt-parameter = "ORCPT=" original-recipient-address + + original-recipient-address = addr-type ";" xtext + + addr-type = atom + + The "addr-type" portion MUST be an IANA-registered electronic mail + address-type (as defined in [5]), while the "xtext" portion contains + an encoded representation of the original recipient address using the + rules in section 5 of this document. The entire ORCPT parameter MAY + be up to 500 characters in length. + + When initially submitting a message via SMTP, if the ORCPT parameter + is used, it MUST contain the same address as the RCPT TO address + (unlike the RCPT TO address, the ORCPT parameter will be encoded as + xtext). Likewise, when a mailing list submits a message via SMTP to + be distributed to the list subscribers, if ORCPT is used, the ORCPT + parameter MUST match the new RCPT TO address of each recipient, not + the address specified by the original sender of the message.) + + The "addr-type" portion of the original-recipient-address is used to + indicate the "type" of the address which appears in the ORCPT + parameter value. However, the address associated with the ORCPT + keyword is NOT constrained to conform to the syntax rules for that + "addr-type". + + Ideally, the "xtext" portion of the original-recipient-address should + contain, in encoded form, the same sequence of characters that the + sender used to specify the recipient. However, for a message + gatewayed from an environment (such as X.400) in which a recipient + address is not a simple string of printable characters, the + representation of recipient address must be defined by a + specification for gatewaying between DSNs and that environment. + +5.3 The RET parameter of the ESMTP MAIL command + + The RET esmtp-keyword on the extended MAIL command specifies whether + or not the message should be included in any failed DSN issued for + this message transmission. If the RET esmtp-keyword is used, it MUST + have an associated esmtp-value, which is one of the following + keywords: + + FULL requests that the entire message be returned in any "failed" + delivery status notification issued for this recipient. + + HDRS requests that only the headers of the message be returned. + + + + + +Moore Standards Track [Page 7] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + The FULL and HDRS keywords may be spelled in any combination of upper + and lower case letters. + + If no RET parameter is supplied, the MTA MAY return either the + headers of the message or the entire message for any DSN containing + indication of failed deliveries. + + Note that the RET parameter only applies to DSNs that indicate + delivery failure for at least one recipient. If a DSN contains no + indications of delivery failure, only the headers of the message + should be returned. + +5.4 The ENVID parameter to the ESMTP MAIL command + + The ENVID esmtp-keyword of the SMTP MAIL command is used to specify + an "envelope identifier" to be transmitted along with the message and + included in any DSNs issued for any of the recipients named in this + SMTP transaction. The purpose of the envelope identifier is to allow + the sender of a message to identify the transaction for which the DSN + was issued. + + The ABNF for the ENVID parameter is: + + envid-parameter = "ENVID=" xtext + + The ENVID esmtp-keyword MUST have an associated esmtp-value. No + meaning is assigned by the mail system to the presence or absence of + this parameter or to any esmtp-value associated with this parameter; + the information is used only by the sender or his user agent. The + ENVID parameter MAY be up to 100 characters in length. + +5.5 Restrictions on the use of Delivery Status Notification parameters + + The RET and ENVID parameters MUST NOT appear more than once each in + any single MAIL command. If more than one of either of these + parameters appears in a MAIL command, the ESMTP server SHOULD respond + with "501 syntax error in parameters or arguments". + + The NOTIFY and ORCPT parameters MUST NOT appear more than once in any + RCPT command. If more than one of either of these parameters appears + in a RCPT command, the ESMTP server SHOULD respond with "501 syntax + error in parameters or arguments". + +6. Conformance requirements + + The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer + Agents (MTAs) when accepting, relaying, or gatewaying mail, as well + as User Agents (UAs) when submitting mail to the mail transport + + + +Moore Standards Track [Page 8] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + system. The DSN extension to SMTP may be used to allow UAs to convey + the sender's requests as to when DSNs should be issued. A UA which + claims to conform to this specification must meet certain + requirements as described below. + + Typically, a message transfer agent (MTA) which supports SMTP will + assume, at different times, both the role of a SMTP client and an + SMTP server, and may also provide local delivery, gatewaying to + foreign environments, forwarding, and mailing list expansion. An MTA + which, when acting as an SMTP server, issues the DSN keyword in + response to the EHLO command, MUST obey the rules below for a + "conforming SMTP client" when acting as a client, and a "conforming + SMTP server" when acting as a server. The term "conforming MTA" + refers to an MTA which conforms to this specification, independent of + its role of client or server. + +6.1 SMTP protocol interactions + + The following rules apply to SMTP transactions in which any of the + ENVID, NOTIFY, RET, or ORCPT keywords are used: + +(a) If an SMTP client issues a MAIL command containing a valid ENVID + parameter and associated esmtp-value and/or a valid RET parameter + and associated esmtp-value, a conforming SMTP server MUST return + the same reply-code as it would to the same MAIL command without + the ENVID and/or RET parameters. A conforming SMTP server MUST + NOT refuse a MAIL command based on the absence or presence of + valid ENVID or RET parameters, or on their associated + esmtp-values. + + However, if the associated esmtp-value is not valid (i.e. contains + illegal characters), or if there is more than one ENVID or RET + parameter in a particular MAIL command, the server MUST issue the + reply-code 501 with an appropriate message (e.g. "syntax error in + parameter"). + +(b) If an SMTP client issues a RCPT command containing any valid + NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST + return the same response as it would to the same RCPT command + without those NOTIFY and/or ORCPT parameters. A conforming SMTP + server MUST NOT refuse a RCPT command based on the presence or + absence of any of these parameters. + + However, if any of the associated esmtp-values are not valid, or + if there is more than one of any of these parameters in a + particular RCPT command, the server SHOULD issue the response "501 + syntax error in parameter". + + + + +Moore Standards Track [Page 9] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2 Handling of messages received via SMTP + + This section describes how a conforming MTA should handle any + messages received via SMTP. + + NOTE: A DSN MUST NOT be returned to the sender for any message for + which the return address from the SMTP MAIL command was NULL ("<>"), + even if the sender's address is available from other sources (e.g. + the message header). However, the MTA which would otherwise issue a + DSN SHOULD inform the local postmaster of delivery failures through + some appropriate mechanism that will not itself result in the + generation of DSNs. + + DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to + be sent with a NULL return address ("reverse-path"). This creates an + interesting situation when a message arrives with one or more + nonfunctional recipient addresses in addition to a nonfunctional + return address. When delivery to one of the recipient addresses + fails, the MTA will attempt to send a nondelivery notification to the + return address, setting the return address on the notification to + NULL. When the delivery of this notification fails, the MTA + attempting delivery of that notification sees a NULL return address. + If that MTA were not to inform anyone of the situation, the original + message would be silently lost. Furthermore, a nonfunctional return + address is often indicative of a configuration problem in the + sender's MTA. Reporting the condition to the local postmaster may + help to speed correction of such errors. + +6.2.1 Relay of messages to other conforming SMTP servers + + The following rules govern the behavior of a conforming MTA, when + relaying a message which was received via the SMTP protocol, to an + SMTP server that supports the Delivery Status Notification service + extension: + +(a) Any ENVID parameter included in the MAIL command when a message was + received, MUST also appear on the MAIL command with which the + message is relayed, with the same associated esmtp-value. If no + ENVID parameter was included in the MAIL command when the message + was received, the ENVID parameter MUST NOT be supplied when the + message is relayed. + +(b) Any RET parameter included in the MAIL command when a message was + received, MUST also appear on the MAIL command with which the + message is relayed, with the same associated esmtp-value. If no RET + parameter was included in the MAIL command when the message was + received, the RET parameter MUST NOT supplied when the message is + relayed. + + + +Moore Standards Track [Page 10] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If the NOTIFY parameter was supplied for a recipient when the + message was received, the RCPT command issued when the message is + relayed MUST also contain the NOTIFY parameter along with its + associated esmtp-value. If the NOTIFY parameter was not supplied + for a recipient when the message was received, the NOTIFY parameter + MUST NOT be supplied for that recipient when the message is relayed. + +(d) If any ORCPT parameter was present in the RCPT command for a + recipient when the message was received, an ORCPT parameter with the + identical original-recipient-address MUST appear in the RCPT command + issued for that recipient when relaying the message. (For example, + the MTA therefore MUST NOT change the case of any alphabetic + characters in an ORCPT parameter.) + + If no ORCPT parameter was present in the RCPT command when the + message was received, an ORCPT parameter MAY be added to the RCPT + command when the message is relayed. If an ORCPT parameter is added + by the relaying MTA, it MUST contain the recipient address from the + RCPT command used when the message was received by that MTA. + +6.2.2 Relay of messages to non-conforming SMTP servers + + The following rules govern the behavior of a conforming MTA (in the + role of client), when relaying a message which was received via the + SMTP protocol, to an SMTP server that does not support the Delivery + Status Notification service extension: + +(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when + relaying the message. + +(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp- + value containing the keyword SUCCESS, and the SMTP server returns a + success (2xx) reply-code in response to the RCPT command, the client + MUST issue a "relayed" DSN for that recipient. + +(c) If the NOTIFY parameter was supplied for a recipient with an esmtp- + value containing the keyword FAILURE, and the SMTP server returns a + permanent failure (5xx) reply-code in response to the RCPT command, + the client MUST issue a "failed" DSN for that recipient. + +(d) If the NOTIFY parameter was supplied for a recipient with an esmtp- + value of NEVER, the client MUST NOT issue a DSN for that recipient, + regardless of the reply-code returned by the SMTP server. However, + if the server returned a failure (5xx) reply-code, the client MAY + inform the local postmaster of the delivery failure via an + appropriate mechanism that will not itself result in the generation + of DSNs. + + + + +Moore Standards Track [Page 11] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + When attempting to relay a message to an SMTP server that does not + support this extension, and if NOTIFY=NEVER was specified for some + recipients of that message, a conforming SMTP client MAY relay the + message for those recipients in a separate SMTP transaction, using + an empty reverse-path in the MAIL command. This will prevent DSNs + from being issued for those recipients by MTAs that conform to [1]. + +(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP + server returns a success (2xx) reply-code in response to a RCPT + command, the client MUST NOT issue any DSN for that recipient. + +(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP + server returns a permanent failure (5xx) reply-code in response to a + RCPT command, the client MUST issue a "failed" DSN for that + recipient. + +6.2.3 Local delivery of messages + + The following rules govern the behavior of a conforming MTA upon + successful delivery of a message that was received via the SMTP + protocol, to a local recipient's mailbox: + + "Delivery" means that the message has been placed in the recipient's + mailbox. For messages which are transmitted to a mailbox for later + retrieval via IMAP [6], POP [7] or a similar message access protocol, + "delivery" occurs when the message is made available to the IMAP + (POP, etc.) service, rather than when the message is retrieved by the + recipient's user agent. + + Similarly, for a recipient address which corresponds to a mailing + list exploder, "delivery" occurs when the message is made available + to that list exploder, even though the list exploder might refuse to + deliver that message to the list recipients. + +(a) If the NOTIFY parameter was supplied for that recipient, with an + esmtp-value containing the SUCCESS keyword, the MTA MUST issue a + "delivered" DSN for that recipient. + +(b) If the NOTIFY parameter was supplied for that recipient which did + not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for + that recipient. + +(c) If the NOTIFY parameter was not supplied for that recipient, the MTA + MUST NOT issue a DSN. + + + + + + + +Moore Standards Track [Page 12] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2.4 Gatewaying a message into a foreign environment + + The following rules govern the behavior of a conforming MTA, when + gatewaying a message that was received via the SMTP protocol, into a + foreign (non-SMTP) environment: + +(a) If the the foreign environment is capable of issuing appropriate + notifications under the conditions requested by the NOTIFY + parameter, and the conforming MTA can ensure that any notification + thus issued will be translated into a DSN and delivered to the + original sender, then the MTA SHOULD gateway the message into the + foreign environment, requesting notification under the desired + conditions, without itself issuing a DSN. + +(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the + destination environment cannot return an appropriate notification on + successful delivery, the MTA SHOULD issue a "relayed" DSN for that + recipient. + +(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a + DSN MUST NOT be issued. If possible, the MTA SHOULD direct the + destination environment to not issue delivery notifications for that + recipient. + +(d) If the NOTIFY parameter was not supplied for a particular recipient, + a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD + attempt to ensure that appropriate notification will be provided by + the foreign mail environment if eventual delivery failure occurs, + and that no notification will be issued on successful delivery. + +(e) When gatewaying a message into a foreign environment, the return-of- + content conditions specified by any RET parameter are nonbinding; + however, the MTA SHOULD attempt to honor the request using whatever + mechanisms exist in the foreign environment. + +6.2.5 Delays in delivery + + If a conforming MTA receives a message via the SMTP protocol, and is + unable to deliver or relay the message to one or more recipients for + an extended length of time (to be determined by the MTA), it MAY + issue a "delayed" DSN for those recipients, subject to the following + conditions: + +(a) If the NOTIFY parameter was supplied for a recipient and its value + included the DELAY keyword, a "delayed" DSN MAY be issued. + +(b) If the NOTIFY parameter was not supplied for a recipient, a + "delayed" DSN MAY be issued. + + + +Moore Standards Track [Page 13] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If the NOTIFY parameter was supplied which did not contain the DELAY + keyword, a "delayed" DSN MUST NOT be issued. + + NOTE: Although delay notifications are common in present-day + electronic mail, a conforming MTA is never required to issue + "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is + provided to allow the SMTP client to specifically request (by + omitting the DELAY parameter) that "delayed" DSNs NOT be issued. + +6.2.6 Failure of a conforming MTA to deliver a message + + The following rules govern the behavior of a conforming MTA which + received a message via the SMTP protocol, and is unable to deliver a + message to a recipient specified in the SMTP transaction: + +(a) If a NOTIFY parameter was supplied for the recipient with an esmtp- + keyword containing the value FAILURE, a "failed" DSN MUST be issued + by the MTA. + +(b) If a NOTIFY parameter was supplied for the recipient which did not + contain the value FAILURE, a DSN MUST NOT be issued for that + recipient. However, the MTA MAY inform the local postmaster of the + delivery failure via some appropriate mechanism which does not + itself result in the generation of DSNs. + +(c) If no NOTIFY parameter was supplied for the recipient, a "failed" + DSN MUST be issued. + + NOTE: Some MTAs are known to forward undeliverable messages to the + local postmaster or "dead letter" mailbox. This is still considered + delivery failure, and does not diminish the requirement to issue a + "failed" DSN under the conditions defined elsewhere in this memo. If + a DSN is issued for such a recipient, the Action value MUST be + "failed". + +6.2.7 Forwarding, aliases, and mailing lists + + Delivery of a message to a local email address usually causes the + message to be stored in the recipient's mailbox. However, MTAs + commonly provide a facility where a local email address can be + designated as an "alias" or "mailing list"; delivery to that address + then causes the message to be forwarded to each of the (local or + remote) recipient addresses associated with the alias or list. It is + also common to allow a user to optionally "forward" her mail to one + or more alternate addresses. If this feature is enabled, her mail is + redistributed to those addresses instead of being deposited in her + mailbox. + + + + +Moore Standards Track [Page 14] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + Following the example of [9] (section 5.3.6), this document defines + the difference between an "alias" and "mailing list" as follows: When + forwarding a message to the addresses associated with an "alias", the + envelope return address (e.g. SMTP MAIL FROM) remains intact. + However, when forwarding a message to the addresses associated with a + "mailing list", the envelope return address is changed to that of the + administrator of the mailing list. This causes DSNs and other + nondelivery reports resulting from delivery to the list members to be + sent to the list administrator rather than the sender of the original + message. + + The DSN processing for aliases and mailing lists is as follows: + +6.2.7.1 mailing lists + + When a message is delivered to a list submission address (i.e. placed + in the list's mailbox for incoming mail, or accepted by the process + that redistributes the message to the list subscribers), this is + considered final delivery for the original message. If the NOTIFY + parameter for the list submission address contained the SUCCESS + keyword, a "delivered" DSN MUST be returned to the sender of the + original message. + + NOTE: Some mailing lists are able to reject message submissions, + based on the content of the message, the sender's address, or some + other criteria. While the interface between such a mailing list and + its MTA is not well-defined, it is important that DSNs NOT be issued + by both the MTA (to report successful delivery to the list), and the + list (to report message rejection using a "failure" DSN.) + + However, even if a "delivered" DSN was issued by the MTA, a mailing + list which rejects a message submission MAY notify the sender that + the message was rejected using an ordinary message instead of a DSN. + + Whenever a message is redistributed to an mailing list, + +(a) The envelope return address is rewritten to point to the list + maintainer. This address MAY be that of a process that recognizes + DSNs and processes them automatically, but it MUST forward + unrecognized messages to the human responsible for the list. + +(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the + redistributed message MUST NOT be derived from those of the original + message. + +(c) The NOTIFY and RET parameters MAY be specified by the local + postmaster or the list administrator. If ORCPT parameters are + supplied during redistribution to the list subscribers, they SHOULD + + + +Moore Standards Track [Page 15] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + contain the addresses of the list subscribers in the format used by + the mailing list. + +6.2.7.2 single-recipient aliases + + Under normal circumstances, when a message arrives for an "alias" + which has a single forwarding address, a DSN SHOULD NOT be issued. + Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with + the message as it is redistributed to the forwarding address. + +6.2.7.3 multiple-recipient aliases + + An "alias" with multiple recipient addresses may be handled in any of + the following ways: + +(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when + relaying the message to any of the forwarding addresses. If the + NOTIFY parameter for the alias contained the SUCCESS keyword, the + MTA issues a "relayed" DSN. (In effect, the MTA treats the message + as if it were being relayed into an environment that does not + support DSNs.) + +(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent + requests if the message is gatewayed) are propagated to EXACTLY one + of the forwarding addresses. No DSN is issued. (This is + appropriate when aliasing is used to forward a message to a + "vacation" auto-responder program in addition to the local mailbox.) + +(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding + addresses associated with that alias. The NOTIFY parameter is + propagated to the forwarding addresses, except that it any SUCCESS + keyword is removed. If the original NOTIFY parameter for the alias + contained the SUCCESS keyword, an "expanded" DSN is issued for the + alias. If the NOTIFY parameter for the alias did not contain the + SUCCESS keyword, no DSN is issued for the alias. + +6.2.7.4 confidential forwarding addresses + + If it is desired to maintain the confidentiality of a recipient's + forwarding address, the forwarding may be treated as if it were a + mailing list. A DSN will be issued, if appropriate, upon "delivery" + to the recipient address specified by the sender. When the message + is forwarded it will have a new envelope return address. Any DSNs + which result from delivery failure of the forwarded message will not + be returned to the original sender of the message and thus not expose + the recipient's forwarding address. + + + + + +Moore Standards Track [Page 16] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +6.2.8 DSNs describing delivery to multiple recipients + + A single DSN may describe attempts to deliver a message to multiple + recipients of that message. If a DSN is issued for some recipients + in an SMTP transaction and not for others according to the rules + above, the DSN SHOULD NOT contain information for recipients for whom + DSNs would not otherwise have been issued. + +6.3 Handling of messages from other sources + + For messages which originated from "local" users (whatever that + means), the specifications under which DSNs should be generated can + be communicated to the MTA via any protocol agreed on between the + sender's mail composer (user agent) and the MTA. The local MTA can + then either relay the message, or issue appropriate delivery status + notifications. However, if such requests are transmitted within the + message itself (for example in the message headers), the requests + MUST be removed from the message before it is transmitted via SMTP. + + For messages gatewayed from non-SMTP sources and further relayed by + SMTP, the gateway SHOULD, using the SMTP extensions described here, + attempt to provide the delivery reporting conditions expected by the + source mail environment. If appropriate, any DSNs returned to the + source environment SHOULD be translated into the format expected in + that environment. + +6.4 Implementation limits + + A conforming MTA MUST accept ESMTP parameters of at least the + following sizes: + + (a) ENVID parameter: 100 characters. + + (b) NOTIFY parameter: 28 characters. + + (c) ORCPT parameter: 500 characters. + + (d) RET parameter: 8 characters. + + The maximum sizes for the ENVID and ORCPT parameters are intended to + be adequate for the transmission of "foreign" envelope identifier and + original recipient addresses. However, user agents which use SMTP as + a message submission protocol SHOULD NOT generate ENVID parameters + which are longer than 38 characters in length. + + A conforming MTA MUST be able to accept SMTP command-lines which are + at least 1036 characters long (530 characters for the ORCPT and + NOTIFY parameters of the RCPT command, in addition to the 512 + + + +Moore Standards Track [Page 17] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + characters required by [1]). If other SMTP extensions are supported + by the MTA, the MTA MUST be able to accept a command-line large + enough for each SMTP command and any combination of ESMTP parameters + which may be used with that command. + +7. Format of delivery notifications + + The format of delivery status notifications is defined in [5], which + uses the framework defined in [8]. Delivery status notifications are + to be returned to the sender of the original message as outlined + below. + +7.1 SMTP Envelope to be used with delivery status notifications + + The DSN sender address (in the SMTP MAIL command) MUST be a null + reverse-path ("<>"), as required by section 5.3.3 of [9]. The DSN + recipient address (in the RCPT command) is copied from the MAIL + command which accompanied the message for which the DSN is being + issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT + be used. The NOTIFY parameter MAY be used, but its value MUST be + NEVER. The ENVID parameter (with a newly generated envelope-id) + and/or ORCPT parameter MAY be used. + +7.2 Contents of the DSN + + A DSN is transmitted as a MIME message with a top-level content-type + of multipart/report (as defined in [5]). + + The multipart/report content-type may be used for any of several + kinds of reports generated by the mail system. When multipart/report + is used to convey a DSN, the report-type parameter of the + multipart/report content-type is "delivery-status". + + As described in [8], the first component of a multipart/report + content-type is a human readable explanation of the report. For a + DSN, the second component of the multipart/report is of content-type + message/delivery-status (defined in [5]). The third component of the + multipart/report consists of the original message or some portion + thereof. When the value of the RET parameter is FULL, the full + message SHOULD be returned for any DSN which conveys notification of + delivery failure. (However, if the length of the message is greater + than some implementation-specified length, the MTA MAY return only + the headers even if the RET parameter specified FULL.) If a DSN + contains no notifications of delivery failure, the MTA SHOULD return + only the headers. + + The third component must have an appropriate content-type label. + Issues concerning selection of the content-type are discussed in [8]. + + + +Moore Standards Track [Page 18] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +7.3 Message/delivery-status fields + + The message/delivery-status content-type defines a number of fields, + with general specifications for their contents. The following + requirements for any DSNs generated in response to a message received + by the SMTP protocol by a conforming SMTP server, are in addition to + the requirements defined in [5] for the message/delivery-status type. + + When generating a DSN for a message which was received via the SMTP + protocol, a conforming MTA will generate the following fields of the + message/delivery-status body part: + +(a) if an ENVID parameter was present on the MAIL command, an Original- + Envelope-ID field MUST be supplied, and the value associated with + the ENVID parameter must appear in that field. If the message was + received via SMTP with no ENVID parameter, the Original-Envelope-ID + field MUST NOT be supplied. + + Since the ENVID parameter is encoded as xtext, but the Original- + Envelope-ID header is NOT encoded as xtext, the MTA must decode the + xtext encoding when copying the ENVID value to the Original- + Envelope-ID field. + +(b) The Reporting-MTA field MUST be supplied. If Reporting MTA can + determine its fully-qualified Internet domain name, the MTA-name- + type subfield MUST be "dns", and the field MUST contain the fully- + qualified domain name of the Reporting MTA. If the fully-qualified + Internet domain name of the Reporting MTA is not known (for example, + for an SMTP server which is not directly connected to the Internet), + the Reporting-MTA field may contain any string identifying the MTA, + however, in this case the MTA-name-type subfield MUST NOT be "dns". + A MTA-name-type subfield value of "x-local-hostname" is suggested. + +(c) Other per-message fields as defined in [5] MAY be supplied as + appropriate. + +(d) If the ORCPT parameter was provided for this recipient, the + Original-Recipient field MUST be supplied, with its value taken from + the ORCPT parameter. If no ORCPT parameter was provided for this + recipient, the Original-Recipient field MUST NOT appear. + +(e) The Final-Recipient field MUST be supplied. It MUST contain the + recipient address from the message envelope. If the message was + received via SMTP, the address-type will be "rfc822". + +(f) The Action field MUST be supplied. + + + + + +Moore Standards Track [Page 19] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(g) The Status field MUST be supplied, using a status-code from [10]. + If there is no specific code which suitably describes a delivery + failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent + failure) MUST be used. + +(h) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, the Remote-MTA field MUST be supplied for each + of those recipients. The mta-name-type subfields of those Remote- + MTA fields will be "dns". + +(i) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, the Diagnostic-Code MUST be supplied for each + of those recipients. The diagnostic-type subfield will be "smtp". + See section 9.2(a) of this document for a description of the "smtp" + diagnostic-code. + +(j) For DSNs resulting from attempts to relay a message to one or more + recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be + supplied for each recipient, which contains the address of that + recpient which was presented to the remote SMTP server. + +(k) Other per-recipient fields defined in [5] MAY appear, as + appropriate. + +8. Acknowledgments + + The author wishes to thank Eric Allman, Harald Alvestrand, Jim + Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned + Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios + Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall + Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for + improvement of this document. + + + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 20] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +9. Appendix - Type-Name Definitions + + The following type names are defined for use in DSN fields generated + by conforming SMTP-based MTAs: + +9.1 "rfc822" address-type + + The "rfc822" address-type is to be used when reporting Internet + electronic mail address in the Original-Recipient and Final-Recipient + DSN fields. + +(a) address-type name: rfc822 + +(b) syntax for mailbox addresses + + RFC822 mailbox addresses are generally expected to be of the form + + [route] addr-spec + + where "route" and "addr-spec" are defined in [2], and the "domain" + portions of both "route" and "addr-spec" are fully-qualified domain + names that are registered in the DNS. However, an MTA MUST NOT + modify an address obtained from the message envelope to force it to + conform to syntax rules. + +(c) If addresses of this type are not composed entirely of graphic +characters from the US-ASCII repertoire, a specification for how they +are to be encoded as graphic US-ASCII characters in a DSN Original- +Recipient or Final-Recipient DSN field. + + RFC822 addresses consist entirely of graphic characters from the US- + ASCII repertoire, so no translation is necessary. + +9.2 "smtp" diagnostic-type + + The "smtp" diagnostic-type is to be used when reporting SMTP reply- + codes in Diagnostic-Code DSN fields. + +(a) diagnostic-type name: SMTP + +(b) A description of the syntax to be used for expressing diagnostic +codes of this type as graphic characters from the US-ASCII repertoire. + + An SMTP diagnostic-code is of the form + + *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text + + + + + +Moore Standards Track [Page 21] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + + For a single-line SMTP reply to an SMTP command, the diagnostic-code + SHOULD be an exact transcription of the reply. For multi-line SMTP + replies, it is necessary to insert a SPACE before each line after + the first. For example, an SMTP reply of: + + 550-mailbox unavailable + 550 user has moved with no forwarding address + + could appear as follows in a Diagnostic-Code DSN field: + + Diagnostic-Code: smtp ; 550-mailbox unavailable + 550 user has moved with no forwarding address + +(c) A list of valid diagnostic codes of this type and the meaning of +each code. + + SMTP reply-codes are currently defined in [1], [4], and [9]. + Additional codes may be defined by other RFCs. + +9.3 "dns" MTA-name-type + + The "dns" MTA-name-type should be used in the Reporting-MTA field. + An MTA-name of type "dns" is a fully-qualified domain name. The name + must be registered in the DNS, and the address Postmaster@{mta-name} + must be valid. + +(a) MTA-name-type name: dns + +(b) A description of the syntax of MTA names of this type, using BNF, +regular expressions, ASN.1, or other non-ambiguous language. + + MTA names of type "dns" SHOULD be valid Internet domain names. If + such domain names are not available, a domain-literal containing the + internet protocol address is acceptable. Such domain names + generally conform to the following syntax: + + domain = real-domain / domain-literal + + real-domain = sub-domain *("." sub-domain) + + sub-domain = atom + + domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]" + + where "atom" and "DIGIT" are defined in [2]. + + + + + + +Moore Standards Track [Page 22] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +(c) If MTA names of this type do not consist entirely of graphic +characters from the US-ASCII repertoire, a specification for how an MTA +name of this type should be expressed as a sequence of graphic US-ASCII +characters. + + MTA names of type "dns" consist entirely of graphic US-ASCII + characters, so no translation is needed. + +10. Appendix - Example + + This example traces the flow of a single message addressed to + multiple recipients. The message is sent by Alice@Pure-Heart.ORG to + Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, + Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a + variety of per-recipient options. The message is successfully + delivered to Bob, Dana (via a gateway), Eric, and Fred. Delivery + fails for Carol and George. + + NOTE: Formatting rules for RFCs require that no line be longer than + 72 characters. Therefore, in the following examples, some SMTP + commands longer than 72 characters are printed on two lines, with the + first line ending in "\". In an actual SMTP transaction, such a + command would be sent as a single line (i.e. with no embedded CRLFs), + and without the "\" character that appears in these examples. + +10.1 Submission + + Alice's user agent sends the message to the SMTP server at Pure- + Heart.ORG. Note that while this example uses SMTP as a mail + submission protocol, other protocols could also be used. + +<<< 220 Pure-Heart.ORG SMTP server here +>>> EHLO Pure-Heart.ORG +<<< 250-Pure-Heart.ORG +<<< 250-DSN +<<< 250-EXPN +<<< 250 SIZE +>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 +<<< 250 <Alice@Pure-Heart.ORG> sender ok +>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 <Bob@Big-Bucks.COM> recipient ok +>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 250 <Carol@Ivory.EDU> recipient ok +>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 <Dana@Ivory.EDU> recipient ok + + + +Moore Standards Track [Page 23] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \ + ORCPT=rfc822;Eric@Bombs.AF.MIL +<<< 250 <Eric@Bombs.AF.MIL> recipient ok +>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER +<<< 250 <Fred@Bombs.AF.MIL> recipient ok +>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 <George@Tax-ME.GOV> recipient ok +>>> DATA +<<< 354 okay, send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> QUIT +<<< 221 goodbye + +10.2 Relay to Big-Bucks.COM + + The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM. + (For the purpose of this example, mail.Big-Bucks.COM is the primary + mail exchanger for Big-Bucks.COM). + +<<< 220 mail.Big-Bucks.COM says hello +>>> EHLO Pure-Heart.ORG +<<< 250-mail.Big-Bucks.COM +<<< 250 DSN +>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 recipient okay +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bcnu + +10.3 Relay to Ivory.EDU + + The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as + it happens) is a gateway to a LAN-based mail system that accepts SMTP + mail and supports the DSN extension. + +<<< 220 Ivory.EDU gateway to FooMail(tm) here +>>> EHLO Pure-Heart.ORG +<<< 250-Ivory.EDU + + + +Moore Standards Track [Page 24] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +<<< 250 DSN +>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 +<<< 250 ok +>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 550 error - no such recipient +>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 recipient ok +>>> DATA +<<< 354 send message, end with '.' +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bye + + Note that since the Ivory.EDU refused to accept mail for + Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the + sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN. + +10.4 Relay to Bombs.AF.MIL + + The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which + does not support the SMTP extension. Because the sender specified + NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure- + Heart.ORG chooses to send the message for that recipient in a + separate transaction with a reverse-path of <>. + +<<< 220-Bombs.AF.MIL reporting for duty. +<<< 220 Electronic mail is to be used for official business only. +>>> EHLO Pure-Heart.ORG +<<< 502 command not implemented +>>> RSET +<<< 250 reset +>>> HELO Pure-Heart.ORG +<<< 250 Bombs.AF.MIL +>>> MAIL FROM:<Alice@Pure-Heart.ORG> +<<< 250 ok +>>> RCPT TO:<Eric@Bombs.AF.MIL> +<<< 250 ok +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> MAIL FROM:<> +<<< 250 ok + + + +Moore Standards Track [Page 25] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO:<Fred@Bombs.AF.MIL> +<<< 250 ok +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message accepted +>>> QUIT +<<< 221 Bombs.AF.MIL closing connection + +10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV + + The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV. (this + step is not shown). MTA Tax-ME.GOV then forwards the message to + Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Pure-Heart.ORG + support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all + retain their original values. + +<<< 220 BoonDoggle.GOV says hello +>>> EHLO Pure-Heart.ORG +<<< 250-mail.Big-Bucks.COM +<<< 250 DSN +>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 recipient okay +>>> DATA +<<< 354 send message +>>> (message goes here) +>>> . +<<< 250 message received +>>> QUIT +<<< 221 bcnu + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 26] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.6 "Delivered" DSN for Bob@Big-Bucks.COM + + MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big- + Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big- + Bucks.COM issues the following DSN, and sends it to Alice@Pure- + Heart.ORG. + +To: Alice@Pure-Heart.ORG +From: postmaster@mail.Big-Bucks.COM +Subject: Delivery Notification (success) for Bob@Big-Bucks.COM +Content-Type: multipart/report; report-type=delivery-status; + boundary=abcde +MIME-Version: 1.0 + +--abcde +Content-type: text/plain; charset=us-ascii + +Your message (id QQ314159) was successfully delivered to +Bob@Big-Bucks.COM. + +--abcde +Content-type: message/delivery-status + +Reporting-MTA: dns; mail.Big-Bucks.COM +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Bob@Big-Bucks.COM +Final-Recipient: rfc822;Bob@Big-Bucks.COM +Action: delivered +Status: 2.0.0 + +--abcde +Content-type: message/rfc822 + +(headers of returned message go here) + +--abcde-- + + + + + + + + + + + + + + +Moore Standards Track [Page 27] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.7 Failed DSN for Carol@Ivory.EDU + + Because delivery to Carol failed and the sender specified + NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP + client to which the failure was reported via SMTP) issues the + following DSN. + +To: Alice@Pure-Heart.ORG +From: postmaster@Pure-Heart.ORG +Subject: Delivery Notification (failure) for Carol@Ivory.EDU +Content-Type: multipart/report; report-type=delivery-status; + boundary=bcdef +MIME-Version: 1.0 + +--bcdef +Content-type: text/plain; charset=us-ascii + +Your message (id QQ314159) could not be delivered to +Carol@Ivory.EDU. + +A transcript of the session follows: + +(while talking to Ivory.EDU) +>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE +<<< 550 error - no such recipient + +--bcdef +Content-type: message/delivery-status + +Reporting-MTA: dns; Pure-Heart.ORG +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Carol@Ivory.EDU +Final-Recipient: rfc822;Carol@Ivory.EDU +SMTP-Remote-Recipient: Carol@Ivory.EDU +Diagnostic-Code: smtp; 550 error - no such recipient +Action: failed +Status: 5.0.0 + +--bcdef +Content-type: message/rfc822 + +(headers of returned message go here) + +--bcdef-- + + + + + + +Moore Standards Track [Page 28] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.8 Relayed DSN For Dana@Ivory.EDU + + Although the mail gateway Ivory.EDU supports the DSN SMTP extension, + the LAN mail system attached to its other side does not generate + positive delivery confirmations. So Ivory.EDU issues a "relayed" + DSN: + +To: Alice@Pure-Heart.ORG +From: postmaster@Ivory.EDU +Subject: mail relayed for Dana@Ivory.EDU +Content-Type: multipart/report; report-type=delivery-status; + boundary=cdefg +MIME-Version: 1.0 + +--cdefg +Content-type: text/plain; charset=us-ascii + +Your message (addressed to Dana@Ivory.EDU) was successfully +relayed to: + +ymail!Dana + +by the FooMail gateway at Ivory.EDU. + +Unfortunately, the remote mail system does not support +confirmation of actual delivery. Unless delivery to ymail!Dana +fails, this will be the only delivery status notification sent. + +--cdefg +Content-type: message/delivery-status + +Reporting-MTA: dns; Ivory.EDU +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;Dana@Ivory.EDU +Final-Recipient: rfc822;Dana@Ivory.EDU +Action: relayed +Status: 2.0.0 + +--cdefg +Content-type: message/rfc822 + +(headers of returned message go here) + +--cdefg-- + + + + + + +Moore Standards Track [Page 29] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +10.9 Failure notification for Sam@Boondoggle.GOV + + The message originally addressed to George@Tax-ME.GOV was forwarded + to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to + deliver the message due to a lack of disk space in Sam's mailbox. + After trying for several days, Boondoggle.GOV returned the following + DSN: + +To: Alice@BigHeart.ORG +From: Postmaster@Boondoggle.GOV +Subject: Delivery failure for Sam@Boondoggle.GOV +Content-Type: multipart/report; report-type=delivery-status; + boundary=defgh +MIME-Version: 1.0 + +--defgh +Your message, originally addressed to George@Tax-ME.GOV, and forwarded +from there to Sam@Boondoggle.GOV could not be delivered, for the +following reason: + +write error to mailbox, disk quota exceeded + +--defgh +Content-type: message/delivery-status + +Reporting-MTA: Boondoggle.GOV +Original-Envelope-ID: QQ314159 + +Original-Recipient: rfc822;George@Tax-ME.GOV +Final-Recipient: rfc822;Sam@Boondoggle.GOV +Action: failed +Status: 4.2.2 (disk quota exceeded) + +--defgh +Content-type: message/rfc822 + +(headers of returned message go here) + +--defgh-- + + + + + + + + + + + + +Moore Standards Track [Page 30] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +11. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Westine, A., and J. Postel, "Problems with the Maintenance of + Large Mailing Lists.", RFC 1211, USC/Information Sciences + Institute, March 1991. + + [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, + "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., Silicon + Graphics, Inc., July 1994. + + [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of Tennessee, + Octel Network Services, January 1996. + + [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC + 1730, University of Washington, 20 December 1994. + + [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC + 1725, Carnegie Mellon, Dover Beach Consulting, November 1994. + + [8] Vaudreuil, G., "The Multipart/Report Content Type for the + Reporting of Mail System Administrative Messages", RFC 1892, Octel + Network Services, January 1996. + + [9] Braden, R., Editor, "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, IETF, October 1989. + + [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, + Octel Network Services, January 1996. + +12. Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + + + + + +Moore Standards Track [Page 31] + diff --git a/RFC/rfc1892.txt b/RFC/rfc1892.txt new file mode 100644 index 00000000..c4bdbd5f --- /dev/null +++ b/RFC/rfc1892.txt @@ -0,0 +1,227 @@ + + + + + + +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] + diff --git a/RFC/rfc1893.txt b/RFC/rfc1893.txt new file mode 100644 index 00000000..9ca4efb5 --- /dev/null +++ b/RFC/rfc1893.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group G. Vaudreuil +Request for Comments: 1893 Octel Network Services +Category: Standards Track January 1996 + + + Enhanced Mail System Status 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. + +1. Overview + + There currently is not a standard mechanism for the reporting of mail + system errors except for the limited set offered by SMTP and the + system specific text descriptions sent in mail messages. There is a + pressing need for a rich machine readable status code for use in + delivery status notifications [DSN]. This document proposes a new + set of status codes for this purpose. + + SMTP [SMTP] error codes have historically been used for reporting + mail system errors. Because of limitations in the SMTP code design, + these are not suitable for use in delivery status notifications. + SMTP provides about 12 useful codes for delivery reports. The + majority of the codes are protocol specific response codes such as + the 354 response to the SMTP data command. Each of the 12 useful + codes are each overloaded to indicate several error conditions each. + SMTP suffers some scars from history, most notably the unfortunate + damage to the reply code extension mechanism by uncontrolled use. + This proposal facilitates future extensibility by requiring the + client to interpret unknown error codes according to the theory of + codes while requiring servers to register new response codes. + + The SMTP theory of reply codes partitioned in the number space such a + manner that the remaining available codes will not provide the space + needed. The most critical example is the existence of only 5 + remaining codes for mail system errors. The mail system + classification includes both host and mailbox error conditions. The + remaining third digit space would be completely consumed as needed to + indicate MIME and media conversion errors and security system errors. + + A revision to the SMTP theory of reply codes to better distribute the + error conditions in the number space will necessarily be incompatible + with SMTP. Further, consumption of the remaining reply-code number + + + +Vaudreuil Standards Track [Page 1] + +RFC 1893 Mail System Status Codes January 1996 + + + space for delivery notification reporting will reduce the available + codes for new ESMTP extensions. + + The following proposal is based on the SMTP theory of reply codes. + It adopts the success, permanent error, and transient error semantics + of the first value, with a further description and classification in + the second. This proposal re-distributes the classifications to + better distribute the error conditions, such as separating mailbox + from host errors. + +2. Status Codes + + This document defines a new set of status codes to report mail system + conditions. These status codes are intended to be used for media and + language independent status reporting. They are not intended for + system specific diagnostics. + + The syntax of the new status codes is defined as: + + status-code = class "." subject "." detail + class = "2"/"4"/"5" + subject = 1*3digit + detail = 1*3digit + + White-space characters and comments are NOT allowed within a status- + code. Each numeric sub-code within the status-code MUST be expressed + without leading zero digits. + + Status codes consist of three numerical fields separated by ".". The + first sub-code indicates whether the delivery attempt was successful. + The second sub-code indicates the probable source of any delivery + anomalies, and the third sub-code indicates a precise error + condition. + + The codes space defined is intended to be extensible only by + standards track documents. Mail system specific status codes should + be mapped as close as possible to the standard status codes. Servers + should send only defined, registered status codes. System specific + errors and diagnostics should be carried by means other than status + codes. + + New subject and detail codes will be added over time. Because the + number space is large, it is not intended that published status codes + will ever be redefined or eliminated. Clients should preserve the + extensibility of the code space by reporting the general error + described in the subject sub-code when the specific detail is + unrecognized. + + + + +Vaudreuil Standards Track [Page 2] + +RFC 1893 Mail System Status Codes January 1996 + + + The class sub-code provides a broad classification of the status. + The enumerated values the class are defined as: + + 2.X.X Success + + Success specifies that the DSN is reporting a positive delivery + action. Detail sub-codes may provide notification of + transformations required for delivery. + + 4.X.X Persistent Transient Failure + + A persistent transient failure is one in which the message as + sent is valid, but some temporary event prevents the successful + sending of the message. Sending in the future may be successful. + + 5.X.X Permanent Failure + + A permanent failure is one which is not likely to be resolved by + resending the message in the current form. Some change to the + message or the destination must be made for successful delivery. + + A client must recognize and report class sub-code even where + subsequent subject sub-codes are unrecognized. + + The subject sub-code classifies the status. This value applies to + each of the three classifications. The subject sub-code, if + recognized, must be reported even if the additional detail provided + by the detail sub-code is not recognized. The enumerated values for + the subject sub-code are: + + X.0.X Other or Undefined Status + + There is no additional subject information available. + + X.1.X Addressing Status + + The address status reports on the originator or destination + address. It may include address syntax or validity. These + errors can generally be corrected by the sender and retried. + + X.2.X Mailbox Status + + Mailbox status indicates that something having to do with the + mailbox has cause this DSN. Mailbox issues are assumed to be + under the general control of the recipient. + + + + + + +Vaudreuil Standards Track [Page 3] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.X Mail System Status + + Mail system status indicates that something having to do + with the destination system has caused this DSN. System + issues are assumed to be under the general control of the + destination system administrator. + + X.4.X Network and Routing Status + + The networking or routing codes report status about the + delivery system itself. These system components include any + necessary infrastructure such as directory and routing + services. Network issues are assumed to be under the + control of the destination or intermediate system + administrator. + + X.5.X Mail Delivery Protocol Status + + The mail delivery protocol status codes report failures + involving the message delivery protocol. These failures + include the full range of problems resulting from + implementation errors or an unreliable connection. Mail + delivery protocol issues may be controlled by many parties + including the originating system, destination system, or + intermediate system administrators. + + X.6.X Message Content or Media Status + + The message content or media status codes report failures + involving the content of the message. These codes report + failures due to translation, transcoding, or otherwise + unsupported message media. Message content or media issues + are under the control of both the sender and the receiver, + both of whom must support a common set of supported + content-types. + + X.7.X Security or Policy Status + + The security or policy status codes report failures + involving policies such as per-recipient or per-host + filtering and cryptographic operations. Security and policy + status issues are assumed to be under the control of either + or both the sender and recipient. Both the sender and + recipient must permit the exchange of messages and arrange + the exchange of necessary keys and certificates for + cryptographic operations. + + + + + +Vaudreuil Standards Track [Page 4] + +RFC 1893 Mail System Status Codes January 1996 + + +3. Enumerated Status Codes + + The following section defines and describes the detail sub-code. The + detail value provides more information about the status and is + defined relative to the subject of the status. + + 3.1 Other or Undefined Status + + X.0.0 Other undefined Status + + Other undefined status is the only undefined error code. It + should be used for all errors for which only the class of the + error is known. + + 3.2 Address Status + + X.1.0 Other address status + + Something about the address specified in the message caused + this DSN. + + X.1.1 Bad destination mailbox address + + The mailbox specified in the address does not exist. For + Internet mail names, this means the address portion to the + left of the "@" sign is invalid. This code is only useful + for permanent failures. + + X.1.2 Bad destination system address + + The destination system specified in the address does not + exist or is incapable of accepting mail. For Internet mail + names, this means the address portion to the right of the + "@" is invalid for mail. This codes is only useful for + permanent failures. + + X.1.3 Bad destination mailbox address syntax + + The destination address was syntactically invalid. This can + apply to any field in the address. This code is only useful + for permanent failures. + + X.1.4 Destination mailbox address ambiguous + + The mailbox address as specified matches one or more + recipients on the destination system. This may result if a + heuristic address mapping algorithm is used to map the + specified address to a local mailbox name. + + + +Vaudreuil Standards Track [Page 5] + +RFC 1893 Mail System Status Codes January 1996 + + + X.1.5 Destination address valid + + This mailbox address as specified was valid. This status + code should be used for positive delivery reports. + + X.1.6 Destination mailbox has moved, No forwarding address + + The mailbox address provided was at one time valid, but mail + is no longer being accepted for that address. This code is + only useful for permanent failures. + + X.1.7 Bad sender's mailbox address syntax + + The sender's address was syntactically invalid. This can + apply to any field in the address. + + X.1.8 Bad sender's system address + + The sender's system specified in the address does not exist + or is incapable of accepting return mail. For domain names, + this means the address portion to the right of the "@" is + invalid for mail. + + 3.3 Mailbox Status + + X.2.0 Other or undefined mailbox status + + The mailbox exists, but something about the destination + mailbox has caused the sending of this DSN. + + X.2.1 Mailbox disabled, not accepting messages + + The mailbox exists, but is not accepting messages. This may + be a permanent error if the mailbox will never be re-enabled + or a transient error if the mailbox is only temporarily + disabled. + + X.2.2 Mailbox full + + The mailbox is full because the user has exceeded a + per-mailbox administrative quota or physical capacity. The + general semantics implies that the recipient can delete + messages to make more space available. This code should be + used as a persistent transient failure. + + + + + + + +Vaudreuil Standards Track [Page 6] + +RFC 1893 Mail System Status Codes January 1996 + + + X.2.3 Message length exceeds administrative limit + + A per-mailbox administrative message length limit has been + exceeded. This status code should be used when the + per-mailbox message length limit is less than the general + system limit. This code should be used as a permanent + failure. + + X.2.4 Mailing list expansion problem + + The mailbox is a mailing list address and the mailing list + was unable to be expanded. This code may represent a + permanent failure or a persistent transient failure. + + 3.4 Mail system status + + X.3.0 Other or undefined mail system status + + The destination system exists and normally accepts mail, but + something about the system has caused the generation of this + DSN. + + X.3.1 Mail system full + + Mail system storage has been exceeded. The general + semantics imply that the individual recipient may not be + able to delete material to make room for additional + messages. This is useful only as a persistent transient + error. + + X.3.2 System not accepting network messages + + The host on which the mailbox is resident is not accepting + messages. Examples of such conditions include an immanent + shutdown, excessive load, or system maintenance. This is + useful for both permanent and permanent transient errors. + + X.3.3 System not capable of selected features + + Selected features specified for the message are not + supported by the destination system. This can occur in + gateways when features from one domain cannot be mapped onto + the supported feature in another. + + + + + + + + +Vaudreuil Standards Track [Page 7] + +RFC 1893 Mail System Status Codes January 1996 + + + X.3.4 Message too big for system + + The message is larger than per-message size limit. This + limit may either be for physical or administrative reasons. + This is useful only as a permanent error. + + X.3.5 System incorrectly configured + + The system is not configured in a manner which will permit + it to accept this message. + + 3.5 Network and Routing Status + + X.4.0 Other or undefined network or routing status + + Something went wrong with the networking, but it is not + clear what the problem is, or the problem cannot be well + expressed with any of the other provided detail codes. + + X.4.1 No answer from host + + The outbound connection attempt was not answered, either + because the remote system was busy, or otherwise unable to + take a call. This is useful only as a persistent transient + error. + + X.4.2 Bad connection + + The outbound connection was established, but was otherwise + unable to complete the message transaction, either because + of time-out, or inadequate connection quality. This is + useful only as a persistent transient error. + + X.4.3 Directory server failure + + The network system was unable to forward the message, + because a directory server was unavailable. This is useful + only as a persistent transient error. + + The inability to connect to an Internet DNS server is one + example of the directory server failure error. + + X.4.4 Unable to route + + The mail system was unable to determine the next hop for the + message because the necessary routing information was + unavailable from the directory server. This is useful for + both permanent and persistent transient errors. + + + +Vaudreuil Standards Track [Page 8] + +RFC 1893 Mail System Status Codes January 1996 + + + A DNS lookup returning only an SOA (Start of Administration) + record for a domain name is one example of the unable to + route error. + + X.4.5 Mail system congestion + + The mail system was unable to deliver the message because + the mail system was congested. This is useful only as a + persistent transient error. + + X.4.6 Routing loop detected + + A routing loop caused the message to be forwarded too many + times, either because of incorrect routing tables or a user + forwarding loop. This is useful only as a persistent + transient error. + + X.4.7 Delivery time expired + + The message was considered too old by the rejecting system, + either because it remained on that host too long or because + the time-to-live value specified by the sender of the + message was exceeded. If possible, the code for the actual + problem found when delivery was attempted should be returned + rather than this code. This is useful only as a persistent + transient error. + + 3.6 Mail Delivery Protocol Status + + X.5.0 Other or undefined protocol status + + Something was wrong with the protocol necessary to deliver + the message to the next hop and the problem cannot be well + expressed with any of the other provided detail codes. + + X.5.1 Invalid command + + A mail transaction protocol command was issued which was + either out of sequence or unsupported. This is useful only + as a permanent error. + + X.5.2 Syntax error + + A mail transaction protocol command was issued which could + not be interpreted, either because the syntax was wrong or + the command is unrecognized. This is useful only as a + permanent error. + + + + +Vaudreuil Standards Track [Page 9] + +RFC 1893 Mail System Status Codes January 1996 + + + X.5.3 Too many recipients + + More recipients were specified for the message than could + have been delivered by the protocol. This error should + normally result in the segmentation of the message into two, + the remainder of the recipients to be delivered on a + subsequent delivery attempt. It is included in this list in + the event that such segmentation is not possible. + + X.5.4 Invalid command arguments + + A valid mail transaction protocol command was issued with + invalid arguments, either because the arguments were out of + range or represented unrecognized features. This is useful + only as a permanent error. + + X.5.5 Wrong protocol version + + A protocol version mis-match existed which could not be + automatically resolved by the communicating parties. + + 3.7 Message Content or Message Media Status + + X.6.0 Other or undefined media error + + Something about the content of a message caused it to be + considered undeliverable and the problem cannot be well + expressed with any of the other provided detail codes. + + X.6.1 Media not supported + + The media of the message is not supported by either the + delivery protocol or the next system in the forwarding path. + This is useful only as a permanent error. + + X.6.2 Conversion required and prohibited + + The content of the message must be converted before it can + be delivered and such conversion is not permitted. Such + prohibitions may be the expression of the sender in the + message itself or the policy of the sending host. + + X.6.3 Conversion required but not supported + + The message content must be converted to be forwarded but + such conversion is not possible or is not practical by a + host in the forwarding path. This condition may result when + an ESMTP gateway supports 8bit transport but is not able to + + + +Vaudreuil Standards Track [Page 10] + +RFC 1893 Mail System Status Codes January 1996 + + + downgrade the message to 7 bit as required for the next hop. + + X.6.4 Conversion with loss performed + + This is a warning sent to the sender when message delivery + was successfully but when the delivery required a conversion + in which some data was lost. This may also be a permanant + error if the sender has indicated that conversion with loss + is prohibited for the message. + + X.6.5 Conversion Failed + + A conversion was required but was unsuccessful. This may be + useful as a permanent or persistent temporary notification. + + 3.8 Security or Policy Status + + X.7.0 Other or undefined security status + + Something related to security caused the message to be + returned, and the problem cannot be well expressed with any + of the other provided detail codes. This status code may + also be used when the condition cannot be further described + because of security policies in force. + + X.7.1 Delivery not authorized, message refused + + The sender is not authorized to send to the destination. + This can be the result of per-host or per-recipient + filtering. This memo does not discuss the merits of any + such filtering, but provides a mechanism to report such. + This is useful only as a permanent error. + + X.7.2 Mailing list expansion prohibited + + The sender is not authorized to send a message to the + intended mailing list. This is useful only as a permanent + error. + + X.7.3 Security conversion required but not possible + + A conversion from one secure messaging protocol to another + was required for delivery and such conversion was not + possible. This is useful only as a permanent error. + + + + + + + +Vaudreuil Standards Track [Page 11] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.4 Security features not supported + + A message contained security features such as secure + authentication which could not be supported on the delivery + protocol. This is useful only as a permanent error. + + X.7.5 Cryptographic failure + + A transport system otherwise authorized to validate or + decrypt a message in transport was unable to do so because + necessary information such as key was not available or such + information was invalid. + + X.7.6 Cryptographic algorithm not supported + + A transport system otherwise authorized to validate or + decrypt a message was unable to do so because the necessary + algorithm was not supported. + + X.7.7 Message integrity failure + + A transport system otherwise authorized to validate a + message was unable to do so because the message was + corrupted or altered. This may be useful as a permanent, + transient persistent, or successful delivery code. + +4. References + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + + [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, University of + Tennessee, Octel Network Services, January 1996. + +5. Security Considerations + + This document describes a status code system with increased + precision. Use of these status codes may disclose additional + information about how an internal mail system is implemented beyond + that currently available. + +6. Acknowledgments + + The author wishes to offer special thanks to Harald Alvestrand, Marko + Kaittola, and Keith Moore for their extensive review and constructive + suggestions. + + + + +Vaudreuil Standards Track [Page 12] + +RFC 1893 Mail System Status Codes January 1996 + + +7. Author's Address + + Gregory M. Vaudreuil + Octel Network Services + 17060 Dallas Parkway + Suite 214 + Dallas, TX 75248-1905 + + Voice/Fax: +1-214-733-2722 + EMail: Greg.Vaudreuil@Octel.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 13] + +RFC 1893 Mail System Status Codes January 1996 + + +8. Appendix - Collected Status Codes + + X.1.0 Other address status + X.1.1 Bad destination mailbox address + X.1.2 Bad destination system address + X.1.3 Bad destination mailbox address syntax + X.1.4 Destination mailbox address ambiguous + X.1.5 Destination mailbox address valid + X.1.6 Mailbox has moved + X.1.7 Bad sender's mailbox address syntax + X.1.8 Bad sender's system address + + X.2.0 Other or undefined mailbox status + X.2.1 Mailbox disabled, not accepting messages + X.2.2 Mailbox full + X.2.3 Message length exceeds administrative limit. + X.2.4 Mailing list expansion problem + + X.3.0 Other or undefined mail system status + X.3.1 Mail system full + X.3.2 System not accepting network messages + X.3.3 System not capable of selected features + X.3.4 Message too big for system + + X.4.0 Other or undefined network or routing status + X.4.1 No answer from host + X.4.2 Bad connection + X.4.3 Routing server failure + X.4.4 Unable to route + X.4.5 Network congestion + X.4.6 Routing loop detected + X.4.7 Delivery time expired + + X.5.0 Other or undefined protocol status + X.5.1 Invalid command + X.5.2 Syntax error + X.5.3 Too many recipients + X.5.4 Invalid command arguments + X.5.5 Wrong protocol version + + X.6.0 Other or undefined media error + X.6.1 Media not supported + X.6.2 Conversion required and prohibited + X.6.3 Conversion required but not supported + X.6.4 Conversion with loss performed + X.6.5 Conversion failed + + + + + +Vaudreuil Standards Track [Page 14] + +RFC 1893 Mail System Status Codes January 1996 + + + X.7.0 Other or undefined security status + X.7.1 Delivery not authorized, message refused + X.7.2 Mailing list expansion prohibited + X.7.3 Security conversion required but not possible + X.7.4 Security features not supported + X.7.5 Cryptographic failure + X.7.6 Cryptographic algorithm not supported + X.7.7 Message integrity failure + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vaudreuil Standards Track [Page 15] + diff --git a/RFC/rfc1894.txt b/RFC/rfc1894.txt new file mode 100644 index 00000000..f1fc90d4 --- /dev/null +++ b/RFC/rfc1894.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1894 University of Tennessee +Category: Standards Track G. Vaudreuil + Octel Network Services + January 1996 + + + An Extensible Message Format for Delivery Status Notifications + +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 memo defines a MIME content-type that may be used by a message + transfer agent (MTA) or electronic mail gateway to report the result + of an attempt to deliver a message to one or more recipients. This + content-type is intended as a machine-processable replacement for the + various types of delivery status notifications currently used in + Internet electronic mail. + + Because many messages are sent between the Internet and other + messaging systems (such as X.400 or the so-called "LAN-based" + systems), the DSN protocol is designed to be useful in a multi- + protocol messaging environment. To this end, the protocol described + in this memo provides for the carriage of "foreign" addresses and + error codes, in addition to those normally used in Internet mail. + Additional attributes may also be defined to support "tunneling" of + foreign notifications through Internet mail. + + Any questions, comments, and reports of defects or ambiguities in + this specification may be sent to the mailing list for the NOTARY + working group of the IETF, using the address + <notifications@cs.utk.edu>. Requests to subscribe to the mailing + list should be addressed to <notifications-request@cs.utk.edu>. + Implementors of this specification are encouraged to subscribe to the + mailing list, so that they will quickly be informed of any problems + which might hinder interoperability. + + NOTE: This document is a Proposed Standard. If and when this + protocol is submitted for Draft Standard status, any normative text + (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in + this document will be re-evaluated in light of implementation + + + +Moore & Vaudreuil Standards Track [Page 1] + +RFC 1894 Delivery Status Notifications January 1996 + + + experience, and are thus subject to change. + +1. Introduction + + This memo defines a MIME [1] content-type for delivery status + notifications (DSNs). A DSN can be used to notify the sender of a + message of any of several conditions: failed delivery, delayed + delivery, successful delivery, or the gatewaying of a message into an + environment that may not support DSNs. The "message/delivery-status" + content-type defined herein is intended for use within the framework + of the "multipart/report" content type defined in [2]. + + This memo defines only the format of the notifications. An extension + to the Simple Message Transfer Protocol (SMTP) [3] to fully support + such notifications is the subject of a separate memo [4]. + +1.1 Purposes + + The DSNs defined in this memo are expected to serve several purposes: + +(a) Inform human beings of the status of message delivery processing, as + well as the reasons for any delivery problems or outright failures, + in a manner which is largely independent of human language; + +(b) Allow mail user agents to keep track of the delivery status of + messages sent, by associating returned DSNs with earlier message + transmissions; + +(c) Allow mailing list exploders to automatically maintain their + subscriber lists when delivery attempts repeatedly fail; + +(d) Convey delivery and non-delivery notifications resulting from + attempts to deliver messages to "foreign" mail systems via a + gateway; + +(e) Allow "foreign" notifications to be tunneled through a MIME-capable + message system and back into the original messaging system that + issued the original notification, or even to a third messaging + system; + +(f) Allow language-independent, yet reasonably precise, indications of + the reason for the failure of a message to be delivered (once status + codes of sufficient precision are defined); and + +(g) Provide sufficient information to remote MTA maintainers (via + "trouble tickets") so that they can understand the nature of + reported errors. This feature is used in the case that failure to + deliver a message is due to the malfunction of a remote MTA and the + + + +Moore & Vaudreuil Standards Track [Page 2] + +RFC 1894 Delivery Status Notifications January 1996 + + + sender wants to report the problem to the remote MTA administrator. + +1.2 Requirements + + These purposes place the following constraints on the notification + protocol: + +(a) It must be readable by humans as well as being machine-parsable. + +(b) It must provide enough information to allow message senders (or the + user agents) to unambiguously associate a DSN with the message that + was sent and the original recipient address for which the DSN is + issued (if such information is available), even if the message was + forwarded to another recipient address. + +(c) It must be able to preserve the reason for the success or failure of + a delivery attempt in a remote messaging system, using the + "language" (mailbox addresses and status codes) of that remote + system. + +(d) It must also be able to describe the reason for the success or + failure of a delivery attempt, independent of any particular human + language or of the "language" of any particular mail system. + +(e) It must preserve enough information to allow the maintainer of a + remote MTA to understand (and if possible, reproduce) the conditions + that caused a delivery failure at that MTA. + +(f) For any notifications issued by foreign mail systems, which are + translated by a mail gateway to the DSN format, the DSN must + preserve the "type" of the foreign addresses and error codes, so + that these may be correctly interpreted by gateways. + + A DSN contains a set of per-message fields which identify the message + and the transaction during which the message was submitted, along + with other fields that apply to all delivery attempts described by + the DSN. The DSN also includes a set of per-recipient fields to + convey the result of the attempt to deliver the message to each of + one or more recipients. + +1.3 Terminology + + A message may be transmitted through several message transfer agents + (MTAs) on its way to a recipient. For a variety of reasons, + recipient addresses may be rewritten during this process, so each MTA + may potentially see a different recipient address. Depending on the + purpose for which a DSN is used, different formats of a particular + recipient address will be needed. + + + +Moore & Vaudreuil Standards Track [Page 3] + +RFC 1894 Delivery Status Notifications January 1996 + + + Several DSN fields are defined in terms of the view from a particular + MTA in the transmission. The MTAs are assigned the following names: + + (a) Original MTA + + The Original MTA is the one to which the message is submitted for + delivery by the sender of the message. + + (b) Reporting MTA + + For any DSN, the Reporting MTA is the one which is reporting the + results of delivery attempts described in the DSN. + + If the delivery attempts described occurred in a "foreign" (non- + Internet) mail system, and the DSN was produced by translating the + foreign notice into DSN format, the Reporting MTA will still identify + the "foreign" MTA where the delivery attempts occurred. + + (c) Received-From MTA + + The Received-From MTA is the MTA from which the Reporting MTA + received the message, and accepted responsibility for delivery of the + message. + + (d) Remote MTA + + If an MTA determines that it must relay a message to one or more + recipients, but the message cannot be transferred to its "next hop" + MTA, or if the "next hop" MTA refuses to accept responsibility for + delivery of the message to one or more of its intended recipients, + the relaying MTA may need to issue a DSN on behalf of the recipients + for whom the message cannot be delivered. In this case the relaying + MTA is the Reporting MTA, and the "next hop" MTA is known as the + Remote MTA. + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 4] + +RFC 1894 Delivery Status Notifications January 1996 + + +Figure 1 illustrates the relationship between the various MTAs. + + ++-----+ +--------+ +---------+ +---------+ +------+ +| | | | |Received-| | | | | +| | => |Original| => ... => | From | => |Reporting| ===> |Remote| +| user| | MTA | | MTA | | MTA | <No! | MTA | +|agent| +--------+ +---------+ +----v----+ +------+ +| | | +| | <-------------------------------------------+ ++-----+ (DSN returned to sender by Reporting MTA) + + + Figure 1. Original, Received-From, Reporting and Remote MTAs + + + Each of these MTAs may provide information which is useful in a DSN: + ++ Ideally, the DSN will contain the address of each recipient as + originally specified to the Original MTA by the sender of the message. + This version of the address is needed (rather than a forwarding + address or some modified version of the original address) so that the + sender may compare the recipient address in the DSN with the address + in the sender's records (e.g. an address book for an individual, the + list of subscribers for a mailing list) and take appropriate action. + + Similarly, the DSN might contain an "envelope identifier" that was + known to both the sender's user agent and the Original MTA at the time + of message submission, and which, if included in the DSN, can be used + by the sender to keep track of which messages were or were not + delivered. + ++ If a message was (a) forwarded to a different address than that + specified by the sender, (b) gatewayed to a different mail system than + that used by the sender, or (c) subjected to address rewriting during + transmission, the "final" form of the recipient address (i.e. the one + seen by the Reporting MTA) will be different than the original + (sender-specified) recipient address. Just as the sender's user agent + (or the sender) prefers the original recipient address, so the "final" + address is needed when reporting a problem to the postmaster of the + site where message delivery failed, because only the final recipient + address will allow her to reproduce the conditions that caused the + failure. + ++ A "failed" DSN should contain the most accurate explanation for the + delivery failure that is available. For ease of interpretation, this + information should be a format which is independent of the mail + transport system that issued the DSN. However, if a foreign error + + + +Moore & Vaudreuil Standards Track [Page 5] + +RFC 1894 Delivery Status Notifications January 1996 + + + code is translated into some transport-independent format, some + information may be lost. It is therefore desirable to provide both a + transport-independent status code and a mechanism for reporting + transport-specific codes. Depending on the circumstances that + produced delivery failure, the transport-specific code might be + obtained from either the Reporting MTA or the Remote MTA. + + Since different values for "recipient address" and "delivery status + code" are needed according to the circumstance in which a DSN will be + used, and since the MTA that issues the DSN cannot anticipate those + circumstances, the DSN format described here may contain both the + original and final forms of a recipient address, and both a + transport-independent and a transport-specific indication of delivery + status. + + Extension fields may also be added by the Reporting MTA as needed to + provide additional information for use in a trouble ticket or to + preserve information for tunneling of foreign delivery reports + through Internet DSNs. + + The Original, Reporting, and Remote MTAs may exist in very different + environments and use dissimilar transport protocols, MTA names, + address formats, and delivery status codes. DSNs therefore do not + assume any particular format for mailbox addresses, MTA names, or + transport-specific status codes. Instead, the various DSN fields + that carry such quantities consist of a "type" subfield followed by a + subfield whose contents are ordinary text characters, and the format + of which is indicated by the "type" subfield. This allows a DSN to + convey these quantities regardless of format. + +2. Format of a Delivery Status Notification + + A DSN is a MIME message with a top-level content-type of + multipart/report (defined in [2]). When a multipart/report content + is used to transmit a DSN: + +(a) The report-type parameter of the multipart/report content is + "delivery-status". + +(b) The first component of the multipart/report contains a human- + readable explanation of the DSN, as described in [2]. + +(c) The second component of the multipart/report is of content-type + message/delivery-status, described in section 2.1 of this document. + +(d) If the original message or a portion of the message is to be + returned to the sender, it appears as the third component of the + multipart/report. + + + +Moore & Vaudreuil Standards Track [Page 6] + +RFC 1894 Delivery Status Notifications January 1996 + + + NOTE: For delivery status notifications gatewayed from foreign + systems, the headers of the original message may not be available. + In this case the third component of the DSN may be omitted, or it + may contain "simulated" RFC 822 headers which contain equivalent + information. In particular, it is very desirable to preserve the + subject, date, and message-id (or equivalent) fields from the + original message. + + The DSN MUST be addressed (in both the message header and the + transport envelope) to the return address from the transport envelope + which accompanied the original message for which the DSN was + generated. (For a message that arrived via SMTP, the envelope return + address appears in the MAIL FROM command.) + + The From field of the message header of the DSN SHOULD contain the + address of a human who is responsible for maintaining the mail system + at the Reporting MTA site (e.g. Postmaster), so that a reply to the + DSN will reach that person. Exception: if a DSN is translated from a + foreign delivery report, and the gateway performing the translation + cannot determine the appropriate address, the From field of the DSN + MAY be the address of a human who is responsible for maintaining the + gateway. + + The envelope sender address of the DSN SHOULD be chosen to ensure + that no delivery status reports will be issued in response to the DSN + itself, and MUST be chosen so that DSNs will not generate mail loops. + Whenever an SMTP transaction is used to send a DSN, the MAIL FROM + command MUST use a NULL return address, i.e. "MAIL FROM:<>". + + A particular DSN describes the delivery status for exactly one + message. However, an MTA MAY report on the delivery status for + several recipients of the same message in a single DSN. Due to the + nature of the mail transport system (where responsibility for + delivery of a message to its recipients may be split among several + MTAs, and delivery to any particular recipient may be delayed), + multiple DSNs may be still be issued in response to a single message + submission. + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 7] + +RFC 1894 Delivery Status Notifications January 1996 + + +2.1 The message/delivery-status content-type + + The message/delivery-status content-type is defined as follows: + + MIME type name: message + MIME subtype name: delivery-status + Optional parameters: none + Encoding considerations: "7bit" encoding is sufficient and + MUST be used to maintain readability + when viewed by non-MIME mail + readers. + Security considerations: discussed in section 4 of this memo. + + The message/delivery-status report type for use in the + multipart/report is "delivery-status". + + The body of a message/delivery-status consists of one or more + "fields" formatted according to the ABNF of RFC 822 header "fields" + (see [6]). The per-message fields appear first, followed by a blank + line. Following the per-message fields are one or more groups of + per-recipient fields. Each group of per-recipient fields is preceded + by a blank line. Using the ABNF of RFC 822, the syntax of the + message/delivery-status content is as follows: + + delivery-status-content = + per-message-fields 1*( CRLF per-recipient-fields ) + + The per-message fields are described in section 2.2. The per- + recipient fields are described in section 2.3. + + +2.1.1 General conventions for DSN fields + + Since these fields are defined according to the rules of RFC 822, the + same conventions for continuation lines and comments apply. + Notification fields may be continued onto multiple lines by beginning + each additional line with a SPACE or HTAB. Text which appears in + parentheses is considered a comment and not part of the contents of + that notification field. Field names are case-insensitive, so the + names of notification fields may be spelled in any combination of + upper and lower case letters. Comments in DSN fields may use the + "encoded-word" construct defined in [7]. + + A number of DSN fields are defined to have a portion of a field body + of "xtext". "xtext" is used to allow encoding sequences of octets + which contain values outside the range [1-127 decimal] of traditional + ASCII characters, and also to allow comments to be inserted in the + data. Any octet may be encoded as "+" followed by two upper case + + + +Moore & Vaudreuil Standards Track [Page 8] + +RFC 1894 Delivery Status Notifications January 1996 + + + hexadecimal digits. (The "+" character MUST be encoded as "+2B".) + With certain exceptions, octets that correspond to ASCII characters + may be represented as themselves. SPACE and HTAB characters are + ignored. Comments may be included by enclosing them in parenthesis. + Except within comments, encoded-words such as defined in [7] may NOT + be used in xtext. + + "xtext" is formally defined as follows: + + xtext = *( xchar / hexchar / linear-white-space / comment ) + + xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, + except for "+", "\" and "(". + + "hexchar"s are intended to encode octets that cannot be represented + as plain text, either because they are reserved, or because they are + non-printable. However, any octet value may be represented by a + "hexchar". + + hexchar = ASCII "+" immediately followed by two upper case + hexadecimal digits + + When encoding an octet sequence as xtext: + + + Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\", + and "(", MAY be encoded as itself. (Some CHARs in this range may + also be encoded as "hexchar"s, at the implementor's discretion.) + + + ASCII CHARs that fall outside the range above must be encoded as + "hexchar". + + + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line + lengths from becoming excessive. + + + Comments MAY be added to clarify the meaning for human readers. + +2.1.2 "*-type" subfields + + Several DSN fields consist of a "-type" subfield, followed by a + semicolon, followed by "*text". For these fields, the keyword used + in the address-type, diagnostic-type, or MTA-name-type subfield + indicates the expected format of the address, status-code, or MTA- + name which follows. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 9] + +RFC 1894 Delivery Status Notifications January 1996 + + + The "-type" subfields are defined as follows: + +(a) An "address-type" specifies the format of a mailbox address. For + example, Internet mail addresses use the "rfc822" address-type. + + address-type = atom + +(b) A "diagnostic-type" specifies the format of a status code. For + example, when a DSN field contains a reply code reported via the + Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is + used. + + diagnostic-type = atom + +(c) An "MTA-name-type" specifies the format of an MTA name. For + example, for an SMTP server on an Internet host, the MTA name is the + domain name of that host, and the "dns" MTA-name-type is used. + + mta-name-type = atom + + Values for address-type, diagnostic-type, and MTA-name-type are + case-insensitive. Thus address-type values of "RFC822" and "rfc822" + are equivalent. + + The Internet Assigned Numbers Authority (IANA) will maintain a + registry of address-types, diagnostic-types, and MTA-name-types, + along with descriptions of the meanings and acceptable values of + each, or a reference to a one or more specifications that provide + such descriptions. (The "rfc822" address-type, "smtp" diagnostic- + type, and "dns" MTA-name-type are defined in [4].) Registration + forms for address-type, diagnostic-type, and MTA-name-type appear in + section 8 of this document. + + IANA will not accept registrations for any address-type, diagnostic- + type, or MTA-name-type name that begins with "X-". These type names + are reserved for experimental use. + +2.1.3 Lexical tokens imported from RFC 822 + + The following lexical tokens, defined in [6], are used in the ABNF + grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear- + white-space, SPACE, text. The date-time lexical token is defined in + [8]. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 10] + +RFC 1894 Delivery Status Notifications January 1996 + + +2.2 Per-Message DSN Fields + + Some fields of a DSN apply to all of the delivery attempts described + by that DSN. These fields may appear at most once in any DSN. These + fields are used to correlate the DSN with the original message + transaction and to provide additional information which may be useful + to gateways. + + per-message-fields = + [ original-envelope-id-field CRLF ] + reporting-mta-field CRLF + [ dsn-gateway-field CRLF ] + [ received-from-mta-field CRLF ] + [ arrival-date-field CRLF ] + *( extension-field CRLF ) + +2.2.1 The Original-Envelope-Id field + + The optional Original-Envelope-Id field contains an "envelope + identifier" which uniquely identifies the transaction during which + the message was submitted, and was either (a) specified by the sender + and supplied to the sender's MTA, or (b) generated by the sender's + MTA and made available to the sender when the message was submitted. + Its purpose is to allow the sender (or her user agent) to associate + the returned DSN with the specific transaction in which the message + was sent. + + If such an envelope identifier was present in the envelope which + accompanied the message when it arrived at the Reporting MTA, it + SHOULD be supplied in the Original-Envelope-Id field of any DSNs + issued as a result of an attempt to deliver the message. Except when + a DSN is issued by the sender's MTA, an MTA MUST NOT supply this + field unless there is an envelope-identifier field in the envelope + which accompanied this message on its arrival at the Reporting MTA. + + The Original-Envelope-Id field is defined as follows: + + original-envelope-id-field = + "Original-Envelope-Id" ":" envelope-id + + envelope-id = *text + + There may be at most one Original-Envelope-Id field per DSN. + + The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the + original case and spelling of the envelope-id. + + + + + +Moore & Vaudreuil Standards Track [Page 11] + +RFC 1894 Delivery Status Notifications January 1996 + + + NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from + the message header. The Message-Id identifies the content of the + message, while the Original-Envelope-Id identifies the transaction in + which the message is sent. + +2.2.2 The Reporting-MTA DSN field + + reporting-mta-field = + "Reporting-MTA" ":" mta-name-type ";" mta-name + + mta-name = *text + + The Reporting-MTA field is defined as follows: + + A DSN describes the results of attempts to deliver, relay, or gateway + a message to one or more recipients. In all cases, the Reporting-MTA + is the MTA which attempted to perform the delivery, relay, or gateway + operation described in the DSN. This field is required. + + Note that if an SMTP client attempts to relay a message to an SMTP + server and receives an error reply to a RCPT command, the client is + responsible for generating the DSN, and the client's domain name will + appear in the Reporting-MTA field. (The server's domain name will + appear in the Remote-MTA field.) + + Note that the Reporting-MTA is not necessarily the MTA which actually + issued the DSN. For example, if an attempt to deliver a message + outside of the Internet resulted in a nondelivery notification which + was gatewayed back into Internet mail, the Reporting-MTA field of the + resulting DSN would be that of the MTA that originally reported the + delivery failure, not that of the gateway which converted the foreign + notification into a DSN. See Figure 2. + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 12] + +RFC 1894 Delivery Status Notifications January 1996 + + +sender's environment recipient's environment +............................ .......................................... + : : + (1) : : (2) + +-----+ +--------+ +--------+ +---------+ +---------+ +------+ + | | | | | | |Received-| | | | | + | |=>|Original|=>| |->| From |->|Reporting|-->|Remote| + | user| | MTA | | | | MTA | | MTA |<No| MTA | + |agent| +--------+ |Gateway | +---------+ +----v----+ +------+ + | | | | | + | | <============| |<-------------------+ + +-----+ | |(4) (3) + +--------+ + : : +...........................: :......................................... + + Figure 2. DSNs in the presence of gateways + + (1) message is gatewayed into recipient's environment + (2) attempt to relay message fails + (3) reporting-mta (in recipient's environment) returns nondelivery + notification + (4) gateway translates foreign notification into a DSN + + + + The mta-name portion of the Reporting-MTA field is formatted + according to the conventions indicated by the mta-name-type subfield. + If an MTA functions as a gateway between dissimilar mail environments + and thus is known by multiple names depending on the environment, the + mta-name subfield SHOULD contain the name used by the environment + from which the message was accepted by the Reporting-MTA. + + Because the exact spelling of an MTA name may be significant in a + particular environment, MTA names are CASE-SENSITIVE. + +2.2.3 The DSN-Gateway field + + The DSN-Gateway field indicates the name of the gateway or MTA which + translated a foreign (non-Internet) delivery status notification into + this DSN. This field MUST appear in any DSN which was translated by + a gateway from a foreign system into DSN format, and MUST NOT appear + otherwise. + + dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name + + + + + + +Moore & Vaudreuil Standards Track [Page 13] + +RFC 1894 Delivery Status Notifications January 1996 + + + For gateways into Internet mail, the MTA-name-type will normally be + "smtp", and the mta-name will be the Internet domain name of the + gateway. + +2.2.4 The Received-From-MTA DSN field + + The optional Received-From-MTA field indicates the name of the MTA + from which the message was received. + + received-from-mta-field = + "Received-From-MTA" ":" mta-name-type ";" mta-name + + If the message was received from an Internet host via SMTP, the + contents of the mta-name subfield SHOULD be the Internet domain name + supplied in the HELO or EHLO command, and the network address used by + the SMTP client SHOULD be included as a comment enclosed in + parentheses. (In this case, the MTA-name-type will be "smtp".) + + The mta-name portion of the Received-From-MTA field is formatted + according to the conventions indicated by the MTA-name-type subfield. + + Since case is significant in some mail systems, the exact spelling, + including case, of the MTA name SHOULD be preserved. + +2.2.5 The Arrival-Date DSN field + + The optional Arrival-Date field indicates the date and time at which + the message arrived at the Reporting MTA. If the Last-Attempt-Date + field is also provided in a per-recipient field, this can be used to + determine the interval between when the message arrived at the + Reporting MTA and when the report was issued for that recipient. + + arrival-date-field = "Arrival-Date" ":" date-time + + The date and time are expressed in RFC 822 'date-time' format, as + modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used. + +2.3 Per-Recipient DSN fields + + A DSN contains information about attempts to deliver a message to one + or more recipients. The delivery information for any particular + recipient is contained in a group of contiguous per-recipient fields. + Each group of per-recipient fields is preceded by a blank line. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 14] + +RFC 1894 Delivery Status Notifications January 1996 + + + The syntax for the group of per-recipient fields is as follows: + + + per-recipient-fields = + [ original-recipient-field CRLF ] + final-recipient-field CRLF + action-field CRLF + status-field CRLF + [ remote-mta-field CRLF ] + [ diagnostic-code-field CRLF ] + [ last-attempt-date-field CRLF ] + [ will-retry-until-field CRLF ] + *( extension-field CRLF ) + +2.3.1 Original-Recipient field + + The Original-Recipient field indicates the original recipient address + as specified by the sender of the message for which the DSN is being + issued. + + original-recipient-field = + "Original-Recipient" ":" address-type ";" generic-address + + generic-address = *text + + The address-type field indicates the type of the original recipient + address. If the message originated within the Internet, the + address-type field field will normally be "rfc822", and the address + will be according to the syntax specified in [6]. The value + "unknown" should be used if the Reporting MTA cannot determine the + type of the original recipient address from the message envelope. + + This field is optional. It should be included only if the sender- + specified recipient address was present in the message envelope, such + as by the SMTP extensions defined in [4]. This address is the same + as that provided by the sender and can be used to automatically + correlate DSN reports and message transactions. + +2.3.2 Final-Recipient field + + The Final-Recipient field indicates the recipient for which this set + of per-recipient fields applies. This field MUST be present in each + set of per-recipient data. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 15] + +RFC 1894 Delivery Status Notifications January 1996 + + + The syntax of the field is as follows: + + final-recipient-field = + "Final-Recipient" ":" address-type ";" generic-address + + The generic-address subfield of the Final-Recipient field MUST + contain the mailbox address of the recipient (from the transport + envelope) as it was when the message was accepted for delivery by the + Reporting MTA. + + The Final-Recipient address may differ from the address originally + provided by the sender, because it may have been transformed during + forwarding and gatewaying into an totally unrecognizable mess. + However, in the absence of the optional Original-Recipient field, the + Final-Recipient field and any returned content may be the only + information available with which to correlate the DSN with a + particular message submission. + + The address-type subfield indicates the type of address expected by + the reporting MTA in that context. Recipient addresses obtained via + SMTP will normally be of address-type "rfc822". + + NOTE: The Reporting MTA is not expected to ensure that the address + actually conforms to the syntax conventions of the address-type. + Instead, it MUST report exactly the address received in the envelope, + unless that address contains characters such as CR or LF which may + not appear in a DSN field. + + Since mailbox addresses (including those used in the Internet) may be + case sensitive, the case of alphabetic characters in the address MUST + be preserved. + +2.3.3 Action field + + The Action field indicates the action performed by the Reporting-MTA + as a result of its attempt to deliver the message to this recipient + address. This field MUST be present for each recipient named in the + DSN. + + The syntax for the action-field is: + + action-field = "Action" ":" action-value + + action-value = + "failed" / "delayed" / "delivered" / "relayed" / "expanded" + + + + + + +Moore & Vaudreuil Standards Track [Page 16] + +RFC 1894 Delivery Status Notifications January 1996 + + + The action-value may be spelled in any combination of upper and lower + case characters. + +"failed" indicates that the message could not be delivered to the + recipient. The Reporting MTA has abandoned any attempts to + deliver the message to this recipient. No further + notifications should be expected. + +"delayed" indicates that the Reporting MTA has so far been unable to + deliver or relay the message, but it will continue to + attempt to do so. Additional notification messages may be + issued as the message is further delayed or successfully + delivered, or if delivery attempts are later abandoned. + +"delivered" indicates that the message was successfully delivered to + the recipient address specified by the sender, which + includes "delivery" to a mailing list exploder. It does + not indicate that the message has been read. This is a + terminal state and no further DSN for this recipient should + be expected. + +"relayed" indicates that the message has been relayed or gatewayed + into an environment that does not accept responsibility for + generating DSNs upon successful delivery. This action- + value SHOULD NOT be used unless the sender has requested + notification of successful delivery for this recipient. + +"expanded" indicates that the message has been successfully delivered + to the recipient address as specified by the sender, and + forwarded by the Reporting-MTA beyond that destination to + multiple additional recipient addresses. An action-value + of "expanded" differs from "delivered" in that "expanded" + is not a terminal state. Further "failed" and/or "delayed" + notifications may be provided. + + Using the terms "mailing list" and "alias" as defined in + [4], section 7.2.7: An action-value of "expanded" is only + to be used when the message is delivered to a multiple- + recipient "alias". An action-value of "expanded" SHOULD + NOT be used with a DSN issued on delivery of a message to a + "mailing list". + + NOTE ON ACTION VS. STATUS CODES: Although the 'action' field might + seem to be redundant with the 'status' field, this is not the case. + In particular, a "temporary failure" ("4") status code could be used + with an action-value of either "delayed" or "failed". For example, + assume that an SMTP client repeatedly tries to relay a message to the + mail exchanger for a recipient, but fails because a query to a domain + + + +Moore & Vaudreuil Standards Track [Page 17] + +RFC 1894 Delivery Status Notifications January 1996 + + + name server timed out. After a few hours, it might issue a "delayed" + DSN to inform the sender that the message had not yet been delivered. + After a few days, the MTA might abandon its attempt to deliver the + message and return a "failed" DSN. The status code (which would + begin with a "4" to indicate "temporary failure") would be the same + for both DSNs. + + Another example for which the action and status codes may appear + contradictory: If an MTA or mail gateway cannot deliver a message + because doing so would entail conversions resulting in an + unacceptable loss of information, it would issue a DSN with the + 'action' field of "failure" and a status code of 'XXX'. If the + message had instead been relayed, but with some loss of information, + it might generate a DSN with the same XXX status-code, but with an + action field of "relayed". + +2.3.4 Status field + + The per-recipient Status field contains a transport-independent + status code which indicates the delivery status of the message to + that recipient. This field MUST be present for each delivery attempt + which is described by a DSN. + + The syntax of the status field is: + + status-field = "Status" ":" status-code + + status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT + + ; White-space characters and comments are NOT allowed within a + ; status-code, though a comment enclosed in parentheses MAY follow + ; the last numeric subfield of the status-code. Each numeric + ; subfield within the status-code MUST be expressed without + ; leading zero digits. + + Status codes thus consist of three numerical fields separated by ".". + The first sub-field indicates whether the delivery attempt was + successful (2 = success, 4 = persistent temporary failure, 5 = + permanent failure). The second sub-field indicates the probable + source of any delivery anomalies, and the third sub-field denotes a + precise error condition, if known. + + The initial set of status-codes is defined in [5]. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 18] + +RFC 1894 Delivery Status Notifications January 1996 + + +2.3.5 Remote-MTA field + + The value associated with the Remote-MTA DSN field is a printable + ASCII representation of the name of the "remote" MTA that reported + delivery status to the "reporting" MTA. + + remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name + + NOTE: The Remote-MTA field preserves the "while talking to" + information that was provided in some pre-existing nondelivery + reports. + + This field is optional. It MUST NOT be included if no remote MTA was + involved in the attempted delivery of the message to that recipient. + +2.3.6 Diagnostic-Code field + + For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field + contains the actual diagnostic code issued by the mail transport. + Since such codes vary from one mail transport to another, the + diagnostic-type subfield is needed to specify which type of + diagnostic code is represented. + + diagnostic-code-field = + "Diagnostic-Code" ":" diagnostic-type ";" *text + + NOTE: The information in the Diagnostic-Code field may be somewhat + redundant with that from the Status field. The Status field is + needed so that any DSN, regardless of origin, may be understood by + any user agent or gateway that parses DSNs. Since the Status code + will sometimes be less precise than the actual transport diagnostic + code, the Diagnostic-Code field is provided to retain the latter + information. Such information may be useful in a trouble ticket sent + to the administrator of the Reporting MTA, or when tunneling foreign + nondelivery reports through DSNs. + + If the Diagnostic Code was obtained from a Remote MTA during an + attempt to relay the message to that MTA, the Remote-MTA field should + be present. When interpreting a DSN, the presence of a Remote-MTA + field indicates that the Diagnostic Code was issued by the Remote + MTA. The absence of a Remote-MTA indicates that the Diagnostic Code + was issued by the Reporting MTA. + + In addition to the Diagnostic-Code itself, additional textual + description of the diagnostic, MAY appear in a comment enclosed in + parentheses. + + + + + +Moore & Vaudreuil Standards Track [Page 19] + +RFC 1894 Delivery Status Notifications January 1996 + + + This field is optional, because some mail systems supply no + additional information beyond that which is returned in the 'action' + and 'status' fields. However, this field SHOULD be included if + transport-specific diagnostic information is available. + +2.3.7 Last-Attempt-Date field + + The Last-Attempt-Date field gives the date and time of the last + attempt to relay, gateway, or deliver the message (whether successful + or unsuccessful) by the Reporting MTA. This is not necessarily the + same as the value of the Date field from the header of the message + used to transmit this delivery status notification: In cases where + the DSN was generated by a gateway, the Date field in the message + header contains the time the DSN was sent by the gateway and the DSN + Last-Attempt-Date field contains the time the last delivery attempt + occurred. + + last-attempt-date-field = "Last-Attempt-Date" ":" date-time + + This field is optional. It MUST NOT be included if the actual date + and time of the last delivery attempt are not available (which might + be the case if the DSN were being issued by a gateway). + + The date and time are expressed in RFC 822 'date-time' format, as + modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used. + + 3.2.1.5 final-log-id field + + The "final-log-id" field gives the final-log-id of the message that + was used by the final-mta. This can be useful as an index to the + final-mta's log entry for that delivery attempt. + + final-log-id-field = "Final-Log-ID" ":" *text + + This field is optional. + +2.3.8 Will-Retry-Until field + + For DSNs of type "delayed", the Will-Retry-Until field gives the date + after which the Reporting MTA expects to abandon all attempts to + deliver the message to that recipient. The Will-Retry-Until field is + optional for "delay" DSNs, and MUST NOT appear in other DSNs. + + will-retry-until-field = "Will-Retry-Until" ":" date-time + + The date and time are expressed in RFC 822 'date-time' format, as + modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used. + + + + +Moore & Vaudreuil Standards Track [Page 20] + +RFC 1894 Delivery Status Notifications January 1996 + + +2.4 Extension fields + + Additional per-message or per-recipient DSN fields may be defined in + the future by later revisions or extensions to this specification. + Extension-field names beginning with "X-" will never be defined as + standard fields; such names are reserved for experimental use. DSN + field names NOT beginning with "X-" MUST be registered with the + Internet Assigned Numbers Authority (IANA) and published in an RFC. + + Extension DSN fields may be defined for the following reasons: + + (a) To allow additional information from foreign delivery status + reports to be tunneled through Internet DSNs. The names of such + DSN fields should begin with an indication of the foreign + environment name (e.g. X400-Physical-Forwarding-Address). + + (b) To allow the transmission of diagnostic information which is + specific to a particular mail transport protocol. The names of + such DSN fields should begin with an indication of the mail + transport being used (e.g. SMTP-Remote-Recipient-Address). Such + fields should be used for diagnostic purposes only and not by + user agents or mail gateways. + + (c) To allow transmission of diagnostic information which is specific + to a particular message transfer agent (MTA). The names of such + DSN fields should begin with an indication of the MTA + implementation which produced the DSN. (e.g. Foomail-Queue-ID). + + MTA implementors are encouraged to provide adequate information, via + extension fields if necessary, to allow an MTA maintainer to + understand the nature of correctable delivery failures and how to fix + them. For example, if message delivery attempts are logged, the DSN + might include information which allows the MTA maintainer to easily + find the log entry for a failed delivery attempt. + + If an MTA developer does not wish to register the meanings of such + extension fields, "X-" fields may be used for this purpose. To avoid + name collisions, the name of the MTA implementation should follow the + "X-", (e.g. "X-Foomail-Log-ID"). + +3. Conformance and Usage Requirements + + An MTA or gateway conforms to this specification if it generates DSNs + according to the protocol defined in this memo. For MTAs and + gateways that do not support requests for positive delivery + notification (such as in [4]), it is sufficient that delivery failure + reports use this protocol. + + + + +Moore & Vaudreuil Standards Track [Page 21] + +RFC 1894 Delivery Status Notifications January 1996 + + + A minimal implementation of this specification need generate only the + Reporting-MTA per-message field, and the Final-Recipient, Action, and + Status fields for each attempt to deliver a message to a recipient + described by the DSN. Generation of the other fields, when + appropriate, is strongly recommended. + + MTAs and gateways MUST NOT generate the Original-Recipient field of a + DSN unless the mail transfer protocol provides the address originally + specified by the sender at the time of submission. (Ordinary SMTP + does not make that guarantee, but the SMTP extension defined in [4] + permits such information to be carried in the envelope if it is + available.) + + Each sender-specified recipient address SHOULD result in at most one + "delivered" or "failed" DSN for that recipient. If a positive DSN is + requested (e.g. one using NOTIFY=SUCCESS in SMTP) for a recipient + that is forwarded to multiple recipients of an "alias" (as defined in + [4], section 7.2.7), the forwarding MTA SHOULD normally issue a + "expanded" DSN for the originally-specified recipient and not + propagate the request for a DSN to the forwarding addresses. + Alternatively, the forwarding MTA MAY relay the request for a DSN to + exactly one of the forwarding addresses and not propagate the request + to the others. + + By contrast, successful submission of a message to a mailing list + exploder is considered final delivery of the message. Upon delivery + of a message to a recipient address corresponding to a mailing list + exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly + as if the recipient address were that of an ordinary mailbox. + + NOTE: This is actually intended to make DSNs usable by mailing lists + themselves. Any message sent to a mailing list subscriber should + have its envelope return address pointing to the list maintainer [see + RFC 1123, section 5.3.7(E)]. Since DSNs are sent to the envelope + return address, all DSNs resulting from delivery to the recipients of + a mailing list will be sent to the list maintainer. The list + maintainer may elect to mechanically process DSNs upon receipt, and + thus automatically delete invalid addresses from the list. (See + section 7 of this memo.) + + This specification places no restrictions on the processing of DSNs + received by user agents or distribution lists. + +4. Security Considerations + + The following security considerations apply when using DSNs: + + + + + +Moore & Vaudreuil Standards Track [Page 22] + +RFC 1894 Delivery Status Notifications January 1996 + + +4.1 Forgery + + DSNs may be forged as easily as ordinary Internet electronic mail. + User agents and automatic mail handling facilities (such as mail + distribution list exploders) that wish to make automatic use of DSNs + should take appropriate precautions to minimize the potential damage + from denial-of-service attacks. + + Security threats related to forged DSNs include the sending of: + +(a) A falsified delivery notification when the message is not delivered + to the indicated recipient, +(b) A falsified non-delivery notification when the message was in fact + delivered to the indicated recipient, +(c) A falsified Final-Recipient address, +(d) A falsified Remote-MTA identification, +(e) A falsified relay notification when the message is "dead ended". +(f) Unsolicited DSNs + +4.2 Confidentiality + + Another dimension of security is confidentiality. There may be cases + in which a message recipient is autoforwarding messages but does not + wish to divulge the address to which the messages are autoforwarded. + The desire for such confidentiality will probably be heightened as + "wireless mailboxes", such as pagers, become more widely used as + autoforward addresses. + + MTA authors are encouraged to provide a mechanism which enables the + end user to preserve the confidentiality of a forwarding address. + Depending on the degree of confidentiality required, and the nature + of the environment to which a message were being forwarded, this + might be accomplished by one or more of: + +(a) issuing a "relayed" DSN (if a positive DSN was requested) when a + message is forwarded to a confidential forwarding address, and + disabling requests for positive DSNs for the forwarded message, + +(b) declaring the message to be delivered, issuing a "delivered" DSN, + re-sending the message to the confidential forwarding address, and + arranging for no DSNs to be issued for the re-sent message, + +(c) omitting "Remote-*" or extension fields of a DSN whenever they would + otherwise contain confidential information (such as a confidential + forwarding address), + +(d) for messages forwarded to a confidential address, setting the + envelope return address (e.g. SMTP MAIL FROM address) to the NULL + + + +Moore & Vaudreuil Standards Track [Page 23] + +RFC 1894 Delivery Status Notifications January 1996 + + + reverse-path ("<>") (so that no DSNs would be sent from a downstream + MTA to the original sender), + +(e) for messages forwarded to a confidential address, disabling delivery + notifications for the forwarded message (e.g. if the "next-hop" MTA + uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER + parameter to the RCPT command), or + +(f) when forwarding mail to a confidential address, having the + forwarding MTA rewrite the envelope return address for the forwarded + message and attempt delivery of that message as if the forwarding + MTA were the originator. On its receipt of final delivery status, + the forwarding MTA would issue a DSN to the original sender. + + In general, any optional DSN field may be omitted if the Reporting + MTA site determines that inclusion of the field would impose too + great a compromise of site confidentiality. The need for such + confidentiality must be balanced against the utility of the omitted + information in trouble reports and DSNs gatewayed to foreign + environments. + + Implementors are cautioned that many existing MTAs will send + nondelivery notifications to a return address in the message header + (rather than to the one in the envelope), in violation of SMTP and + other protocols. If a message is forwarded through such an MTA, no + reasonable action on the part of the forwarding MTA will prevent the + downstream MTA from compromising the forwarding address. Likewise, + if the recipient's MTA automatically responds to messages based on a + request in the message header (such as the nonstandard, but widely + used, Return-Receipt-To extension header), it will also compromise + the forwarding address. + +4.3 Non-Repudiation + + Within the framework of today's internet mail, the DSNs defined in + this memo provide valuable information to the mail user; however, + even a "failed" DSN can not be relied upon as a guarantee that a + message was not received by the recipient. Even if DSNs are not + actively forged, conditions exist under which a message can be + delivered despite the fact that a failure DSN was issued. + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 24] + +RFC 1894 Delivery Status Notifications January 1996 + + + For example, a race condition in the SMTP protocol allows for the + duplication of messages if the connection is dropped following a + completed DATA command, but before a response is seen by the SMTP + client. This will cause the SMTP client to retransmit the message, + even though the SMTP server has already accepted it.[9] If one of + those delivery attempts succeeds and the other one fails, a "failed" + DSN could be issued even though the message actually reached the + recipient. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 25] + +RFC 1894 Delivery Status Notifications January 1996 + + +5. Appendix - collected grammar + + NOTE: The following lexical tokens are defined in RFC 822: atom, + CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. + The date-time lexical token is defined in [8]. + +action-field = "Action" ":" action-value + +action-value = + "failed" / "delayed" / "delivered" / "relayed" / "expanded" + +address-type = atom + +arrival-date-field = "Arrival-Date" ":" date-time + +delivery-status-content = + per-message-fields 1*( CRLF per-recipient-fields ) + +diagnostic-code-field = + "Diagnostic-Code" ":" diagnostic-type ";" *text + +diagnostic-type = atom + +dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name + +envelope-id = *text + +extension-field = extension-field-name ":" *text + +extension-field-name = atom + +final-recipient-field = + "Final-Recipient" ":" address-type ";" generic-address + +generic-address = *text + +last-attempt-date-field = "Last-Attempt-Date" ":" date-time + +mta-name = *text + +mta-name-type = atom + +original-envelope-id-field = + "Original-Envelope-Id" ":" envelope-id + +original-recipient-field = + "Original-Recipient" ":" address-type ";" generic-address + + + + +Moore & Vaudreuil Standards Track [Page 26] + +RFC 1894 Delivery Status Notifications January 1996 + + +per-message-fields = + [ original-envelope-id-field CRLF ] + reporting-mta-field CRLF + [ dsn-gateway-field CRLF ] + [ received-from-mta-field CRLF ] + [ arrival-date-field CRLF ] + *( extension-field CRLF ) + +per-recipient-fields = + [ original-recipient-field CRLF ] + final-recipient-field CRLF + action-field CRLF + status-field CRLF + [ remote-mta-field CRLF ] + [ diagnostic-code-field CRLF ] + [ last-attempt-date-field CRLF ] + [ will-retry-until-field CRLF ] + *( extension-field CRLF ) + +received-from-mta-field = + "Received-From-MTA" ":" mta-name-type ";" mta-name + +remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name + +reporting-mta-field = + "Reporting-MTA" ":" mta-name-type ";" mta-name + +status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT + + ; White-space characters and comments are NOT allowed within a + ; status-code, though a comment enclosed in parentheses MAY follow + ; the last numeric subfield of the status-code. Each numeric + ; subfield within the status-code MUST be expressed without + ; leading zero digits. + +status-field = "Status" ":" status-code + +will-retry-until-field = "Will-Retry-Until" ":" date-time + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 27] + +RFC 1894 Delivery Status Notifications January 1996 + + +6. Appendix - Guidelines for gatewaying DSNs + + NOTE: This section provides non-binding recommendations for the + construction of mail gateways that wish to provide semi-transparent + delivery reports between the Internet and another electronic mail + system. Specific DSN gateway requirements for a particular pair of + mail systems may be defined by other documents. + +6.1 Gatewaying from other mail systems to DSNs + + A mail gateway may issue a DSN to convey the contents of a "foreign" + delivery or non-delivery notification over Internet mail. When there + are appropriate mappings from the foreign notification elements to + DSN fields, the information may be transmitted in those DSN fields. + Additional information (such as might be useful in a trouble ticket + or needed to tunnel the foreign notification through the Internet) + may be defined in extension DSN fields. (Such fields should be given + names that identify the foreign mail protocol, e.g. X400-* for X.400 + NDN or DN protocol elements) + + The gateway must attempt to supply reasonable values for the + Reporting-MTA, Final-Recipient, Action, and Status fields. These + will normally be obtained by translating the values from the remote + delivery or non-delivery notification into their Internet-style + equivalents. However, some loss of information is to be expected. + For example, the set of status-codes defined for DSNs may not be + adequate to fully convey the delivery diagnostic code from the + foreign system. The gateway should assign the most precise code + which describes the failure condition, falling back on "generic" + codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0 + (permanent failure) when necessary. The actual foreign diagnostic + code should be retained in the Diagnostic-Code field (with an + appropriate diagnostic-type value) for use in trouble tickets or + tunneling. + + The sender-specified recipient address, and the original envelope-id, + if present in the foreign transport envelope, should be preserved in + the Original-Recipient and Original-Envelope-ID fields. + + The gateway should also attempt to preserve the "final" recipient + addresses and MTA names from the foreign system. Whenever possible, + foreign protocol elements should be encoded as meaningful printable + ASCII strings. + + For DSNs produced from foreign delivery or nondelivery notifications, + the name of the gateway MUST appear in the DSN-Gateway field of the + DSN. + + + + +Moore & Vaudreuil Standards Track [Page 28] + +RFC 1894 Delivery Status Notifications January 1996 + + +6.2 Gatewaying from DSNs to other mail systems + + It may be possible to gateway DSNs from the Internet into a foreign + mail system. The primary purpose of such gatewaying is to convey + delivery status information in a form that is usable by the + destination system. A secondary purpose is to allow "tunneling" of + DSNs through foreign mail systems, in case the DSN may be gatewayed + back into the Internet. + + In general, the recipient of the DSN (i.e., the sender of the + original message) will want to know, for each recipient: the closest + available approximation to the original recipient address, the + delivery status (success, failure, or temporary failure), and for + failed deliveries, a diagnostic code that describes the reason for + the failure. + + If possible, the gateway should attempt to preserve the Original- + Recipient address and Original-Envelope-ID (if present), in the + resulting foreign delivery status report. + + When reporting delivery failures, if the diagnostic-type subfield of + the Diagnostic-Code field indicates that the original diagnostic code + is understood by the destination environment, the information from + the Diagnostic-Code field should be used. Failing that, the + information in the Status field should be mapped into the closest + available diagnostic code used in the destination environment. + + If it is possible to tunnel a DSN through the destination + environment, the gateway specification may define a means of + preserving the DSN information in the delivery status reports used by + that environment. + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 29] + +RFC 1894 Delivery Status Notifications January 1996 + + +7. Appendix - Guidelines for use of DSNs by mailing list exploders + + NOTE: This section pertains only to the use of DSNs by "mailing + lists" as defined in [4], section 7.2.7. + + DSNs are designed to be used by mailing list exploders to allow them + to detect and automatically delete recipients for whom mail delivery + fails repeatedly. + + When forwarding a message to list subscribers, the mailing list + exploder should always set the envelope return address (e.g. SMTP + MAIL FROM address) to point to a special address which is set up to + received nondelivery reports. A "smart" mailing list exploder can + therefore intercept such nondelivery reports, and if they are in the + DSN format, automatically examine them to determine for which + recipients a message delivery failed or was delayed. + + The Original-Recipient field should be used if available, since it + should exactly match the subscriber address known to the list. If + the Original-Recipient field is not available, the recipient field + may resemble the list subscriber address. Often, however, the list + subscriber will have forwarded his mail to a different address, or + the address may be subject to some re-writing, so heuristics may be + required to successfully match an address from the recipient field. + Care is needed in this case to minimize the possibility of false + matches. + + The reason for delivery failure can be obtained from the Status and + Action fields, and from the Diagnostic-Code field (if the status-type + is recognized). Reports for recipients with action values other than + "failed" can generally be ignored; in particular, subscribers should + not be removed from a list due to "delayed" reports. + + In general, almost any failure status code (even a "permanent" one) + can result from a temporary condition. It is therefore recommended + that a list exploder not delete a subscriber based on any single + failure DSN (regardless of the status code), but only on the + persistence of delivery failure over a period of time. + + However, some kinds of failures are less likely than others to have + been caused by temporary conditions, and some kinds of failures are + more likely to be noticed and corrected quickly than others. Once + more precise status codes are defined, it may be useful to + differentiate between the status codes when deciding whether to + delete a subscriber. For example, on a list with a high message + volume, it might be desirable to temporarily suspend delivery to a + recipient address which causes repeated "temporary" failures, rather + than simply deleting the recipient. The duration of the suspension + + + +Moore & Vaudreuil Standards Track [Page 30] + +RFC 1894 Delivery Status Notifications January 1996 + + + might depend on the type of error. On the other hand, a "user + unknown" error which persisted for several days could be considered a + reliable indication that address were no longer valid. + +8. Appendix - IANA registration forms for DSN types + + The forms below are for use when registering a new address-type, + diagnostic-type, or MTA-name-type with the Internet Assigned Numbers + Authority (IANA). Each piece of information requested by a + registration form may be satisfied either by providing the + information on the form itself, or by including a reference to a + published, publicly available specification which includes the + necessary information. IANA MAY reject DSN type registrations + because of incomplete registration forms, imprecise specifications, + or inappropriate type names. + + To register a DSN type, complete the applicable form below and send + it via Internet electronic mail to <IANA@IANA.ORG>. + +8.1 IANA registration form for address-type + + A registration for a DSN address-type MUST include the following + information: + +(a) The proposed address-type name. + +(b) The syntax for mailbox addresses of this type, specified using BNF, + regular expressions, ASN.1, or other non-ambiguous language. + +(c) If addresses of this type are not composed entirely of graphic + characters from the US-ASCII repertoire, a specification for how + they are to be encoded as graphic US-ASCII characters in a DSN + Original-Recipient or Final-Recipient DSN field. + +(d) [optional] A specification for how addresses of this type are to be + translated to and from Internet electronic mail addresses. + +8.2 IANA registration form for diagnostic-type + + A registration for a DSN address-type MUST include the following + information: + +(a) The proposed diagnostic-type name. + +(b) A description of the syntax to be used for expressing diagnostic + codes of this type as graphic characters from the US-ASCII + repertoire. + + + + +Moore & Vaudreuil Standards Track [Page 31] + +RFC 1894 Delivery Status Notifications January 1996 + + +(c) A list of valid diagnostic codes of this type and the meaning of + each code. + +(d) [optional] A specification for mapping from diagnostic codes of this + type to DSN status codes (as defined in [5]). + +8.3 IANA registration form for MTA-name-type + + A registration for a DSN MTA-name-type must include the following + information: + +(a) The proposed MTA-name-type name. + +(b) A description of the syntax of MTA names of this type, using BNF, + regular expressions, ASN.1, or other non-ambiguous language. + +(c) If MTA names of this type do not consist entirely of graphic + characters from the US-ASCII repertoire, a specification for how an + MTA name of this type should be expressed as a sequence of graphic + US-ASCII characters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 32] + +RFC 1894 Delivery Status Notifications January 1996 + + +9. Appendix - Examples + + NOTE: These examples are provided as illustration only, and are not + considered part of the DSN protocol specification. If an example + conflicts with the protocol definition above, the example is wrong. + + Likewise, the use of *-type subfield names or extension fields in + these examples is not to be construed as a definition for those type + names or extension fields. + + These examples were manually translated from bounced messages using + whatever information was available. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 33] + +RFC 1894 Delivery Status Notifications January 1996 + + +9.1 This is a simple DSN issued after repeated attempts + to deliver a message failed. In this case, the DSN is + issued by the same MTA from which the message was originated. + + + Date: Thu, 7 Jul 1994 17:16:05 -0400 + From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU> + Message-Id: <199407072116.RAA14128@CS.UTK.EDU> + Subject: Returned mail: Cannot send message for 5 days + To: <owner-info-mime@cs.utk.edu> + MIME-Version: 1.0 + Content-Type: multipart/report; report-type=delivery-status; + boundary="RAA14128.773615765/CS.UTK.EDU" + + --RAA14128.773615765/CS.UTK.EDU + + The original message was received at Sat, 2 Jul 1994 17:10:28 -0400 + from root@localhost + + ----- The following addresses had delivery problems ----- + <louisl@larry.slip.umd.edu> (unrecoverable error) + + ----- Transcript of session follows ----- + <louisl@larry.slip.umd.edu>... Deferred: Connection timed out + with larry.slip.umd.edu. + Message could not be delivered for 5 days + Message will be deleted from queue + + --RAA14128.773615765/CS.UTK.EDU + content-type: message/delivery-status + + Reporting-MTA: dns; cs.utk.edu + + Original-Recipient: rfc822;louisl@larry.slip.umd.edu + Final-Recipient: rfc822;louisl@larry.slip.umd.edu + Action: failed + Status: 4.0.0 + Diagnostic-Code: smtp; 426 connection timed out + Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 + + --RAA14128.773615765/CS.UTK.EDU + content-type: message/rfc822 + + [original message goes here] + --RAA14128.773615765/CS.UTK.EDU-- + + + + + + +Moore & Vaudreuil Standards Track [Page 34] + +RFC 1894 Delivery Status Notifications January 1996 + + +9.2 This is another DSN issued by the sender's MTA, which + contains details of multiple delivery attempts. Some of + these were detected locally, and others by a remote MTA. + + + Date: Fri, 8 Jul 1994 09:21:47 -0400 + From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU> + Subject: Returned mail: User unknown + To: <owner-ups-mib@CS.UTK.EDU> + MIME-Version: 1.0 + Content-Type: multipart/report; report-type=delivery-status; + boundary="JAA13167.773673707/CS.UTK.EDU" + + --JAA13167.773673707/CS.UTK.EDU + content-type: text/plain; charset=us-ascii + + ----- The following addresses had delivery problems ----- + <arathib@vnet.ibm.com> (unrecoverable error) + <wsnell@sdcc13.ucsd.edu> (unrecoverable error) + + --JAA13167.773673707/CS.UTK.EDU + content-type: message/delivery-status + + Reporting-MTA: dns; cs.utk.edu + + Original-Recipient: rfc822;arathib@vnet.ibm.com + Final-Recipient: rfc822;arathib@vnet.ibm.com + Action: failed + Status: 5.0.0 (permanent failure) + Diagnostic-Code: smtp; + 550 'arathib@vnet.IBM.COM' is not a registered gateway user + Remote-MTA: dns; vnet.ibm.com + + Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com + Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com + Action: delayed + Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure) + + Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu + Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu + Action: failed + Status: 5.0.0 + Diagnostic-Code: smtp; 550 user unknown + Remote-MTA: dns; sdcc13.ucsd.edu + + --JAA13167.773673707/CS.UTK.EDU + content-type: message/rfc822 + + + + +Moore & Vaudreuil Standards Track [Page 35] + +RFC 1894 Delivery Status Notifications January 1996 + + + [original message goes here] + --JAA13167.773673707/CS.UTK.EDU-- + + +9.3 A delivery report generated by Message Router (MAILBUS) and + gatewayed by PMDF_MR to a DSN. In this case the gateway did not + have sufficient information to supply an original-recipient address. + + + + Disclose-recipients: prohibited + Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT) + From: Message Router Submission Agent <AMMGR@corp.timeplex.com> + Subject: Status of : Re: Battery current sense + To: owner-ups-mib@CS.UTK.EDU + Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com> + MIME-version: 1.0 + content-type: multipart/report; report-type=delivery-status; + boundary="84229080704991.122306.SYS30" + + --84229080704991.122306.SYS30 + content-type: text/plain + + Invalid address - nair_s + %DIR-E-NODIRMTCH, No matching Directory Entry found + + --84229080704991.122306.SYS30 + content-type: message/delivery-status + + Reporting-MTA: mailbus; SYS30 + + Final-Recipient: unknown; nair_s + Status: 5.0.0 (unknown permanent failure) + Action: failed + + --84229080704991.122306.SYS30-- + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 36] + +RFC 1894 Delivery Status Notifications January 1996 + + +9.4 A delay report from a multiprotocol MTA. Note that there is no + returned content, so no third body part appears in the DSN. + + From: <postmaster@nsfnet-relay.ac.uk> + Message-Id: <199407092338.TAA23293@CS.UTK.EDU> + Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk + id <g.12954-0@sun2.nsfnet-relay.ac.uk>; + Sun, 10 Jul 1994 00:36:51 +0100 + To: owner-info-mime@cs.utk.edu + Date: Sun, 10 Jul 1994 00:36:51 +0100 + Subject: WARNING: message delayed at "nsfnet-relay.ac.uk" + content-type: multipart/report; report-type=delivery-status; + boundary=foobar + + --foobar + content-type: text/plain + + The following message: + + UA-ID: Reliable PC (... + Q-ID: sun2.nsf:77/msg.11820-0 + + has not been delivered to the intended recipient: + + thomas@de-montfort.ac.uk + + despite repeated delivery attempts over the past 24 hours. + + The usual cause of this problem is that the remote system is + temporarily unavailable. + + Delivery will continue to be attempted up to a total elapsed + time of 168 hours, ie 7 days. + + You will be informed if delivery proves to be impossible + within this time. + + Please quote the Q-ID in any queries regarding this mail. + + --foobar + content-type: message/delivery-status + + Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk + + Final-Recipient: rfc822;thomas@de-montfort.ac.uk + Status: 4.0.0 (unknown temporary failure) + Action: delayed + + + + +Moore & Vaudreuil Standards Track [Page 37] + +RFC 1894 Delivery Status Notifications January 1996 + + + --foobar-- + +10. Acknowledgments + + The authors wish to thank the following people for their reviews of + earlier drafts of this document and their suggestions for + improvement: Eric Allman, Harald Alvestrand, Allan Cargille, Jim + Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko + Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark + Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory + Sheehan. + +11. References + +[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", + RFC 1521, Bellcore, Innosoft, September 1993. + +[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting + of Mail System Administrative Messages", RFC 1892, Octal Network + Services, January 1996. + +[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + USC/Information Sciences Institute, August 1982. + +[4] Moore, K., "SMTP Service Extension for Delivery Status + Notifications", RFC 1891, University of Tennessee, January 1996. + +[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octal + Network Services, January 1996. + +[6] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + +[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two: + Message Header Extensions for Non-Ascii Text", RFC 1522, University + of Tennessee, September 1993. + +[8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, USC/Information Sciences Institute, + October 1989. + +[9] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, BBN, + February 1988. + + + + + + + + +Moore & Vaudreuil Standards Track [Page 38] + +RFC 1894 Delivery Status Notifications January 1996 + + +11. Authors' Addresses + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville, TN 37996-1301 + USA + + EMail: moore@cs.utk.edu + Phone: +1 615 974 3126 + Fax: +1 615 974 8296 + + + Gregory M. Vaudreuil + Octel Network Services + 17080 Dallas Parkway + Dallas, TX 75248-1905 + USA + + EMail: Greg.Vaudreuil@Octel.Com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore & Vaudreuil Standards Track [Page 39] + diff --git a/RFC/rfc1938.txt b/RFC/rfc1938.txt new file mode 100644 index 00000000..5d3a9002 --- /dev/null +++ b/RFC/rfc1938.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group N. Haller +Request for Comments: 1938 Bellcore +Category: Standards Track C. Metz + Kaman Sciences Corporation + May 1996 + + + A One-Time Password System + +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.0 ABSTRACT + + This document describes a one-time password authentication system + (OTP). The system provides authentication for system access (login) + and other applications requiring authentication that is secure + against passive attacks based on replaying captured reusable + passwords. OTP evolved from the S/KEY (S/KEY is a trademark of + Bellcore) One-Time Password System that was released by Bellcore and + is described in references [3] and [5]. + +2.0 OVERVIEW + + One form of attack on networked computing systems is eavesdropping on + network connections to obtain authentication information such as the + login IDs and passwords of legitimate users. Once this information is + captured, it can be used at a later time to gain access to the + system. One-time password systems are designed to counter this type + of attack, called a "replay attack" [4]. + + The authentication system described in this document uses a secret + pass-phrase to generate a sequence of one-time (single use) + passwords. With this system, the user's secret pass-phrase never + needs to cross the network at any time such as during authentication + or during pass-phrase changes. Thus, it is not vulnerable to replay + attacks. Added security is provided by the property that no secret + information need be stored on any system, including the server being + protected. + + The OTP system protects against external passive attacks against the + authentication subsystem. It does not prevent a network eavesdropper + from gaining access to private information and does not provide + + + +Haller & Metz Standards Track [Page 1] + +RFC 1938 A One-Time Password System May 1996 + + + protection against either "social engineering" or active attacks [9]. + +3.0 INTRODUCTION + + There are two entities in the operation of the OTP one-time password + system. The generator must produce the appropriate one-time password + from the user's secret pass-phrase and from information provided in + the challenge from the server. The server must send a challenge that + includes the appropriate generation parameters to the generator, must + verify the one-time password received, must store the last valid + one-time password it received, and must store the corresponding one- + time password sequence number. The server must also facilitate the + changing of the user's secret pass-phrase in a secure manner. + + The OTP system generator passes the user's secret pass-phrase, along + with a seed received from the server as part of the challenge, + through multiple iterations of a secure hash function to produce a + one-time password. After each successful authentication, the number + of secure hash function iterations is reduced by one. Thus, a unique + sequence of passwords is generated. The server verifies the one-time + password received from the generator by computing the secure hash + function once and comparing the result with the previously accepted + one-time password. This technique was first suggested by Leslie + Lamport [1]. + +4.0 REQUIREMENTS TERMINOLOGY + + In this document, the words that are used to define the significance + of each particular requirement are usually capitalized. These words + are: + + - MUST + + This word or the adjective "REQUIRED" means that the item is an + absolute requirement of the specification. + + - SHOULD + + This word or the adjective "RECOMMENDED" means that there might + exist valid reasons in particular circumstances to ignore this + item, but the full implications should be understood and the + case carefully weighed before taking a different course. + + - MAY + + This word or the adjective "OPTIONAL" means that this item is + truly optional. One vendor might choose to include the item + because a particular marketplace requires it or because it + + + +Haller & Metz Standards Track [Page 2] + +RFC 1938 A One-Time Password System May 1996 + + + enhances the product, for example; another vendor may omit the + same item. + +5.0 SECURE HASH FUNCTION + + The security of the OTP system is based on the non-invertability of a + secure hash function. Such a function must be tractable to compute in + the forward direction, but computationally infeasible to invert. + + The interfaces are currently defined for three such hash algorithms, + MD4 [2] and MD5 [6] by Ronald Rivest, and SHA [7] by NIST. All + conforming implementations of both server and generators MUST support + MD5. They SHOULD support SHA and MAY also support MD4. Clearly, the + generator and server must use the same algorithm in order to + interoperate. Other hash algorithms may be specified for use with + this system by publishing the appropriate interfaces. + + The secure hash algorithms listed above have the property that they + accept an input that is arbitrarily long and produce a fixed size + output. The OTP system folds this output to 64 bits using the + algorithms in the Appendix A. 64 bits is also the length of the one- + time passwords. This is believed to be long enough to be secure and + short enough to be entered manually (see below, Form of Output) when + necessary. + +6.0 GENERATION OF ONE-TIME PASSWORDS + + This section describes the generation of the one-time passwords. + This process consists of an initial step in which all inputs are + combined, a computation step where the secure hash function is + applied a specified number of times, and an output function where the + 64 bit one-time password is converted to a human readable form. + + Initial Step + + In principle, the user's secret pass-phrase may be of any length. + To reduce the risk from techniques such as exhaustive search or + dictionary attacks, character string pass-phrases MUST contain at + least 10 characters (see Form of Inputs below). All + implementations MUST support a pass-phrases of at least 63 + characters. The secret pass-phrase is frequently, but is not + required to be, textual information provided by a user. + + In this step, the pass phrase is concatenated with a seed that is + transmitted from the server in clear text. This non-secret seed + allows clients to use the same secret pass-phrase on multiple + machines (using different seeds) and to safely recycle their + secret pass-phrases by changing the seed. + + + +Haller & Metz Standards Track [Page 3] + +RFC 1938 A One-Time Password System May 1996 + + + The result of the concatenation is passed through the secure hash + function and then is reduced to 64 bits using one of the function + dependent algorithms shown in Appendix A. + + Computation Step + + A sequence of one-time passwords is produced by applying the + secure hash function multiple times to the output of the initial + step (called S). That is, the first one-time password to be used + is produced by passing S through the secure hash function a number + of times (N) specified by the user. The next one-time password to + be used is generated by passing S though the secure hash function + N-1 times. An eavesdropper who has monitored the transmission of a + one- time password would not be able to generate the next required + password because doing so would mean inverting the hash function. + + Form of Inputs + + The secret pass-phrase is seen only by the OTP generator. To allow + interchangeability of generators, all generators MUST support a + secret pass-phrase of 10 to 63 characters. Implementations MAY + support a longer pass-phrase, but such implementations risk the + loss of interchangeability with implementations supporting only + the minimum. + + The seed MUST consist of purely alphanumeric characters and MUST + be of one to 16 characters in length. The seed is a string of + characters that MUST not contain any blanks and SHOULD consist of + strictly alphanumeric characters from the ISO-646 Invariant Code + Set. The seed MUST be case insensitive and MUST be internally + converted to lower case before it is processed. + + The sequence number and seed together constitute a larger unit of + data called the challenge. The challenge gives the generator the + parameters it needs to calculate the correct one-time password + from the secret pass-phrase. The challenge MUST be in a standard + syntax so that automated generators can recognize the challenge in + context and extract these parameters. The syntax of the challenge + is: + + otp-<algorithm identifier> <sequence integer> <seed> + + The three tokens MUST be separated by a white space (defined as + any number of spaces and/or tabs) and the entire challenge string + MUST be terminated with either a space or a new line. The string + "otp-" MUST be in lower case. The algorithm identifier is case + sensitive (the existing identifiers are all lower case), and the + seed is case insensitive and converted before use to lower case. + + + +Haller & Metz Standards Track [Page 4] + +RFC 1938 A One-Time Password System May 1996 + + + If additional algorithms are defined, appropriate identifiers + (short, but not limited to three or four characters) must be + defined. The currently defined algorithm identifiers are: + + md4 MD4 Message Digest + md5 MD5 Message Digest + sha1 NIST Secure Hash Algorithm Revision 1 + + An example of an OTP challenge is: otp-md5 487 dog2 + + Form of Output + + The one-time password generated by the above procedure is 64 bits + in length. Entering a 64 bit number is a difficult and error prone + process. Some generators insert this password into the input + stream and some others make it available for system "cut and + paste." Still other arrangements require the one-time password to + be entered manually. The OTP system is designed to facilitate this + manual entry without impeding automatic methods. The one-time + password therefore MAY be converted to, and all servers MUST be + capable of accepting it as, a sequence of six short (1 to 4 + letter) easily typed words that only use characters from ISO-646 + IVCS. Each word is chosen from a dictionary of 2048 words; at 11 + bits per word, all one-time passwords may be encoded. + + The two extra bits in this encoding are used to store a checksum. + The 64 bits of key are broken down into pairs of bits, then these + pairs are summed together. The two least significant bits of this + sum are encoded in the last two bits of the six word sequence with + the least significant bit of the sum as the last bit encoded. All + OTP generators MUST calculate this checksum and all OTP servers + MUST verify this checksum explicitly as part of the operation of + decoding this representation of the one-time password. + + Generators that produce the six-word format MUST present the words + in upper case with single spaces used as separators. All servers + MUST accept six-word format without regard to case and white space + used as a separator. The two lines below represent the same one- + time password. The first is valid as output from a generator and + as input a server, the second is valid only as human input to a + server. + + OUST COAT FOAL MUG BEAK TOTE + oust coat foal mug beak tote + + Interoperability requires that all OTP servers and generators use + the same dictionary. The standard dictionary was originally + specified in the "S/KEY One Time Password System" that is + + + +Haller & Metz Standards Track [Page 5] + +RFC 1938 A One-Time Password System May 1996 + + + described in RFC 1760 [5]. This dictionary is included in this + document as Appendix C. + + To facilitate the implementation of smaller generators, + hexadecimal output is an acceptable alternative for the + presentation of the one-time password. All implementations of the + server software MUST accept case-insensitive hexadecimal as well + as six-word format. The hexadecimal digits may be separated by + white space so servers are REQUIRED to ignore all white space. If + the representation is partitioned by white space, leading zeros + must be retained. Examples of hexadecimal format are: + + Representation Value + + 3503785b369cda8b 0x3503785b369cda8b + e5cc a1b8 7c13 096b 0xe5cca1b87c13096b + C7 48 90 F4 27 7B A1 CF 0xc74890f4277ba1cf + 47 9 A68 28 4C 9D 0 1BC 0x479a68284c9d01bc + + In addition to accepting six-word and hexadecimal encodings of the + 64 bit one-time password, servers SHOULD accept the alternate + dictionary encoding described in Appendix B. The six words in + this encoding MUST not overlap the set of words in the standard + dictionary. To avoid ambiguity with the hexadecimal + representation, words in the alternate dictionary MUST not be + comprised solely of the letters A-F. Decoding words thus encoded + does not require any knowledge of the alternative dictionary used + so the acceptance of any alternate dictionary implies the + acceptance of all alternate dictionaries. Words in the + alternative dictionaries are case sensitive. Generators and + servers MUST preserve the case in the processing of these words. + + In summary, all conforming servers MUST accept six-word input that + uses the Standard Dictionary (RFC 1760 and Appendix C), MUST + accept hexadecimal encoding, and SHOULD accept six-word input that + uses the Alternative Dictionary technique (Appendix B). As there + is a remote possibility that a hexadecimal encoding of a one-time + password will look like a valid six-word standard dictionary + encoding, all implementations MUST use the following scheme. If a + six-word encoded one-time password is valid, it is accepted. + Otherwise, if the one-time password can be interpreted as + hexadecimal, and with that decoding it is valid, then it is + accepted. + + + + + + + + +Haller & Metz Standards Track [Page 6] + +RFC 1938 A One-Time Password System May 1996 + + +7.0 VERIFICATION OF ONE-TIME PASSWORDS + + An application on the server system that requires OTP authentication + is expected to issue an OTP challenge as described above. Given the + parameters from this challenge and the secret pass-phrase, the + generator can compute (or lookup) the one-time password that is + passed to the server to be verified. + + The server system has a database containing, for each user, the one- + time password from the last successful authentication or the first + OTP of a newly initialized sequence. To authenticate the user, the + server decodes the one-time password received from the generator into + a 64-bit key and then runs this key through the secure hash function + once. If the result of this operation matches the stored previous + OTP, the authentication is successful and the accepted one-time + password is stored for future use. + +8.0 PASS-PHRASE CHANGES + + Because the number of hash function applications executed by the + generator decreases by one each time, at some point the user must + reinitialize the system or be unable to authenticate. + + Although some installations may not permit users to initialize + remotely, implementations MUST provide a means to do so that does not + reveal the user's secret pass-phrase. One way is to provide a means + to reinitialize the sequence through explicit specification of the + first one-time password. + + When the sequence of one-time passwords is reinitialized, + implementations MUST verify that the seed or the pass-phrase is + changed. Installations SHOULD discourage any operation that sends + the secret pass-phrase over a network in clear-text as such practice + defeats the concept of a one-time password. + + Implementations MAY use the following technique for + [re]initialization: + + o The user picks a new seed and hash count (default values may + be offered). The user provides these, along with the + corresponding generated one-time password, to the host system. + + o The user MAY also provide the corresponding generated one + time password for count-1 as an error check. + + o The user SHOULD provide the generated one-time password for + the old seed and old hash count to protect an idle terminal + or workstation (this implies that when the count is 1, the + + + +Haller & Metz Standards Track [Page 7] + +RFC 1938 A One-Time Password System May 1996 + + + user can login but cannot then change the seed or count). + + In the future a specific protocol may be defined for reinitialization + that will permit smooth and possibly automated interoperation of all + hosts and generators. + +9.0 PROTECTION AGAINST RACE ATTACK + + All conforming server implementations MUST protect against the race + condition described in this section. A defense against this attack + is outlined; implementations MAY use this approach or MAY select an + alternative defense. + + It is possible for an attacker to listen to most of a one-time + password, guess the remainder, and then race the legitimate user to + complete the authentication. Multiple guesses against the last word + of the six-word format are likely to succeed. + + One possible defense is to prevent a user from starting multiple + simultaneous authentication sessions. This means that once the + legitimate user has initiated authentication, an attacker would be + blocked until the first authentication process has completed. In + this approach, a timeout is necessary to thwart a denial of service + attack. + +10.0 SECURITY CONSIDERATIONS + + This entire document discusses an authentication system that improves + security by limiting the danger of eavesdropping/replay attacks that + have been used against simple password systems [4]. + + The use of the OTP system only provides protections against passive + eavesdropping/replay attacks. It does not provide for the privacy of + transmitted data, and it does not provide protection against active + attacks. Active attacks against TCP connections are known to be + present in the current Internet [9]. + + The success of the OTP system to protect host systems is dependent on + the non-invertability of the secure hash functions used. To our + knowledge, none of the hash algorithms have been broken, but it is + generally believed [6] that MD4 is not as strong as MD5. If a server + supports multiple hash algorithms, it is only as secure as the + weakest algorithm. + + + + + + + + +Haller & Metz Standards Track [Page 8] + +RFC 1938 A One-Time Password System May 1996 + + +11.0 ACKNOWLEDGMENTS + + The idea behind OTP authentication was first proposed by Leslie + Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was + proposed by Phil Karn, who also wrote most of the Bellcore reference + implementation. + +12.0 REFERENCES + + [1] Leslie Lamport, "Password Authentication with Insecure + Communication", Communications of the ACM 24.11 (November + 1981), 770-772 + + [2] Rivest, R., "The MD4 Message-Digest Algorithm, RFC 1320", + MIT and RSA Data Security, Inc., April 1992. + + [3] Neil Haller, "The S/KEY One-Time Password System", Proceedings + of the ISOC Symposium on Network and Distributed System + Security, February 1994, San Diego, CA + + [4] Haller, N., and R. Atkinson, "On Internet Authentication", + RFC 1704, Bellcore and Naval Research Laboratory, October 1994. + + [5] Haller, N., "The S/KEY One-Time Password System", RFC 1760, + Bellcore, February 1995. + + [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + MIT and RSA Data Security, Inc., April 1992. + + [7] National Institute of Standards and Technology (NIST), + "Announcing the Secure Hash Standard", FIPS 180-1, U.S. + Department of Commerce, April 1995. + + [8] International Standard - Information Processing -- ISO 7-bit + coded character set for information interchange (Invariant Code + Set), ISO-646, International Standards Organization, Geneva, + Switzerland, 1983 + + [9] Computer Emergency Response Team (CERT), "IP Spoofing and + Hijacked Terminal Connections", CA-95:01, January 1995. + Available via anonymous ftp from info.cert.org in + /pub/cert_advisories. + + + + + + + + + +Haller & Metz Standards Track [Page 9] + +RFC 1938 A One-Time Password System May 1996 + + +13.0 AUTHORS' ADDRESSES + + Neil Haller + Bellcore + MCC 1C-265B + 445 South Street + Morristown, NJ, 07960-6438, USA + + Phone: +1 201 829-4478 + Fax: +1 201 829-2504 + EMail: nmh@bellcore.com + + + Craig Metz + Kaman Sciences Corporation + For NRL Code 5544 + 4555 Overlook Avenue, S.W. + Washington, DC, 20375-5337, USA + + Phone: +1 202 404-7122 + Fax: +1 202 404-7942 + EMail: cmetz@cs.nrl.navy.mil + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Haller & Metz Standards Track [Page 10] + +RFC 1938 A One-Time Password System May 1996 + + +Appendix A - Interfaces to Secure Hash Algorithms + +MD4 Message Digest (see reference [2]) + + strcpy(buf,seed); + strcat(buf,passwd); + MDbegin(&md) + MDupdate(&md,(unsigned char *)buf,8*buflen); + + /* Fold result to 64 bits */ + md.buffer[0] ^= md.buffer[2]; + md.buffer[1] ^= md.buffer[3]; + + +MD5 Message Digest (see reference [6]) + + MD5_CTX mdCxt; + + strcpy(buf,seed); + strcat(buf,passwd); + + /* Crunch the key through MD5 */ + MD5Init(&mdCxt); + MD5Update(&mdCxt,(unsigned char *)bits,strlen(bits)); + MD5Update(&mdCxt,(unsigned char *)buf,buflen); + MD5Final(&mdCxt); + + /* Fold result to 64 bits */ + for( i = 0; i < 8; i++ ) + result[i] = mdCxt.digest[i] ^ mdCxt.digest[i+8]; + + +SHA Secure Hash Algorithm (see reference [7]) + + + /* Fold 160 bit result to 64 bits */ + md.buffer[0] ^= md.buffer[2]; + md.buffer[1] ^= md.buffer[3]; + md.buffer[0] ^= md.buffer[4]; + +Appendix B - Alternative Dictionary Algorithm + + The purpose of alternative dictionary encoding of the OTP one-time + password is to allow the use of language specific or friendly words. + As case translation is not always well defined, the alternative + dictionary encoding is case insensitive. Servers SHOULD accept this + encoding in addition to the standard 6-word and hexadecimal + encodings. + + + +Haller & Metz Standards Track [Page 11] + +RFC 1938 A One-Time Password System May 1996 + + +GENERATOR ENCODING USING AN ALTERNATE DICTIONARY + + The standard 6-word encoding uses the placement of a word in the + dictionary to represent an 11-bit number. The 64-bit one-time + password can then be represented by six words. + + An alternative dictionary of 2048 words may be created such that + each word W and position of the word in the dictionary N obey the + relationship: + + alg( W ) % 2048 == N + where + alg is the hash algorithm used (e.g. MD4, MD5, SHA1). + + In addition, no words in the standard dictionary may be chosen. + + The generator expands the 64-bit one-time password to 66 bits by + computing parity as with the standard 6-word encoding. The six 11- + bit numbers are then converted to words using the dictionary that + was created such that the above relationship holds. + + +SERVER DECODING OF ALTERNATE DICTIONARY ONE-TIME PASSWORDS + + The server accepting alternative dictionary encoding converts each + word to an 11-bit number using the above encoding. These numbers are + then used in the same way as the decoded standard dictionary words + to form the 66-bit one-time password. + + The server does not need to have access to the alternate dictionary + that was used to create the one-time password it is authenticating. + This is because the decoding from word to 11-bit number does not + make any use of the dictionary. As a result of the independence of + the dictionary, a server accepting one alternate dictionary accept + all alternate dictionaries. + +Appendix C - Dictionary for Converting Between 6-Word and Binary +Formats + + This dictionary is from the module put.c in the original Bellcore + reference distribution. + +{ "A", "ABE", "ACE", "ACT", "AD", "ADA", "ADD", +"AGO", "AID", "AIM", "AIR", "ALL", "ALP", "AM", "AMY", +"AN", "ANA", "AND", "ANN", "ANT", "ANY", "APE", "APS", +"APT", "ARC", "ARE", "ARK", "ARM", "ART", "AS", "ASH", +"ASK", "AT", "ATE", "AUG", "AUK", "AVE", "AWE", "AWK", +"AWL", "AWN", "AX", "AYE", "BAD", "BAG", "BAH", "BAM", + + + +Haller & Metz Standards Track [Page 12] + +RFC 1938 A One-Time Password System May 1996 + + +"BAN", "BAR", "BAT", "BAY", "BE", "BED", "BEE", "BEG", +"BEN", "BET", "BEY", "BIB", "BID", "BIG", "BIN", "BIT", +"BOB", "BOG", "BON", "BOO", "BOP", "BOW", "BOY", "BUB", +"BUD", "BUG", "BUM", "BUN", "BUS", "BUT", "BUY", "BY", +"BYE", "CAB", "CAL", "CAM", "CAN", "CAP", "CAR", "CAT", +"CAW", "COD", "COG", "COL", "CON", "COO", "COP", "COT", +"COW", "COY", "CRY", "CUB", "CUE", "CUP", "CUR", "CUT", +"DAB", "DAD", "DAM", "DAN", "DAR", "DAY", "DEE", "DEL", +"DEN", "DES", "DEW", "DID", "DIE", "DIG", "DIN", "DIP", +"DO", "DOE", "DOG", "DON", "DOT", "DOW", "DRY", "DUB", +"DUD", "DUE", "DUG", "DUN", "EAR", "EAT", "ED", "EEL", +"EGG", "EGO", "ELI", "ELK", "ELM", "ELY", "EM", "END", +"EST", "ETC", "EVA", "EVE", "EWE", "EYE", "FAD", "FAN", +"FAR", "FAT", "FAY", "FED", "FEE", "FEW", "FIB", "FIG", +"FIN", "FIR", "FIT", "FLO", "FLY", "FOE", "FOG", "FOR", +"FRY", "FUM", "FUN", "FUR", "GAB", "GAD", "GAG", "GAL", +"GAM", "GAP", "GAS", "GAY", "GEE", "GEL", "GEM", "GET", +"GIG", "GIL", "GIN", "GO", "GOT", "GUM", "GUN", "GUS", +"GUT", "GUY", "GYM", "GYP", "HA", "HAD", "HAL", "HAM", +"HAN", "HAP", "HAS", "HAT", "HAW", "HAY", "HE", "HEM", +"HEN", "HER", "HEW", "HEY", "HI", "HID", "HIM", "HIP", +"HIS", "HIT", "HO", "HOB", "HOC", "HOE", "HOG", "HOP", +"HOT", "HOW", "HUB", "HUE", "HUG", "HUH", "HUM", "HUT", +"I", "ICY", "IDA", "IF", "IKE", "ILL", "INK", "INN", +"IO", "ION", "IQ", "IRA", "IRE", "IRK", "IS", "IT", +"ITS", "IVY", "JAB", "JAG", "JAM", "JAN", "JAR", "JAW", +"JAY", "JET", "JIG", "JIM", "JO", "JOB", "JOE", "JOG", +"JOT", "JOY", "JUG", "JUT", "KAY", "KEG", "KEN", "KEY", +"KID", "KIM", "KIN", "KIT", "LA", "LAB", "LAC", "LAD", +"LAG", "LAM", "LAP", "LAW", "LAY", "LEA", "LED", "LEE", +"LEG", "LEN", "LEO", "LET", "LEW", "LID", "LIE", "LIN", +"LIP", "LIT", "LO", "LOB", "LOG", "LOP", "LOS", "LOT", +"LOU", "LOW", "LOY", "LUG", "LYE", "MA", "MAC", "MAD", +"MAE", "MAN", "MAO", "MAP", "MAT", "MAW", "MAY", "ME", +"MEG", "MEL", "MEN", "MET", "MEW", "MID", "MIN", "MIT", +"MOB", "MOD", "MOE", "MOO", "MOP", "MOS", "MOT", "MOW", +"MUD", "MUG", "MUM", "MY", "NAB", "NAG", "NAN", "NAP", +"NAT", "NAY", "NE", "NED", "NEE", "NET", "NEW", "NIB", +"NIL", "NIP", "NIT", "NO", "NOB", "NOD", "NON", "NOR", +"NOT", "NOV", "NOW", "NU", "NUN", "NUT", "O", "OAF", +"OAK", "OAR", "OAT", "ODD", "ODE", "OF", "OFF", "OFT", +"OH", "OIL", "OK", "OLD", "ON", "ONE", "OR", "ORB", +"ORE", "ORR", "OS", "OTT", "OUR", "OUT", "OVA", "OW", +"OWE", "OWL", "OWN", "OX", "PA", "PAD", "PAL", "PAM", +"PAN", "PAP", "PAR", "PAT", "PAW", "PAY", "PEA", "PEG", +"PEN", "PEP", "PER", "PET", "PEW", "PHI", "PI", "PIE", +"PIN", "PIT", "PLY", "PO", "POD", "POE", "POP", "POT", +"POW", "PRO", "PRY", "PUB", "PUG", "PUN", "PUP", "PUT", + + + +Haller & Metz Standards Track [Page 13] + +RFC 1938 A One-Time Password System May 1996 + + +"QUO", "RAG", "RAM", "RAN", "RAP", "RAT", "RAW", "RAY", +"REB", "RED", "REP", "RET", "RIB", "RID", "RIG", "RIM", +"RIO", "RIP", "ROB", "ROD", "ROE", "RON", "ROT", "ROW", +"ROY", "RUB", "RUE", "RUG", "RUM", "RUN", "RYE", "SAC", +"SAD", "SAG", "SAL", "SAM", "SAN", "SAP", "SAT", "SAW", +"SAY", "SEA", "SEC", "SEE", "SEN", "SET", "SEW", "SHE", +"SHY", "SIN", "SIP", "SIR", "SIS", "SIT", "SKI", "SKY", +"SLY", "SO", "SOB", "SOD", "SON", "SOP", "SOW", "SOY", +"SPA", "SPY", "SUB", "SUD", "SUE", "SUM", "SUN", "SUP", +"TAB", "TAD", "TAG", "TAN", "TAP", "TAR", "TEA", "TED", +"TEE", "TEN", "THE", "THY", "TIC", "TIE", "TIM", "TIN", +"TIP", "TO", "TOE", "TOG", "TOM", "TON", "TOO", "TOP", +"TOW", "TOY", "TRY", "TUB", "TUG", "TUM", "TUN", "TWO", +"UN", "UP", "US", "USE", "VAN", "VAT", "VET", "VIE", +"WAD", "WAG", "WAR", "WAS", "WAY", "WE", "WEB", "WED", +"WEE", "WET", "WHO", "WHY", "WIN", "WIT", "WOK", "WON", +"WOO", "WOW", "WRY", "WU", "YAM", "YAP", "YAW", "YE", +"YEA", "YES", "YET", "YOU", "ABED", "ABEL", "ABET", "ABLE", +"ABUT", "ACHE", "ACID", "ACME", "ACRE", "ACTA", "ACTS", "ADAM", +"ADDS", "ADEN", "AFAR", "AFRO", "AGEE", "AHEM", "AHOY", "AIDA", +"AIDE", "AIDS", "AIRY", "AJAR", "AKIN", "ALAN", "ALEC", "ALGA", +"ALIA", "ALLY", "ALMA", "ALOE", "ALSO", "ALTO", "ALUM", "ALVA", +"AMEN", "AMES", "AMID", "AMMO", "AMOK", "AMOS", "AMRA", "ANDY", +"ANEW", "ANNA", "ANNE", "ANTE", "ANTI", "AQUA", "ARAB", "ARCH", +"AREA", "ARGO", "ARID", "ARMY", "ARTS", "ARTY", "ASIA", "ASKS", +"ATOM", "AUNT", "AURA", "AUTO", "AVER", "AVID", "AVIS", "AVON", +"AVOW", "AWAY", "AWRY", "BABE", "BABY", "BACH", "BACK", "BADE", +"BAIL", "BAIT", "BAKE", "BALD", "BALE", "BALI", "BALK", "BALL", +"BALM", "BAND", "BANE", "BANG", "BANK", "BARB", "BARD", "BARE", +"BARK", "BARN", "BARR", "BASE", "BASH", "BASK", "BASS", "BATE", +"BATH", "BAWD", "BAWL", "BEAD", "BEAK", "BEAM", "BEAN", "BEAR", +"BEAT", "BEAU", "BECK", "BEEF", "BEEN", "BEER", "BEET", "BELA", +"BELL", "BELT", "BEND", "BENT", "BERG", "BERN", "BERT", "BESS", +"BEST", "BETA", "BETH", "BHOY", "BIAS", "BIDE", "BIEN", "BILE", +"BILK", "BILL", "BIND", "BING", "BIRD", "BITE", "BITS", "BLAB", +"BLAT", "BLED", "BLEW", "BLOB", "BLOC", "BLOT", "BLOW", "BLUE", +"BLUM", "BLUR", "BOAR", "BOAT", "BOCA", "BOCK", "BODE", "BODY", +"BOGY", "BOHR", "BOIL", "BOLD", "BOLO", "BOLT", "BOMB", "BONA", +"BOND", "BONE", "BONG", "BONN", "BONY", "BOOK", "BOOM", "BOON", +"BOOT", "BORE", "BORG", "BORN", "BOSE", "BOSS", "BOTH", "BOUT", +"BOWL", "BOYD", "BRAD", "BRAE", "BRAG", "BRAN", "BRAY", "BRED", +"BREW", "BRIG", "BRIM", "BROW", "BUCK", "BUDD", "BUFF", "BULB", +"BULK", "BULL", "BUNK", "BUNT", "BUOY", "BURG", "BURL", "BURN", +"BURR", "BURT", "BURY", "BUSH", "BUSS", "BUST", "BUSY", "BYTE", +"CADY", "CAFE", "CAGE", "CAIN", "CAKE", "CALF", "CALL", "CALM", +"CAME", "CANE", "CANT", "CARD", "CARE", "CARL", "CARR", "CART", +"CASE", "CASH", "CASK", "CAST", "CAVE", "CEIL", "CELL", "CENT", +"CERN", "CHAD", "CHAR", "CHAT", "CHAW", "CHEF", "CHEN", "CHEW", + + + +Haller & Metz Standards Track [Page 14] + +RFC 1938 A One-Time Password System May 1996 + + +"CHIC", "CHIN", "CHOU", "CHOW", "CHUB", "CHUG", "CHUM", "CITE", +"CITY", "CLAD", "CLAM", "CLAN", "CLAW", "CLAY", "CLOD", "CLOG", +"CLOT", "CLUB", "CLUE", "COAL", "COAT", "COCA", "COCK", "COCO", +"CODA", "CODE", "CODY", "COED", "COIL", "COIN", "COKE", "COLA", +"COLD", "COLT", "COMA", "COMB", "COME", "COOK", "COOL", "COON", +"COOT", "CORD", "CORE", "CORK", "CORN", "COST", "COVE", "COWL", +"CRAB", "CRAG", "CRAM", "CRAY", "CREW", "CRIB", "CROW", "CRUD", +"CUBA", "CUBE", "CUFF", "CULL", "CULT", "CUNY", "CURB", "CURD", +"CURE", "CURL", "CURT", "CUTS", "DADE", "DALE", "DAME", "DANA", +"DANE", "DANG", "DANK", "DARE", "DARK", "DARN", "DART", "DASH", +"DATA", "DATE", "DAVE", "DAVY", "DAWN", "DAYS", "DEAD", "DEAF", +"DEAL", "DEAN", "DEAR", "DEBT", "DECK", "DEED", "DEEM", "DEER", +"DEFT", "DEFY", "DELL", "DENT", "DENY", "DESK", "DIAL", "DICE", +"DIED", "DIET", "DIME", "DINE", "DING", "DINT", "DIRE", "DIRT", +"DISC", "DISH", "DISK", "DIVE", "DOCK", "DOES", "DOLE", "DOLL", +"DOLT", "DOME", "DONE", "DOOM", "DOOR", "DORA", "DOSE", "DOTE", +"DOUG", "DOUR", "DOVE", "DOWN", "DRAB", "DRAG", "DRAM", "DRAW", +"DREW", "DRUB", "DRUG", "DRUM", "DUAL", "DUCK", "DUCT", "DUEL", +"DUET", "DUKE", "DULL", "DUMB", "DUNE", "DUNK", "DUSK", "DUST", +"DUTY", "EACH", "EARL", "EARN", "EASE", "EAST", "EASY", "EBEN", +"ECHO", "EDDY", "EDEN", "EDGE", "EDGY", "EDIT", "EDNA", "EGAN", +"ELAN", "ELBA", "ELLA", "ELSE", "EMIL", "EMIT", "EMMA", "ENDS", +"ERIC", "EROS", "EVEN", "EVER", "EVIL", "EYED", "FACE", "FACT", +"FADE", "FAIL", "FAIN", "FAIR", "FAKE", "FALL", "FAME", "FANG", +"FARM", "FAST", "FATE", "FAWN", "FEAR", "FEAT", "FEED", "FEEL", +"FEET", "FELL", "FELT", "FEND", "FERN", "FEST", "FEUD", "FIEF", +"FIGS", "FILE", "FILL", "FILM", "FIND", "FINE", "FINK", "FIRE", +"FIRM", "FISH", "FISK", "FIST", "FITS", "FIVE", "FLAG", "FLAK", +"FLAM", "FLAT", "FLAW", "FLEA", "FLED", "FLEW", "FLIT", "FLOC", +"FLOG", "FLOW", "FLUB", "FLUE", "FOAL", "FOAM", "FOGY", "FOIL", +"FOLD", "FOLK", "FOND", "FONT", "FOOD", "FOOL", "FOOT", "FORD", +"FORE", "FORK", "FORM", "FORT", "FOSS", "FOUL", "FOUR", "FOWL", +"FRAU", "FRAY", "FRED", "FREE", "FRET", "FREY", "FROG", "FROM", +"FUEL", "FULL", "FUME", "FUND", "FUNK", "FURY", "FUSE", "FUSS", +"GAFF", "GAGE", "GAIL", "GAIN", "GAIT", "GALA", "GALE", "GALL", +"GALT", "GAME", "GANG", "GARB", "GARY", "GASH", "GATE", "GAUL", +"GAUR", "GAVE", "GAWK", "GEAR", "GELD", "GENE", "GENT", "GERM", +"GETS", "GIBE", "GIFT", "GILD", "GILL", "GILT", "GINA", "GIRD", +"GIRL", "GIST", "GIVE", "GLAD", "GLEE", "GLEN", "GLIB", "GLOB", +"GLOM", "GLOW", "GLUE", "GLUM", "GLUT", "GOAD", "GOAL", "GOAT", +"GOER", "GOES", "GOLD", "GOLF", "GONE", "GONG", "GOOD", "GOOF", +"GORE", "GORY", "GOSH", "GOUT", "GOWN", "GRAB", "GRAD", "GRAY", +"GREG", "GREW", "GREY", "GRID", "GRIM", "GRIN", "GRIT", "GROW", +"GRUB", "GULF", "GULL", "GUNK", "GURU", "GUSH", "GUST", "GWEN", +"GWYN", "HAAG", "HAAS", "HACK", "HAIL", "HAIR", "HALE", "HALF", +"HALL", "HALO", "HALT", "HAND", "HANG", "HANK", "HANS", "HARD", +"HARK", "HARM", "HART", "HASH", "HAST", "HATE", "HATH", "HAUL", +"HAVE", "HAWK", "HAYS", "HEAD", "HEAL", "HEAR", "HEAT", "HEBE", + + + +Haller & Metz Standards Track [Page 15] + +RFC 1938 A One-Time Password System May 1996 + + +"HECK", "HEED", "HEEL", "HEFT", "HELD", "HELL", "HELM", "HERB", +"HERD", "HERE", "HERO", "HERS", "HESS", "HEWN", "HICK", "HIDE", +"HIGH", "HIKE", "HILL", "HILT", "HIND", "HINT", "HIRE", "HISS", +"HIVE", "HOBO", "HOCK", "HOFF", "HOLD", "HOLE", "HOLM", "HOLT", +"HOME", "HONE", "HONK", "HOOD", "HOOF", "HOOK", "HOOT", "HORN", +"HOSE", "HOST", "HOUR", "HOVE", "HOWE", "HOWL", "HOYT", "HUCK", +"HUED", "HUFF", "HUGE", "HUGH", "HUGO", "HULK", "HULL", "HUNK", +"HUNT", "HURD", "HURL", "HURT", "HUSH", "HYDE", "HYMN", "IBIS", +"ICON", "IDEA", "IDLE", "IFFY", "INCA", "INCH", "INTO", "IONS", +"IOTA", "IOWA", "IRIS", "IRMA", "IRON", "ISLE", "ITCH", "ITEM", +"IVAN", "JACK", "JADE", "JAIL", "JAKE", "JANE", "JAVA", "JEAN", +"JEFF", "JERK", "JESS", "JEST", "JIBE", "JILL", "JILT", "JIVE", +"JOAN", "JOBS", "JOCK", "JOEL", "JOEY", "JOHN", "JOIN", "JOKE", +"JOLT", "JOVE", "JUDD", "JUDE", "JUDO", "JUDY", "JUJU", "JUKE", +"JULY", "JUNE", "JUNK", "JUNO", "JURY", "JUST", "JUTE", "KAHN", +"KALE", "KANE", "KANT", "KARL", "KATE", "KEEL", "KEEN", "KENO", +"KENT", "KERN", "KERR", "KEYS", "KICK", "KILL", "KIND", "KING", +"KIRK", "KISS", "KITE", "KLAN", "KNEE", "KNEW", "KNIT", "KNOB", +"KNOT", "KNOW", "KOCH", "KONG", "KUDO", "KURD", "KURT", "KYLE", +"LACE", "LACK", "LACY", "LADY", "LAID", "LAIN", "LAIR", "LAKE", +"LAMB", "LAME", "LAND", "LANE", "LANG", "LARD", "LARK", "LASS", +"LAST", "LATE", "LAUD", "LAVA", "LAWN", "LAWS", "LAYS", "LEAD", +"LEAF", "LEAK", "LEAN", "LEAR", "LEEK", "LEER", "LEFT", "LEND", +"LENS", "LENT", "LEON", "LESK", "LESS", "LEST", "LETS", "LIAR", +"LICE", "LICK", "LIED", "LIEN", "LIES", "LIEU", "LIFE", "LIFT", +"LIKE", "LILA", "LILT", "LILY", "LIMA", "LIMB", "LIME", "LIND", +"LINE", "LINK", "LINT", "LION", "LISA", "LIST", "LIVE", "LOAD", +"LOAF", "LOAM", "LOAN", "LOCK", "LOFT", "LOGE", "LOIS", "LOLA", +"LONE", "LONG", "LOOK", "LOON", "LOOT", "LORD", "LORE", "LOSE", +"LOSS", "LOST", "LOUD", "LOVE", "LOWE", "LUCK", "LUCY", "LUGE", +"LUKE", "LULU", "LUND", "LUNG", "LURA", "LURE", "LURK", "LUSH", +"LUST", "LYLE", "LYNN", "LYON", "LYRA", "MACE", "MADE", "MAGI", +"MAID", "MAIL", "MAIN", "MAKE", "MALE", "MALI", "MALL", "MALT", +"MANA", "MANN", "MANY", "MARC", "MARE", "MARK", "MARS", "MART", +"MARY", "MASH", "MASK", "MASS", "MAST", "MATE", "MATH", "MAUL", +"MAYO", "MEAD", "MEAL", "MEAN", "MEAT", "MEEK", "MEET", "MELD", +"MELT", "MEMO", "MEND", "MENU", "MERT", "MESH", "MESS", "MICE", +"MIKE", "MILD", "MILE", "MILK", "MILL", "MILT", "MIMI", "MIND", +"MINE", "MINI", "MINK", "MINT", "MIRE", "MISS", "MIST", "MITE", +"MITT", "MOAN", "MOAT", "MOCK", "MODE", "MOLD", "MOLE", "MOLL", +"MOLT", "MONA", "MONK", "MONT", "MOOD", "MOON", "MOOR", "MOOT", +"MORE", "MORN", "MORT", "MOSS", "MOST", "MOTH", "MOVE", "MUCH", +"MUCK", "MUDD", "MUFF", "MULE", "MULL", "MURK", "MUSH", "MUST", +"MUTE", "MUTT", "MYRA", "MYTH", "NAGY", "NAIL", "NAIR", "NAME", +"NARY", "NASH", "NAVE", "NAVY", "NEAL", "NEAR", "NEAT", "NECK", +"NEED", "NEIL", "NELL", "NEON", "NERO", "NESS", "NEST", "NEWS", +"NEWT", "NIBS", "NICE", "NICK", "NILE", "NINA", "NINE", "NOAH", +"NODE", "NOEL", "NOLL", "NONE", "NOOK", "NOON", "NORM", "NOSE", + + + +Haller & Metz Standards Track [Page 16] + +RFC 1938 A One-Time Password System May 1996 + + +"NOTE", "NOUN", "NOVA", "NUDE", "NULL", "NUMB", "OATH", "OBEY", +"OBOE", "ODIN", "OHIO", "OILY", "OINT", "OKAY", "OLAF", "OLDY", +"OLGA", "OLIN", "OMAN", "OMEN", "OMIT", "ONCE", "ONES", "ONLY", +"ONTO", "ONUS", "ORAL", "ORGY", "OSLO", "OTIS", "OTTO", "OUCH", +"OUST", "OUTS", "OVAL", "OVEN", "OVER", "OWLY", "OWNS", "QUAD", +"QUIT", "QUOD", "RACE", "RACK", "RACY", "RAFT", "RAGE", "RAID", +"RAIL", "RAIN", "RAKE", "RANK", "RANT", "RARE", "RASH", "RATE", +"RAVE", "RAYS", "READ", "REAL", "REAM", "REAR", "RECK", "REED", +"REEF", "REEK", "REEL", "REID", "REIN", "RENA", "REND", "RENT", +"REST", "RICE", "RICH", "RICK", "RIDE", "RIFT", "RILL", "RIME", +"RING", "RINK", "RISE", "RISK", "RITE", "ROAD", "ROAM", "ROAR", +"ROBE", "ROCK", "RODE", "ROIL", "ROLL", "ROME", "ROOD", "ROOF", +"ROOK", "ROOM", "ROOT", "ROSA", "ROSE", "ROSS", "ROSY", "ROTH", +"ROUT", "ROVE", "ROWE", "ROWS", "RUBE", "RUBY", "RUDE", "RUDY", +"RUIN", "RULE", "RUNG", "RUNS", "RUNT", "RUSE", "RUSH", "RUSK", +"RUSS", "RUST", "RUTH", "SACK", "SAFE", "SAGE", "SAID", "SAIL", +"SALE", "SALK", "SALT", "SAME", "SAND", "SANE", "SANG", "SANK", +"SARA", "SAUL", "SAVE", "SAYS", "SCAN", "SCAR", "SCAT", "SCOT", +"SEAL", "SEAM", "SEAR", "SEAT", "SEED", "SEEK", "SEEM", "SEEN", +"SEES", "SELF", "SELL", "SEND", "SENT", "SETS", "SEWN", "SHAG", +"SHAM", "SHAW", "SHAY", "SHED", "SHIM", "SHIN", "SHOD", "SHOE", +"SHOT", "SHOW", "SHUN", "SHUT", "SICK", "SIDE", "SIFT", "SIGH", +"SIGN", "SILK", "SILL", "SILO", "SILT", "SINE", "SING", "SINK", +"SIRE", "SITE", "SITS", "SITU", "SKAT", "SKEW", "SKID", "SKIM", +"SKIN", "SKIT", "SLAB", "SLAM", "SLAT", "SLAY", "SLED", "SLEW", +"SLID", "SLIM", "SLIT", "SLOB", "SLOG", "SLOT", "SLOW", "SLUG", +"SLUM", "SLUR", "SMOG", "SMUG", "SNAG", "SNOB", "SNOW", "SNUB", +"SNUG", "SOAK", "SOAR", "SOCK", "SODA", "SOFA", "SOFT", "SOIL", +"SOLD", "SOME", "SONG", "SOON", "SOOT", "SORE", "SORT", "SOUL", +"SOUR", "SOWN", "STAB", "STAG", "STAN", "STAR", "STAY", "STEM", +"STEW", "STIR", "STOW", "STUB", "STUN", "SUCH", "SUDS", "SUIT", +"SULK", "SUMS", "SUNG", "SUNK", "SURE", "SURF", "SWAB", "SWAG", +"SWAM", "SWAN", "SWAT", "SWAY", "SWIM", "SWUM", "TACK", "TACT", +"TAIL", "TAKE", "TALE", "TALK", "TALL", "TANK", "TASK", "TATE", +"TAUT", "TEAL", "TEAM", "TEAR", "TECH", "TEEM", "TEEN", "TEET", +"TELL", "TEND", "TENT", "TERM", "TERN", "TESS", "TEST", "THAN", +"THAT", "THEE", "THEM", "THEN", "THEY", "THIN", "THIS", "THUD", +"THUG", "TICK", "TIDE", "TIDY", "TIED", "TIER", "TILE", "TILL", +"TILT", "TIME", "TINA", "TINE", "TINT", "TINY", "TIRE", "TOAD", +"TOGO", "TOIL", "TOLD", "TOLL", "TONE", "TONG", "TONY", "TOOK", +"TOOL", "TOOT", "TORE", "TORN", "TOTE", "TOUR", "TOUT", "TOWN", +"TRAG", "TRAM", "TRAY", "TREE", "TREK", "TRIG", "TRIM", "TRIO", +"TROD", "TROT", "TROY", "TRUE", "TUBA", "TUBE", "TUCK", "TUFT", +"TUNA", "TUNE", "TUNG", "TURF", "TURN", "TUSK", "TWIG", "TWIN", +"TWIT", "ULAN", "UNIT", "URGE", "USED", "USER", "USES", "UTAH", +"VAIL", "VAIN", "VALE", "VARY", "VASE", "VAST", "VEAL", "VEDA", +"VEIL", "VEIN", "VEND", "VENT", "VERB", "VERY", "VETO", "VICE", +"VIEW", "VINE", "VISE", "VOID", "VOLT", "VOTE", "WACK", "WADE", + + + +Haller & Metz Standards Track [Page 17] + +RFC 1938 A One-Time Password System May 1996 + + +"WAGE", "WAIL", "WAIT", "WAKE", "WALE", "WALK", "WALL", "WALT", +"WAND", "WANE", "WANG", "WANT", "WARD", "WARM", "WARN", "WART", +"WASH", "WAST", "WATS", "WATT", "WAVE", "WAVY", "WAYS", "WEAK", +"WEAL", "WEAN", "WEAR", "WEED", "WEEK", "WEIR", "WELD", "WELL", +"WELT", "WENT", "WERE", "WERT", "WEST", "WHAM", "WHAT", "WHEE", +"WHEN", "WHET", "WHOA", "WHOM", "WICK", "WIFE", "WILD", "WILL", +"WIND", "WINE", "WING", "WINK", "WINO", "WIRE", "WISE", "WISH", +"WITH", "WOLF", "WONT", "WOOD", "WOOL", "WORD", "WORE", "WORK", +"WORM", "WORN", "WOVE", "WRIT", "WYNN", "YALE", "YANG", "YANK", +"YARD", "YARN", "YAWL", "YAWN", "YEAH", "YEAR", "YELL", "YOGA", +"YOKE" }; + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Haller & Metz Standards Track [Page 18] + diff --git a/RFC/rfc1939.txt b/RFC/rfc1939.txt new file mode 100644 index 00000000..b11350e9 --- /dev/null +++ b/RFC/rfc1939.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 1939 Carnegie Mellon +STD: 53 M. Rose +Obsoletes: 1725 Dover Beach Consulting, Inc. +Category: Standards Track May 1996 + + + Post Office Protocol - Version 3 + +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. + +Table of Contents + + 1. Introduction ................................................ 2 + 2. A Short Digression .......................................... 2 + 3. Basic Operation ............................................. 3 + 4. The AUTHORIZATION State ..................................... 4 + QUIT Command ................................................ 5 + 5. The TRANSACTION State ....................................... 5 + STAT Command ................................................ 6 + LIST Command ................................................ 6 + RETR Command ................................................ 8 + DELE Command ................................................ 8 + NOOP Command ................................................ 9 + RSET Command ................................................ 9 + 6. The UPDATE State ............................................ 10 + QUIT Command ................................................ 10 + 7. Optional POP3 Commands ...................................... 11 + TOP Command ................................................. 11 + UIDL Command ................................................ 12 + USER Command ................................................ 13 + PASS Command ................................................ 14 + APOP Command ................................................ 15 + 8. Scaling and Operational Considerations ...................... 16 + 9. POP3 Command Summary ........................................ 18 + 10. Example POP3 Session ....................................... 19 + 11. Message Format ............................................. 19 + 12. References ................................................. 20 + 13. Security Considerations .................................... 20 + 14. Acknowledgements ........................................... 20 + 15. Authors' Addresses ......................................... 21 + Appendix A. Differences from RFC 1725 .......................... 22 + + + +Myers & Rose Standards Track [Page 1] + +RFC 1939 POP3 May 1996 + + + Appendix B. Command Index ...................................... 23 + +1. Introduction + + On certain types of smaller nodes in the Internet it is often + impractical to maintain a message transport system (MTS). For + example, a workstation may not have sufficient resources (cycles, + disk space) in order to permit a SMTP server [RFC821] and associated + local mail delivery system to be kept resident and continuously + running. Similarly, it may be expensive (or impossible) to keep a + personal computer interconnected to an IP-style network for long + amounts of time (the node is lacking the resource known as + "connectivity"). + + Despite this, it is often very useful to be able to manage mail on + these smaller nodes, and they often support a user agent (UA) to aid + the tasks of mail handling. To solve this problem, a node which can + support an MTS entity offers a maildrop service to these less endowed + nodes. The Post Office Protocol - Version 3 (POP3) is intended to + permit a workstation to dynamically access a maildrop on a server + host in a useful fashion. Usually, this means that the POP3 protocol + is used to allow a workstation to retrieve mail that the server is + holding for it. + + POP3 is not intended to provide extensive manipulation operations of + mail on the server; normally, mail is downloaded and then deleted. A + more advanced (and complex) protocol, IMAP4, is discussed in + [RFC1730]. + + For the remainder of this memo, the term "client host" refers to a + host making use of the POP3 service, while the term "server host" + refers to a host which offers the POP3 service. + +2. A Short Digression + + This memo does not specify how a client host enters mail into the + transport system, although a method consistent with the philosophy of + this memo is presented here: + + When the user agent on a client host wishes to enter a message + into the transport system, it establishes an SMTP connection to + its relay host and sends all mail to it. This relay host could + be, but need not be, the POP3 server host for the client host. Of + course, the relay host must accept mail for delivery to arbitrary + recipient addresses, that functionality is not required of all + SMTP servers. + + + + + +Myers & Rose Standards Track [Page 2] + +RFC 1939 POP3 May 1996 + + +3. Basic Operation + + Initially, the server host starts the POP3 service by listening on + TCP port 110. When a client host wishes to make use of the service, + it establishes a TCP connection with the server host. When the + connection is established, the POP3 server sends a greeting. The + client and POP3 server then exchange commands and responses + (respectively) until the connection is closed or aborted. + + Commands in the POP3 consist of a case-insensitive keyword, possibly + followed by one or more arguments. All commands are terminated by a + CRLF pair. Keywords and arguments consist of printable ASCII + characters. Keywords and arguments are each separated by a single + SPACE character. Keywords are three or four characters long. Each + argument may be up to 40 characters long. + + Responses in the POP3 consist of a status indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. Responses may be up to 512 characters + long, including the terminating CRLF. There are currently two status + indicators: positive ("+OK") and negative ("-ERR"). Servers MUST + send the "+OK" and "-ERR" in upper case. + + Responses to certain commands are multi-line. In these cases, which + are clearly indicated below, after sending the first line of the + response and a CRLF, any additional lines are sent, each terminated + by a CRLF pair. When all lines of the response have been sent, a + final line is sent, consisting of a termination octet (decimal code + 046, ".") and a CRLF pair. If any line of the multi-line response + begins with the termination octet, the line is "byte-stuffed" by + pre-pending the termination octet to that line of the response. + Hence a multi-line response is terminated with the five octets + "CRLF.CRLF". When examining a multi-line response, the client checks + to see if the line begins with the termination octet. If so and if + octets other than CRLF follow, the first octet of the line (the + termination octet) is stripped away. If so and if CRLF immediately + follows the termination character, then the response from the POP + server is ended and the line containing ".CRLF" is not considered + part of the multi-line response. + + A POP3 session progresses through a number of states during its + lifetime. Once the TCP connection has been opened and the POP3 + server has sent the greeting, the session enters the AUTHORIZATION + state. In this state, the client must identify itself to the POP3 + server. Once the client has successfully done this, the server + acquires resources associated with the client's maildrop, and the + session enters the TRANSACTION state. In this state, the client + requests actions on the part of the POP3 server. When the client has + + + +Myers & Rose Standards Track [Page 3] + +RFC 1939 POP3 May 1996 + + + issued the QUIT command, the session enters the UPDATE state. In + this state, the POP3 server releases any resources acquired during + the TRANSACTION state and says goodbye. The TCP connection is then + closed. + + A server MUST respond to an unrecognized, unimplemented, or + syntactically invalid command by responding with a negative status + indicator. A server MUST respond to a command issued when the + session is in an incorrect state by responding with a negative status + indicator. There is no general method for a client to distinguish + between a server which does not implement an optional command and a + server which is unwilling or unable to process the command. + + A POP3 server MAY have an inactivity autologout timer. Such a timer + MUST be of at least 10 minutes' duration. The receipt of any command + from the client during that interval should suffice to reset the + autologout timer. When the timer expires, the session does NOT enter + the UPDATE state--the server should close the TCP connection without + removing any messages or sending any response to the client. + +4. The AUTHORIZATION State + + Once the TCP connection has been opened by a POP3 client, the POP3 + server issues a one line greeting. This can be any positive + response. An example might be: + + S: +OK POP3 server ready + + The POP3 session is now in the AUTHORIZATION state. The client must + now identify and authenticate itself to the POP3 server. Two + possible mechanisms for doing this are described in this document, + the USER and PASS command combination and the APOP command. Both + mechanisms are described later in this document. Additional + authentication mechanisms are described in [RFC1734]. While there is + no single authentication mechanism that is required of all POP3 + servers, a POP3 server must of course support at least one + authentication mechanism. + + Once the POP3 server has determined through the use of any + authentication command that the client should be given access to the + appropriate maildrop, the POP3 server then acquires an exclusive- + access lock on the maildrop, as necessary to prevent messages from + being modified or removed before the session enters the UPDATE state. + If the lock is successfully acquired, the POP3 server responds with a + positive status indicator. The POP3 session now enters the + TRANSACTION state, with no messages marked as deleted. If the + maildrop cannot be opened for some reason (for example, a lock can + not be acquired, the client is denied access to the appropriate + + + +Myers & Rose Standards Track [Page 4] + +RFC 1939 POP3 May 1996 + + + maildrop, or the maildrop cannot be parsed), the POP3 server responds + with a negative status indicator. (If a lock was acquired but the + POP3 server intends to respond with a negative status indicator, the + POP3 server must release the lock prior to rejecting the command.) + After returning a negative status indicator, the server may close the + connection. If the server does not close the connection, the client + may either issue a new authentication command and start again, or the + client may issue the QUIT command. + + After the POP3 server has opened the maildrop, it assigns a message- + number to each message, and notes the size of each message in octets. + The first message in the maildrop is assigned a message-number of + "1", the second is assigned "2", and so on, so that the nth message + in a maildrop is assigned a message-number of "n". In POP3 commands + and responses, all message-numbers and message sizes are expressed in + base-10 (i.e., decimal). + + Here is the summary for the QUIT command when used in the + AUTHORIZATION state: + + QUIT + + Arguments: none + + Restrictions: none + + Possible Responses: + +OK + + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + +5. The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and opened the appropriate maildrop, + the POP3 session is now in the TRANSACTION state. The client may now + issue any of the following POP3 commands repeatedly. After each + command, the POP3 server issues a response. Eventually, the client + issues the QUIT command and the POP3 session enters the UPDATE state. + + + + + + + + + + +Myers & Rose Standards Track [Page 5] + +RFC 1939 POP3 May 1996 + + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + The POP3 server issues a positive response with a line + containing information for the maildrop. This line is + called a "drop listing" for that maildrop. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for drop listings. The + positive response consists of "+OK" followed by a single + space, the number of messages in the maildrop, a single + space, and the size of the maildrop in octets. This memo + makes no requirement on what follows the maildrop size. + Minimal implementations should just end that line of the + response with a CRLF pair. More advanced implementations + may include other information. + + NOTE: This memo STRONGLY discourages implementations + from supplying additional information in the drop + listing. Other, optional, facilities are discussed + later on which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not counted in + either total. + + Possible Responses: + +OK nn mm + + Examples: + C: STAT + S: +OK 2 320 + + + LIST [msg] + + Arguments: + a message-number (optional), which, if present, may NOT + refer to a message marked as deleted + + + + + +Myers & Rose Standards Track [Page 6] + +RFC 1939 POP3 May 1996 + + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If an argument was given and the POP3 server issues a + positive response with a line containing information for + that message. This line is called a "scan listing" for + that message. + + If no argument was given and the POP3 server issues a + positive response, then the response given is multi-line. + After the initial +OK, for each message in the maildrop, + the POP3 server responds with a line containing + information for that message. This line is also called a + "scan listing" for that message. If there are no + messages in the maildrop, then the POP3 server responds + with no scan listings--it issues a positive response + followed by a line containing a termination octet and a + CRLF pair. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. A + scan listing consists of the message-number of the + message, followed by a single space and the exact size of + the message in octets. Methods for calculating the exact + size of the message are described in the "Message Format" + section below. This memo makes no requirement on what + follows the message size in the scan listing. Minimal + implementations should just end that line of the response + with a CRLF pair. More advanced implementations may + include other information, as parsed from the message. + + NOTE: This memo STRONGLY discourages implementations + from supplying additional information in the scan + listing. Other, optional, facilities are discussed + later on which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not listed. + + Possible Responses: + +OK scan listing follows + -ERR no such message + + Examples: + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + + + +Myers & Rose Standards Track [Page 7] + +RFC 1939 POP3 May 1996 + + + S: 2 200 + S: . + ... + C: LIST 2 + S: +OK 2 200 + ... + C: LIST 3 + S: -ERR no such message, only 2 messages in maildrop + + + RETR msg + + Arguments: + a message-number (required) which may NOT refer to a + message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, the + POP3 server sends the message corresponding to the given + message-number, being careful to byte-stuff the termination + character (as with all multi-line responses). + + Possible Responses: + +OK message follows + -ERR no such message + + Examples: + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends the entire message here> + S: . + + + DELE msg + + Arguments: + a message-number (required) which may NOT refer to a + message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state + + + + + + +Myers & Rose Standards Track [Page 8] + +RFC 1939 POP3 May 1996 + + + Discussion: + The POP3 server marks the message as deleted. Any future + reference to the message-number associated with the message + in a POP3 command generates an error. The POP3 server does + not actually delete the message until the POP3 session + enters the UPDATE state. + + Possible Responses: + +OK message deleted + -ERR no such message + + Examples: + C: DELE 1 + S: +OK message 1 deleted + ... + C: DELE 2 + S: -ERR message 2 already deleted + + + NOOP + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + The POP3 server does nothing, it merely replies with a + positive response. + + Possible Responses: + +OK + + Examples: + C: NOOP + S: +OK + + + RSET + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If any messages have been marked as deleted by the POP3 + server, they are unmarked. The POP3 server then replies + + + +Myers & Rose Standards Track [Page 9] + +RFC 1939 POP3 May 1996 + + + with a positive response. + + Possible Responses: + +OK + + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + +6. The UPDATE State + + When the client issues the QUIT command from the TRANSACTION state, + the POP3 session enters the UPDATE state. (Note that if the client + issues the QUIT command from the AUTHORIZATION state, the POP3 + session terminates but does NOT enter the UPDATE state.) + + If a session terminates for some reason other than a client-issued + QUIT command, the POP3 session does NOT enter the UPDATE state and + MUST not remove any messages from the maildrop. + + QUIT + + Arguments: none + + Restrictions: none + + Discussion: + The POP3 server removes all messages marked as deleted + from the maildrop and replies as to the status of this + operation. If there is an error, such as a resource + shortage, encountered while removing messages, the + maildrop may result in having some or none of the messages + marked as deleted be removed. In no case may the server + remove any messages not marked as deleted. + + Whether the removal was successful or not, the server + then releases any exclusive-access lock on the maildrop + and closes the TCP connection. + + Possible Responses: + +OK + -ERR some deleted messages not removed + + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + ... + C: QUIT + + + +Myers & Rose Standards Track [Page 10] + +RFC 1939 POP3 May 1996 + + + S: +OK dewey POP3 server signing off (2 messages left) + ... + +7. Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + implementations of POP3 servers. + + The optional POP3 commands described below permit a POP3 client + greater freedom in message handling, while preserving a simple POP3 + server implementation. + + NOTE: This memo STRONGLY encourages implementations to support + these commands in lieu of developing augmented drop and scan + listings. In short, the philosophy of this memo is to put + intelligence in the part of the POP3 client and not the POP3 + server. + + TOP msg n + + Arguments: + a message-number (required) which may NOT refer to to a + message marked as deleted, and a non-negative number + of lines (required) + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, the + POP3 server sends the headers of the message, the blank + line separating the headers from the body, and then the + number of lines of the indicated message's body, being + careful to byte-stuff the termination character (as with + all multi-line responses). + + Note that if the number of lines requested by the POP3 + client is greater than than the number of lines in the + body, then the POP3 server sends the entire message. + + Possible Responses: + +OK top of message follows + -ERR no such message + + Examples: + C: TOP 1 10 + S: +OK + + + +Myers & Rose Standards Track [Page 11] + +RFC 1939 POP3 May 1996 + + + S: <the POP3 server sends the headers of the + message, a blank line, and the first 10 lines + of the body of the message> + S: . + ... + C: TOP 100 3 + S: -ERR no such message + + + UIDL [msg] + + Arguments: + a message-number (optional), which, if present, may NOT + refer to a message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state. + + Discussion: + If an argument was given and the POP3 server issues a positive + response with a line containing information for that message. + This line is called a "unique-id listing" for that message. + + If no argument was given and the POP3 server issues a positive + response, then the response given is multi-line. After the + initial +OK, for each message in the maildrop, the POP3 server + responds with a line containing information for that message. + This line is called a "unique-id listing" for that message. + + In order to simplify parsing, all POP3 servers are required to + use a certain format for unique-id listings. A unique-id + listing consists of the message-number of the message, + followed by a single space and the unique-id of the message. + No information follows the unique-id in the unique-id listing. + + The unique-id of a message is an arbitrary server-determined + string, consisting of one to 70 characters in the range 0x21 + to 0x7E, which uniquely identifies a message within a + maildrop and which persists across sessions. This + persistence is required even if a session ends without + entering the UPDATE state. The server should never reuse an + unique-id in a given maildrop, for as long as the entity + using the unique-id exists. + + Note that messages marked as deleted are not listed. + + While it is generally preferable for server implementations + to store arbitrarily assigned unique-ids in the maildrop, + + + +Myers & Rose Standards Track [Page 12] + +RFC 1939 POP3 May 1996 + + + this specification is intended to permit unique-ids to be + calculated as a hash of the message. Clients should be able + to handle a situation where two identical copies of a + message in a maildrop have the same unique-id. + + Possible Responses: + +OK unique-id listing follows + -ERR no such message + + Examples: + C: UIDL + S: +OK + S: 1 whqtswO00WBw418f9t5JxYwZ + S: 2 QhdPYR:00WBw1Ph7x7 + S: . + ... + C: UIDL 2 + S: +OK 2 QhdPYR:00WBw1Ph7x7 + ... + C: UIDL 3 + S: -ERR no such message, only 2 messages in maildrop + + + USER name + + Arguments: + a string identifying a mailbox (required), which is of + significance ONLY to the server + + Restrictions: + may only be given in the AUTHORIZATION state after the POP3 + greeting or after an unsuccessful USER or PASS command + + Discussion: + To authenticate using the USER and PASS command + combination, the client must first issue the USER + command. If the POP3 server responds with a positive + status indicator ("+OK"), then the client may issue + either the PASS command to complete the authentication, + or the QUIT command to terminate the POP3 session. If + the POP3 server responds with a negative status indicator + ("-ERR") to the USER command, then the client may either + issue a new authentication command or may issue the QUIT + command. + + The server may return a positive response even though no + such mailbox exists. The server may return a negative + response if mailbox exists, but does not permit plaintext + + + +Myers & Rose Standards Track [Page 13] + +RFC 1939 POP3 May 1996 + + + password authentication. + + Possible Responses: + +OK name is a valid mailbox + -ERR never heard of mailbox name + + Examples: + C: USER frated + S: -ERR sorry, no mailbox for frated here + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + + + PASS string + + Arguments: + a server/mailbox-specific password (required) + + Restrictions: + may only be given in the AUTHORIZATION state immediately + after a successful USER command + + Discussion: + When the client issues the PASS command, the POP3 server + uses the argument pair from the USER and PASS commands to + determine if the client should be given access to the + appropriate maildrop. + + Since the PASS command has exactly one argument, a POP3 + server may treat spaces in the argument as part of the + password, instead of as argument separators. + + Possible Responses: + +OK maildrop locked and ready + -ERR invalid password + -ERR unable to lock maildrop + + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR maildrop already locked + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages (320 octets) + + + +Myers & Rose Standards Track [Page 14] + +RFC 1939 POP3 May 1996 + + + APOP name digest + + Arguments: + a string identifying a mailbox and a MD5 digest string + (both required) + + Restrictions: + may only be given in the AUTHORIZATION state after the POP3 + greeting or after an unsuccessful USER or PASS command + + Discussion: + Normally, each POP3 session starts with a USER/PASS + exchange. This results in a server/user-id specific + password being sent in the clear on the network. For + intermittent use of POP3, this may not introduce a sizable + risk. However, many POP3 client implementations connect to + the POP3 server on a regular basis -- to check for new + mail. Further the interval of session initiation may be on + the order of five minutes. Hence, the risk of password + capture is greatly enhanced. + + An alternate method of authentication is required which + provides for both origin authentication and replay + protection, but which does not involve sending a password + in the clear over the network. The APOP command provides + this functionality. + + A POP3 server which implements the APOP command will + include a timestamp in its banner greeting. The syntax of + the timestamp corresponds to the `msg-id' in [RFC822], and + MUST be different each time the POP3 server issues a banner + greeting. For example, on a UNIX implementation in which a + separate UNIX process is used for each instance of a POP3 + server, the syntax of the timestamp might be: + + <process-ID.clock@hostname> + + where `process-ID' is the decimal value of the process's + PID, clock is the decimal value of the system clock, and + hostname is the fully-qualified domain-name corresponding + to the host where the POP3 server is running. + + The POP3 client makes note of this timestamp, and then + issues the APOP command. The `name' parameter has + identical semantics to the `name' parameter of the USER + command. The `digest' parameter is calculated by applying + the MD5 algorithm [RFC1321] to a string consisting of the + timestamp (including angle-brackets) followed by a shared + + + +Myers & Rose Standards Track [Page 15] + +RFC 1939 POP3 May 1996 + + + secret. This shared secret is a string known only to the + POP3 client and server. Great care should be taken to + prevent unauthorized disclosure of the secret, as knowledge + of the secret will allow any entity to successfully + masquerade as the named user. The `digest' parameter + itself is a 16-octet value which is sent in hexadecimal + format, using lower-case ASCII characters. + + When the POP3 server receives the APOP command, it verifies + the digest provided. If the digest is correct, the POP3 + server issues a positive response, and the POP3 session + enters the TRANSACTION state. Otherwise, a negative + response is issued and the POP3 session remains in the + AUTHORIZATION state. + + Note that as the length of the shared secret increases, so + does the difficulty of deriving it. As such, shared + secrets should be long strings (considerably longer than + the 8-character example shown below). + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + + Examples: + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK maildrop has 1 message (369 octets) + + In this example, the shared secret is the string `tan- + staaf'. Hence, the MD5 algorithm is applied to the string + + <1896.697170952@dbc.mtview.ca.us>tanstaaf + + which produces a digest value of + + c4c9334bac560ecc979e58001b3e22fb + +8. Scaling and Operational Considerations + + Since some of the optional features described above were added to the + POP3 protocol, experience has accumulated in using them in large- + scale commercial post office operations where most of the users are + unrelated to each other. In these situations and others, users and + vendors of POP3 clients have discovered that the combination of using + the UIDL command and not issuing the DELE command can provide a weak + version of the "maildrop as semi-permanent repository" functionality + normally associated with IMAP. Of course the other capabilities of + + + +Myers & Rose Standards Track [Page 16] + +RFC 1939 POP3 May 1996 + + + IMAP, such as polling an existing connection for newly arrived + messages and supporting multiple folders on the server, are not + present in POP3. + + When these facilities are used in this way by casual users, there has + been a tendency for already-read messages to accumulate on the server + without bound. This is clearly an undesirable behavior pattern from + the standpoint of the server operator. This situation is aggravated + by the fact that the limited capabilities of the POP3 do not permit + efficient handling of maildrops which have hundreds or thousands of + messages. + + Consequently, it is recommended that operators of large-scale multi- + user servers, especially ones in which the user's only access to the + maildrop is via POP3, consider such options as: + + * Imposing a per-user maildrop storage quota or the like. + + A disadvantage to this option is that accumulation of messages may + result in the user's inability to receive new ones into the + maildrop. Sites which choose this option should be sure to inform + users of impending or current exhaustion of quota, perhaps by + inserting an appropriate message into the user's maildrop. + + * Enforce a site policy regarding mail retention on the server. + + Sites are free to establish local policy regarding the storage and + retention of messages on the server, both read and unread. For + example, a site might delete unread messages from the server after + 60 days and delete read messages after 7 days. Such message + deletions are outside the scope of the POP3 protocol and are not + considered a protocol violation. + + Server operators enforcing message deletion policies should take + care to make all users aware of the policies in force. + + Clients must not assume that a site policy will automate message + deletions, and should continue to explicitly delete messages using + the DELE command when appropriate. + + It should be noted that enforcing site message deletion policies + may be confusing to the user community, since their POP3 client + may contain configuration options to leave mail on the server + which will not in fact be supported by the server. + + One special case of a site policy is that messages may only be + downloaded once from the server, and are deleted after this has + been accomplished. This could be implemented in POP3 server + + + +Myers & Rose Standards Track [Page 17] + +RFC 1939 POP3 May 1996 + + + software by the following mechanism: "following a POP3 login by a + client which was ended by a QUIT, delete all messages downloaded + during the session with the RETR command". It is important not to + delete messages in the event of abnormal connection termination + (ie, if no QUIT was received from the client) because the client + may not have successfully received or stored the messages. + Servers implementing a download-and-delete policy may also wish to + disable or limit the optional TOP command, since it could be used + as an alternate mechanism to download entire messages. + +9. POP3 Command Summary + + Minimal POP3 Commands: + + USER name valid in the AUTHORIZATION state + PASS string + QUIT + + STAT valid in the TRANSACTION state + LIST [msg] + RETR msg + DELE msg + NOOP + RSET + QUIT + + Optional POP3 Commands: + + APOP name digest valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + UIDL [msg] + + POP3 Replies: + + +OK + -ERR + + Note that with the exception of the STAT, LIST, and UIDL commands, + the reply given by the POP3 server to any command is significant + only to "+OK" and "-ERR". Any text occurring after this reply + may be ignored by the client. + + + + + + + + + +Myers & Rose Standards Track [Page 18] + +RFC 1939 POP3 May 1996 + + +10. Example POP3 Session + + S: <wait for connection on TCP port 110> + C: <open connection> + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK mrose's maildrop has 2 messages (320 octets) + C: STAT + S: +OK 2 320 + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + C: RETR 1 + S: +OK 120 octets + S: <the POP3 server sends message 1> + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: <the POP3 server sends message 2> + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: <close connection> + S: <wait for next connection> + +11. Message Format + + All messages transmitted during a POP3 session are assumed to conform + to the standard for the format of Internet text messages [RFC822]. + + It is important to note that the octet count for a message on the + server host may differ from the octet count assigned to that message + due to local conventions for designating end-of-line. Usually, + during the AUTHORIZATION state of the POP3 session, the POP3 server + can calculate the size of each message in octets when it opens the + maildrop. For example, if the POP3 server host internally represents + end-of-line as a single character, then the POP3 server simply counts + each occurrence of this character in a message as two octets. Note + that lines in the message which start with the termination octet need + not (and must not) be counted twice, since the POP3 client will + remove all byte-stuffed termination characters when it receives a + multi-line response. + + + +Myers & Rose Standards Track [Page 19] + +RFC 1939 POP3 May 1996 + + +12. References + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text + Messages", STD 11, RFC 822, University of Delaware, August 1982. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + MIT Laboratory for Computer Science, April 1992. + + [RFC1730] Crispin, M., "Internet Message Access Protocol - Version + 4", RFC 1730, University of Washington, December 1994. + + [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, + Carnegie Mellon, December 1994. + +13. Security Considerations + + It is conjectured that use of the APOP command provides origin + identification and replay protection for a POP3 session. + Accordingly, a POP3 server which implements both the PASS and APOP + commands should not allow both methods of access for a given user; + that is, for a given mailbox name, either the USER/PASS command + sequence or the APOP command is allowed, but not both. + + Further, note that as the length of the shared secret increases, so + does the difficulty of deriving it. + + Servers that answer -ERR to the USER command are giving potential + attackers clues about which names are valid. + + Use of the PASS command sends passwords in the clear over the + network. + + Use of the RETR and TOP commands sends mail in the clear over the + network. + + Otherwise, security issues are not discussed in this memo. + +14. Acknowledgements + + The POP family has a long and checkered history. Although primarily + a minor revision to RFC 1460, POP3 is based on the ideas presented in + RFCs 918, 937, and 1081. + + In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff + provided significant comments on the APOP command. + + + +Myers & Rose Standards Track [Page 20] + +RFC 1939 POP3 May 1996 + + +15. Authors' Addresses + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave + Pittsburgh, PA 15213 + + EMail: jgm+@cmu.edu + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Mountain View, CA 94043-2186 + + EMail: mrose@dbc.mtview.ca.us + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers & Rose Standards Track [Page 21] + +RFC 1939 POP3 May 1996 + + +Appendix A. Differences from RFC 1725 + + This memo is a revision to RFC 1725, a Draft Standard. It makes the + following changes from that document: + + - clarifies that command keywords are case insensitive. + + - specifies that servers must send "+OK" and "-ERR" in + upper case. + + - specifies that the initial greeting is a positive response, + instead of any string which should be a positive response. + + - clarifies behavior for unimplemented commands. + + - makes the USER and PASS commands optional. + + - clarified the set of possible responses to the USER command. + + - reverses the order of the examples in the USER and PASS + commands, to reduce confusion. + + - clarifies that the PASS command may only be given immediately + after a successful USER command. + + - clarified the persistence requirements of UIDs and added some + implementation notes. + + - specifies a UID length limitation of one to 70 octets. + + - specifies a status indicator length limitation + of 512 octets, including the CRLF. + + - clarifies that LIST with no arguments on an empty mailbox + returns success. + + - adds a reference from the LIST command to the Message Format + section + + - clarifies the behavior of QUIT upon failure + + - clarifies the security section to not imply the use of the + USER command with the APOP command. + + - adds references to RFCs 1730 and 1734 + + - clarifies the method by which a UA may enter mail into the + transport system. + + + +Myers & Rose Standards Track [Page 22] + +RFC 1939 POP3 May 1996 + + + - clarifies that the second argument to the TOP command is a + number of lines. + + - changes the suggestion in the Security Considerations section + for a server to not accept both PASS and APOP for a given user + from a "must" to a "should". + + - adds a section on scaling and operational considerations + +Appendix B. Command Index + + APOP ....................................................... 15 + DELE ....................................................... 8 + LIST ....................................................... 6 + NOOP ....................................................... 9 + PASS ....................................................... 14 + QUIT ....................................................... 5 + QUIT ....................................................... 10 + RETR ....................................................... 8 + RSET ....................................................... 9 + STAT ....................................................... 6 + TOP ........................................................ 11 + UIDL ....................................................... 12 + USER ....................................................... 13 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers & Rose Standards Track [Page 23] + diff --git a/RFC/rfc1985.txt b/RFC/rfc1985.txt new file mode 100644 index 00000000..f49afd75 --- /dev/null +++ b/RFC/rfc1985.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group J. De Winter +Request for Comments: 1985 Wildbear Consulting, Inc. +Category: Standards Track August 1996 + + + SMTP Service Extension + for Remote Message Queue Starting + +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 memo defines an extension to the SMTP service whereby an SMTP + client and server may interact to give the server an opportunity to + start the processing of its queues for messages to go to a given + host. This extension is meant to be used in startup conditions as + well as for mail nodes that have transient connections to their + service providers. + +1. Introduction + + The TURN command was a valid attempt to address the problem of having + to start the processing for the mail queue on a remote machine. + However, the TURN command presents a large security loophole. As + there is no verification of the remote host name, the TURN command + could be used by a rogue system to download the mail for a site other + than itself. + + Therefore, this memo introduces the ETRN command. This command uses + the mechanism defined in [4] to define extensions to the SMTP service + whereby a client ("sender-SMTP") may request that the server + ("receiver-SMTP") start the processing of its mail queues for + messages that are waiting at the server for the client machine. If + any messages are at the server for the client, then the server should + create a new SMTP session and send the messages at that time. + + + + + + + + + + +De Winter Standards Track [Page 1] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + +2. Framework for the ETRN Extension + + The following service extension is therefore defined: + + (1) the name of the SMTP service extension is "Remote Queue + Processing Declaration"; + + (2) the EHLO keyword value associated with this extension is "ETRN", + with no associated parameters; + + (3) one additional verb, ETRN, with a single parameter that + specifies the name of the client(s) to start processing for; + + (4) no additional SMTP verbs are defined by this extension. + + The remainder of this memo specifies how support for the extension + affects the behavior of an SMTP client and server. + +3. The Remote Queue Processing Declaration service extension + + To save money, many small companies want to only maintain transient + connections to their service providers. In addition, there are some + situations where the client sites depend on their mail arriving + quickly, so forcing the queues on the server belonging to their + service provider may be more desirable than waiting for the retry + timeout to occur. + + Both of these situations could currently be fixed using the TURN + command defined in [1], if it were not for a large security loophole + in the TURN command. As it stands, the TURN command will reverse the + direction of the SMTP connection and assume that the remote host is + being honest about what its name is. The security loophole is that + there is no documented stipulation for checking the authenticity of + the remote host name, as given in the HELO or EHLO command. As such, + most SMTP and ESMTP implementations do not implement the TURN command + to avoid this security loophole. + + This has been addressed in the design of the ETRN command. This + extended turn command was written with the points in the first + paragraph in mind, yet paying attention to the problems that + currently exist with the TURN command. The security loophole is + avoided by asking the server to start a new connection aimed at the + specified client. + + In this manner, the server has a lot more certainty that it is + talking to the correct SMTP client. This mechanism can just be seen + as a more immediate version of the retry queues that appear in most + SMTP implementations. In addition, as this command will take a + + + +De Winter Standards Track [Page 2] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + + single parameter, the name of the remote host(s) to start the queues + for, the server can decide whether it wishes to respect the request + or deny it for any local administrative reasons. + +4. Definitions + + Remote queue processing means that using an SMTP or ESMTP connection, + the client may request that the server start to process parts of its + messaging queue. This processing is performed using the existing + SMTP infrastructure and will occur at some point after the processing + is initiated. + + The server host is the node that is responding to the ETRN + command. + + The client host is the node that is initiating the ETRN command. + + The remote host name is defined to be a plain-text field that + specifies a name for the remote host(s). This remote host name may + also include an alias for the specified remote host or special + commands to identify other types of queues. + +5. The extended ETRN command + + The extended ETRN command is issued by the client host when it wishes + to start the SMTP queue processing of a given server host. The + syntax of this command is as follows: + + ETRN [<option character>]<node name><CR><LF> + + This command may be issued at any time once a session is established, + as long as there is not a transaction occuring. Thus, this command + is illegal between a MAIL FROM: command and the end of the DATA + commands and responses. + + The specified node name must be a fully qualified domain name for the + node, which may refer to a CNAME or MX pointer in the DNS. If an + alias is used for the node, multiple ETRN commands may be needed to + start the processing for the node as it may be listed at the remote + site under multiple names. This can also be addressed using the + options discussed in section 5.3. + + The option character under normal circumstances is not used. + + + + + + + + +De Winter Standards Track [Page 3] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + +5.1 Server action on receipt of the extended ETRN command + + When the server host receives the ETRN command, it should have a look + at the node name that is specified in the command and make a local + decision if it should honour the request. If not, the appropriate + error codes should be returned to the client. + + Otherwise, the server host should force its retry queues to start + sending messages to that remote site, using another SMTP connection. + At the moment, there is no requirement that a connection must occur, + or that the connection must occur within a given time frame. This + should be noted in the case where there are no messages for the + client host at the server host and only the 250 response is used. + + Since the processing of the queues may take an indeterminate amount + of time, this command should return immediately with a response to + the client host. The valid return codes for this command are: + + 250 OK, queuing for node <x> started + 251 OK, no messages waiting for node <x> + 252 OK, pending messages for node <x> started + 253 OK, <n> pending messages for node <x> started + 458 Unable to queue messages for node <x> + 459 Node <x> not allowed: <reason> + 500 Syntax Error + 501 Syntax Error in Parameters + + The 250 response code does not indicate that messages will be sent to + the system in question, just that the queue has been started and some + action will occur. If the server is capable of supporting it, the + 251, 252 or 253 response codes should be used to give more + information to the client side. In this case, if there are messages + waiting for the client side node, a check can be performed using + these responses codes as an indication of when there are no more + pending messages in the queue for that node. + + The 458 and 459 result codes should be used to give more information + back to the client host as to why the action was not performed. If + the syntax of the request is not correct, then the 500 and 501 result + codes should be used. + +5.2 Client action on receiving response to extended ETRN command + + If one of the 500 level error codes (550 or 551) are sent, the client + should assume that the protocol is not supported in the remote host + or that the protocol has not been implemented correctly on either the + client or server host. In this case, multiple ETRN commands (dealing + with the aliases for the system) should not be sent. + + + +De Winter Standards Track [Page 4] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + + If the 250 response is received, then the client host can assume that + the server host found its request to be satisfactory and it will send + any queued messages. This process may involve going through a very + large retry queue, and may take some time. + + If the 400 level response is received, then the client can assume + that the server supports the command, but for some local reason does + not want to accept the ETRN command as is. In most cases, it will + mean that there is a list of nodes that it will accept the command + from and the current client is not on that list. The 459 response + code is presented to allow for a more in-depth reason as to why the + remote queuing cannot be started. + +5.3 Use Of ETRN to release mail for a subdomain or queue + + If the requesting server wishes to release all of the mail for a + given subdomain, a variation on the ETRN command can be used. To + perform this request, the option character '@' should be used in + front of the node name. In this manner, any domain names that are + formed with a suffix of the specified node name are released. + + For example, if the command ETRN @foo.com was issued, then any + accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com + may be released. It should be noted that the receiving side of the + ETRN command should make a decision based on the client in question + and only allow certain combinations for each of the nodes. This is + more of a security issue than anything else. + + In a similar vein, it might be necessary under some circumstances to + release a certain queue, where that queue does not correspond to a + given domain name. To this end, the option character '#' can be used + to force the processing of a given queue. In this case, the node + name would be used as a queue name instead, and its syntactical + structure would be dependant on the receiving server. An example of + this would be using the command ETRN #uucp to force the flush of a + UUCP queue. Note that the use of this option is entirely a local + matter and there is no way for a client to find a list of any such + queues that exist. + +6. Minimal usage + + A "minimal" client may use this extension with its host name to start + the queues on the server host. This minimal usage will not handle + cases where mail for 'x.y' is sent to 's.x.y'. + + A minimal server may use this extensions to start the processing of + the queues for all remote sites. In this case, the 458 error + response will not be seen, and it should always return the 250 + + + +De Winter Standards Track [Page 5] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + + response as it will always try and start the processing for any + request. + +7. Example + + The following example illustrates the use of remote queue processing + with some permanent and temporary failures. + + S: <wait for connection on TCP port 25> + C: <open connection to server> + S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992) + C: EHLO ymir.claremont.edu + S: 250-sigurd.innosoft.com + S: 250-EXPN + S: 250-HELP + S: 250 ETRN + C: ETRN + S: 500 Syntax Error + C: ETRN localname + S: 501 Syntax Error in Parameters + C: ETRN uu.net + S: 458 Unable to queue messages for node uu.net + ... + + C: ETRN sigurd.innosoft.com + S: 250 OK, queuing for node sigurd.innosoft.com started + C: ETRN innosoft.com + S: 250 OK, queuing for node innosoft.com started + + OR + + C: ETRN sigurd.innosoft.com + S: 251 OK, no messages waiting for node sigurd.innosoft.com + C: ETRN innosoft.com + S: 252 OK, pending messages for node innosoft.com started + C: ETRN mysoft.com + S: 253 OK, 14 pending messages for node mysoft.com started + + ... + C: ETRN foo.bar + S: 459 Node foo.bar not allowed: Unable to resolve name. + ... + C: QUIT + S: 250 Goodbye + + + + + + + +De Winter Standards Track [Page 6] + +RFC 1985 SMTP Service Extension - ETRN August 1996 + + +8. Security Considerations + + This command does not compromise any security considerations of any + existing SMTP or ESMTP protocols as it merely shortens the time that + a client needs to wait before their messages are retried. + + Precautions should be taken to make sure that any client server can + only use the @ and # option characters for systems that make sense. + Failure to implement some kind of sanity checking on the parameters + could lead to congestion. This would be evident if a person asking + to release @com, which would release mail for any address that ended + with com. + +9. Acknowledgements + + This document was created with lots of support from the users of our + products, who have given some input to the functionality that they + would like to see in the software that they bought. + +10. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, + E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United + Nations University, Innosoft International, Inc., Dover Beach + Consulting, Inc., Network Management Associates, Inc., The Branch + Office, February 1993. + +11. Author's Address + + Jack De Winter + Wildbear Consulting, Inc. + 17 Brock Street + Kitchener, Ontario, Canada + N2M 1X2 + + Phone: +1 519 576 3873 + EMail: jack@wildbear.on.ca + + + + + + + + + + + +De Winter Standards Track [Page 7] + diff --git a/RFC/rfc2033.txt b/RFC/rfc2033.txt new file mode 100644 index 00000000..a47433e8 --- /dev/null +++ b/RFC/rfc2033.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 2033 Carnegie Mellon +Category: Informational October 1996 + + + Local Mail Transfer Protocol + +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 + + SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a + mechanism for transferring mail reliably and efficiently. The design + of the SMTP protocol effectively requires the server to manage a mail + delivery queue. + + In some limited circumstances, outside the area of mail exchange + between independent hosts on public networks, it is desirable to + implement a system where a mail receiver does not manage a queue. + This document describes the LMTP protocol for transporting mail into + such systems. + + Although LMTP is an alternative protocol to ESMTP, it uses (with a + few changes) the syntax and semantics of ESMTP. This design permits + LMTP to utilize the extensions defined for ESMTP. LMTP should be + used only by specific prior arrangement and configuration, and it + MUST NOT be used on TCP port 25. + +Table of Contents + + 1. Abstract ................................................ 1 + 2. Conventions Used in this Document ....................... 2 + 3. Introduction and Overview ............................... 2 + 4. The LMTP protocol ....................................... 3 + 4.1. The LHLO, HELO and EHLO commands ........................ 4 + 4.2. The DATA command ........................................ 4 + 4.3. The BDAT command ........................................ 5 + 5. Implementation requirements ............................. 6 + 6. Acknowledgments ......................................... 6 + 7. References .............................................. 7 + 8. Security Considerations ................................. 7 + 9. Author's Address ........................................ 7 + + + + + +Myers Informational [Page 1] + +RFC 2033 LMTP October 1996 + + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +3. Introduction and Overview + + The design of the SMTP protocol effectively requires the server to + manage a mail delivery queue. This is because a single mail + transaction may specify multiple recipients and the final "." of the + DATA command may return only one reply code, to indicate the status + of the entire transaction. If, for example, a server is given a + transaction for two recipients, delivery to the first succeeds, and + delivery to the second encounters a temporary failure condition, + there is no mechanism to inform the client of the situation. The + server must queue the message and later attempt to deliver it to the + second recipient. + + This queuing requirement is beneficial in the situation for which + SMTP was originally designed: store-and-forward relay of mail between + networked hosts. In some limited situations, it is desirable to have + a server which does not manage a queue, instead relying on the client + to perform queue management. As an example, consider a hypothetical + host with a mail system designed as follows: + + + + TCP port 25 +-----------------+ + ---------------------->| | ######### + | Queue |<># Mail # + TCP port 25 | Manager | # Queue # + <----------------------| | ######### + +-----------------+ + Local * ^ Local * Local + IPC * | IPC * IPC + * | * + * | * + * | * + V | V + Non-SMTP +----------+ +----------+ + Protocol | Gateway | | Local | ######### + <==============>| Delivery | | Delivery |>># Mail # + | Agent | | Agent | # Spool # + +----------+ +----------+ ######### + + + The host's mail system has three independent, communicating + subsystems. The first is a queue manager, which acts as a + + + +Myers Informational [Page 2] + +RFC 2033 LMTP October 1996 + + + traditional SMTP agent, transferring messages to and from other hosts + over TCP and managing a mail queue in persistent storage. The other + two are agents which handle delivery for addresses in domains for + which the host takes responsibility. One agent performs gatewaying + to and from some other mail system. The other agent delivers the + message into a persistent mail spool. + + It would be desirable to use SMTP over a local inter-process + communication channel to transfer messages from the queue manager to + the delivery agents. It would, however, significantly increase the + complexity of the delivery agents to require them to manage their own + mail queues. + + The common practice of invoking a delivery agent with the envelope + address(es) as command-line arguments, then having the delivery agent + communicate status with an exit code has three serious problems: the + agent can only return one exit code to be applied to all recipients, + it is difficult to extend the interface to deal with ESMTP extensions + such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and + exits performed by system libraries due to temporary conditions + frequently get interpreted as permanent errors. + + The LMTP protocol causes the server to return, after the final "." of + the DATA command, one reply for each recipient. Therefore, if the + queue manager is configured to use LMTP instead of SMTP when + transferring messages to the delivery agents, then the delivery + agents may attempt delivery to each recipient after the final "." and + individually report the status for each recipient. Connections which + should use the LMTP protocol are drawn in the diagram above using + asterisks. + + Note that it is not beneficial to use the LMTP protocol when + transferring messages to the queue manager, either from the network + or from a delivery agent. The queue manager does implement a mail + queue, so it may store the message and take responsibility for later + delivering it. + +4. The LMTP protocol + + The LMTP protocol is identical to the SMTP protocol SMTP [SMTP] + [HOST-REQ] with its service extensions [ESMTP], except as modified by + this document. + + A "successful" RCPT command is defined as an RCPT command which + returns a Positive Completion reply code. + + A "Positive Completion reply code" is defined in Appendix E of STD + 10, RFC 821 [SMTP] as a reply code which "2" as the first digit. + + + +Myers Informational [Page 3] + +RFC 2033 LMTP October 1996 + + +4.1. The LHLO, HELO and EHLO commands + + The HELO and EHLO commands of ESMTP are replaced by the LHLO command. + This permits a misconfiguration where both parties are not using the + same protocol to be detected. + + The LHLO command has identical semantics to the EHLO command of ESMTP + [ESMTP]. + + The HELO and EHLO commands of ESMTP are not present in LMTP. A LMTP + server MUST NOT return a Postive Completion reply code to these + commands. The 500 reply code is recommended. + +4.2. The DATA command + + In the LMTP protocol, there is one additional restriction placed on + the DATA command, and one change to how replies to the final "." are + sent. + + The additional restriction is that when there have been no successful + RCPT commands in the mail transaction, the DATA command MUST fail + with a 503 reply code. + + The change is that after the final ".", the server returns one reply + for each previously successful RCPT command in the mail transaction, + in the order that the RCPT commands were issued. Even if there were + multiple successful RCPT commands giving the same forward-path, there + must be one reply for each successful RCPT command. + + When one of these replies to the final "." is a Positive Completion + reply, the server is accepting responsibility for delivering or + relying the message to the corresponding recipient. It must take + this responsibility seriously, i.e., it MUST NOT lose the message for + frivolous reasons, e.g., because the host later crashes or because of + a predictable resource shortage. + + A multiline reply is still considered a single reply and corresponds + to a single RCPT command. + + EXAMPLE: + + S: 220 foo.edu LMTP server ready + C: LHLO foo.edu + S: 250-foo.edu + S: 250-PIPELINING + S: 250 SIZE + C: MAIL FROM:<chris@bar.com> + S: 250 OK + + + +Myers Informational [Page 4] + +RFC 2033 LMTP October 1996 + + + C: RCPT TO:<pat@foo.edu> + S: 250 OK + C: RCPT TO:<jones@foo.edu> + S: 550 No such user here + C: RCPT TO:<green@foo.edu> + S: 250 OK + C: DATA + S: 354 Start mail input; end with <CRLF>.<CRLF> + C: Blah blah blah... + C: ...etc. etc. etc. + C: . + S: 250 OK + S: 452 <green@foo.edu> is temporarily over quota + C: QUIT + S: 221 foo.edu closing connection + + +NOTE: in the above example, the domain names of both the client and + server are identical. This is because in the example the client and + server are different subsystems of the same mail domain. + +4.3. The BDAT command + + If the server supports the ESMTP CHUNKING extension [BINARYMIME], a + BDAT command containing the LAST parameter returns one reply for each + previously successful RCPT command in the mail transaction, in the + order that the RCPT commands were issued. Even if there were + multiple successful RCPT commands giving the same forward-path, there + must be one reply for each successful RCPT command. If there were no + previously successful RCPT commands in the mail transaction, then the + BDAT LAST command returns zero replies. + + When one of these replies to the BDAT LAST command is a Positive + Completion reply, the server is accepting responsibility for + delivering or relaying the message to the corresponding recipient. + It must take this responsibility seriously, i.e., it MUST NOT lose + the message for frivolous reasons, e.g., because the host later + crashes or because of a predictable resource shortage. + + A multiline reply is still considered a single reply and corresponds + to a single RCPT command. + + The behavior of BDAT commands without the LAST parameter is not + changed; they still return exactly one reply. + + + + + + + +Myers Informational [Page 5] + +RFC 2033 LMTP October 1996 + + +5. Implementation requirements + + As LMTP is a different protocol than SMTP, it MUST NOT be used on the + TCP service port 25. + + A server implementation MUST implement the PIPELINING [PIPELINING] + and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions. A + server implementation SHOULD implement the 8BITMIME [8BITMIME] + extension. + + Use of LMTP can aggravate the situation described in [DUP-MSGS]. To + avoid this synchronization problem, the following requirements are + made of implementations: + + A server implementation which is capable of quickly accepting + responsibility for delivering or relaying a message to multiple + recipients and which is capable of sending any necessary notification + messages SHOULD NOT implement the LMTP protocol. + + The LMTP protocol SHOULD NOT be used over wide area networks. + + The server SHOULD send each reply as soon as possible. If it is + going to spend a nontrivial amount of time handling delivery for the + next recipient, it SHOULD flush any outgoing LMTP buffer, so the + reply may be quickly received by the client. + + The client SHOULD process the replies as they come in, instead of + waiting for all of the replies to arrive before processing any of + them. If the connection closes after replies for some, but not all, + recipients have arrived, the client MUST process the replies that + arrived and treat the rest as temporary failures. + +6. Acknowledgments + + This work is a refinement of the MULT extension, which was invented + by Jeff Michaud and was used in implementing gateways to the Mail-11 + mail system. + + Many thanks to Matt Thomas for assisting me in understanding the + semantics of the Mail-11 MULT extension. + + + + + + + + + + + +Myers Informational [Page 6] + +RFC 2033 LMTP October 1996 + + +7. References + + [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME + transport", RFC 1652, July 1994. + + [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission + of Large and Binary MIME Messages", RFC 1830, August 1995. + + [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, January 1996. + + [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047, + February 1988. + + [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for + Returning Enhanced Error Codes", RFC 2034, October 1996. + + [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N., + "SMTP Service Extensions", RFC 1869, November 1995. + + [HOST-REQ] Braden, R., "Requirements for Internet hosts - application + and support", STD 3, RFC 1123 section 5, October 1989. + + [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for + Command Pipelining", RFC 1854, October 1995. + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + + There are no known security issues with the issues in this memo. + +9. Author's Address + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave. + Pittsburgh PA, 15213-3890 + + EMail: jgm+@cmu.edu + + + + + + + + + + + +Myers Informational [Page 7] + diff --git a/RFC/rfc2060.txt b/RFC/rfc2060.txt new file mode 100644 index 00000000..591dec4d --- /dev/null +++ b/RFC/rfc2060.txt @@ -0,0 +1,4595 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 2060 University of Washington +Obsoletes: 1730 December 1996 +Category: Standards Track + + + INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 + +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 Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) + allows a client to access and manipulate electronic mail messages on + a server. IMAP4rev1 permits manipulation of remote message folders, + called "mailboxes", in a way that is functionally equivalent to local + mailboxes. IMAP4rev1 also provides the capability for an offline + client to resynchronize with the server (see also [IMAP-DISC]). + + IMAP4rev1 includes operations for creating, deleting, and renaming + mailboxes; checking for new messages; permanently removing messages; + setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; + searching; and selective fetching of message attributes, texts, and + portions thereof. Messages in IMAP4rev1 are accessed by the use of + numbers. These numbers are either message sequence numbers or unique + identifiers. + + IMAP4rev1 supports a single server. A mechanism for accessing + configuration information to support multiple IMAP4rev1 servers is + discussed in [ACAP]. + + IMAP4rev1 does not specify a means of posting mail; this function is + handled by a mail transfer protocol such as [SMTP]. + + IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and + unpublished IMAP2bis protocols. In the course of the evolution of + IMAP4rev1, some aspects in the earlier protocol have become obsolete. + Obsolete commands, responses, and data formats which an IMAP4rev1 + implementation may encounter when used with an earlier implementation + are described in [IMAP-OBSOLETE]. + + + + + +Crispin Standards Track [Page 1] + +RFC 2060 IMAP4rev1 December 1996 + + + Other compatibility issues with IMAP2bis, the most common variant of + the earlier protocol, are discussed in [IMAP-COMPAT]. A full + discussion of compatibility issues with rare (and presumed extinct) + variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is + primarily of historical interest. + +Table of Contents + +IMAP4rev1 Protocol Specification .................................. 4 +1. How to Read This Document ................................. 4 +1.1. Organization of This Document ............................. 4 +1.2. Conventions Used in This Document ......................... 4 +2. Protocol Overview ......................................... 5 +2.1. Link Level ................................................ 5 +2.2. Commands and Responses .................................... 6 +2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 6 +2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 7 +2.3. Message Attributes ........................................ 7 +2.3.1. Message Numbers ........................................... 7 +2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7 +2.3.1.2. Message Sequence Number Message Attribute ......... 9 +2.3.2. Flags Message Attribute .................................... 9 +2.3.3. Internal Date Message Attribute ........................... 10 +2.3.4. [RFC-822] Size Message Attribute .......................... 11 +2.3.5. Envelope Structure Message Attribute ...................... 11 +2.3.6. Body Structure Message Attribute .......................... 11 +2.4. Message Texts ............................................. 11 +3. State and Flow Diagram .................................... 11 +3.1. Non-Authenticated State ................................... 11 +3.2. Authenticated State ....................................... 11 +3.3. Selected State ............................................ 12 +3.4. Logout State .............................................. 12 +4. Data Formats .............................................. 12 +4.1. Atom ...................................................... 13 +4.2. Number .................................................... 13 +4.3. String ..................................................... 13 +4.3.1. 8-bit and Binary Strings .................................. 13 +4.4. Parenthesized List ........................................ 14 +4.5. NIL ....................................................... 14 +5. Operational Considerations ................................ 14 +5.1. Mailbox Naming ............................................ 14 +5.1.1. Mailbox Hierarchy Naming .................................. 14 +5.1.2. Mailbox Namespace Naming Convention ....................... 14 +5.1.3. Mailbox International Naming Convention ................... 15 +5.2. Mailbox Size and Message Status Updates ................... 16 +5.3. Response when no Command in Progress ...................... 16 +5.4. Autologout Timer .......................................... 16 +5.5. Multiple Commands in Progress ............................. 17 + + + +Crispin Standards Track [Page 2] + +RFC 2060 IMAP4rev1 December 1996 + + +6. Client Commands ........................................... 17 +6.1. Client Commands - Any State ............................... 18 +6.1.1. CAPABILITY Command ........................................ 18 +6.1.2. NOOP Command .............................................. 19 +6.1.3. LOGOUT Command ............................................ 20 +6.2. Client Commands - Non-Authenticated State ................. 20 +6.2.1. AUTHENTICATE Command ...................................... 21 +6.2.2. LOGIN Command ............................................. 22 +6.3. Client Commands - Authenticated State ..................... 22 +6.3.1. SELECT Command ............................................ 23 +6.3.2. EXAMINE Command ........................................... 24 +6.3.3. CREATE Command ............................................ 25 +6.3.4. DELETE Command ............................................ 26 +6.3.5. RENAME Command ............................................ 27 +6.3.6. SUBSCRIBE Command ......................................... 29 +6.3.7. UNSUBSCRIBE Command ....................................... 30 +6.3.8. LIST Command .............................................. 30 +6.3.9. LSUB Command .............................................. 32 +6.3.10. STATUS Command ............................................ 33 +6.3.11. APPEND Command ............................................ 34 +6.4. Client Commands - Selected State .......................... 35 +6.4.1. CHECK Command ............................................. 36 +6.4.2. CLOSE Command ............................................. 36 +6.4.3. EXPUNGE Command ........................................... 37 +6.4.4. SEARCH Command ............................................ 37 +6.4.5. FETCH Command ............................................. 41 +6.4.6. STORE Command ............................................. 45 +6.4.7. COPY Command .............................................. 46 +6.4.8. UID Command ............................................... 47 +6.5. Client Commands - Experimental/Expansion .................. 48 +6.5.1. X<atom> Command ........................................... 48 +7. Server Responses .......................................... 48 +7.1. Server Responses - Status Responses ....................... 49 +7.1.1. OK Response ............................................... 51 +7.1.2. NO Response ............................................... 51 +7.1.3. BAD Response .............................................. 52 +7.1.4. PREAUTH Response .......................................... 52 +7.1.5. BYE Response .............................................. 52 +7.2. Server Responses - Server and Mailbox Status .............. 53 +7.2.1. CAPABILITY Response ....................................... 53 +7.2.2. LIST Response .............................................. 54 +7.2.3. LSUB Response ............................................. 55 +7.2.4 STATUS Response ........................................... 55 +7.2.5. SEARCH Response ........................................... 55 +7.2.6. FLAGS Response ............................................ 56 +7.3. Server Responses - Mailbox Size ........................... 56 +7.3.1. EXISTS Response ........................................... 56 +7.3.2. RECENT Response ........................................... 57 + + + +Crispin Standards Track [Page 3] + +RFC 2060 IMAP4rev1 December 1996 + + +7.4. Server Responses - Message Status ......................... 57 +7.4.1. EXPUNGE Response .......................................... 57 +7.4.2. FETCH Response ............................................ 58 +7.5. Server Responses - Command Continuation Request ........... 63 +8. Sample IMAP4rev1 connection ............................... 63 +9. Formal Syntax ............................................. 64 +10. Author's Note ............................................. 74 +11. Security Considerations ................................... 74 +12. Author's Address .......................................... 75 +Appendices ........................................................ 76 +A. References ................................................ 76 +B. Changes from RFC 1730 ..................................... 77 +C. Key Word Index ............................................ 79 + + +IMAP4rev1 Protocol Specification + +1. How to Read This Document + +1.1. Organization of This Document + + This document is written from the point of view of the implementor of + an IMAP4rev1 client or server. Beyond the protocol overview in + section 2, it is not optimized for someone trying to understand the + operation of the protocol. The material in sections 3 through 5 + provides the general context and definitions with which IMAP4rev1 + operates. + + Sections 6, 7, and 9 describe the IMAP commands, responses, and + syntax, respectively. The relationships among these are such that it + is almost impossible to understand any of them separately. In + particular, do not attempt to deduce command syntax from the command + section alone; instead refer to the Formal Syntax section. + +1.2. Conventions Used in This Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The following terms are used in this document to signify the + requirements of this specification. + + 1) MUST, or the adjective REQUIRED, means that the definition is + an absolute requirement of the specification. + + 2) MUST NOT that the definition is an absolute prohibition of the + specification. + + + + +Crispin Standards Track [Page 4] + +RFC 2060 IMAP4rev1 December 1996 + + + 3) SHOULD means that there may exist valid reasons in particular + circumstances to ignore a particular item, but the full + implications MUST be understood and carefully weighed before + choosing a different course. + + 4) SHOULD NOT means that there may exist valid reasons in + particular circumstances when the particular behavior is + acceptable or even useful, but the full implications SHOULD be + understood and the case carefully weighed before implementing + any behavior described with this label. + + 5) MAY, or the adjective OPTIONAL, means that an item is truly + optional. One vendor may choose to include the item because a + particular marketplace requires it or because the vendor feels + that it enhances the product while another vendor may omit the + same item. An implementation which does not include a + particular option MUST be prepared to interoperate with another + implementation which does include the option. + + "Can" is used instead of "may" when referring to a possible + circumstance or situation, as opposed to an optional facility of + the protocol. + + "User" is used to refer to a human user, whereas "client" refers + to the software being run by the user. + + "Connection" refers to the entire sequence of client/server + interaction from the initial establishment of the network + connection until its termination. "Session" refers to the + sequence of client/server interaction from the time that a mailbox + is selected (SELECT or EXAMINE command) until the time that + selection ends (SELECT or EXAMINE of another mailbox, CLOSE + command, or connection termination). + + Characters are 7-bit US-ASCII unless otherwise specified. Other + character sets are indicated using a "CHARSET", as described in + [MIME-IMT] and defined in [CHARSET]. CHARSETs have important + additional semantics in addition to defining character set; refer + to these documents for more detail. + +2. Protocol Overview + +2.1. Link Level + + The IMAP4rev1 protocol assumes a reliable data stream such as + provided by TCP. When TCP is used, an IMAP4rev1 server listens on + port 143. + + + + +Crispin Standards Track [Page 5] + +RFC 2060 IMAP4rev1 December 1996 + + +2.2. Commands and Responses + + An IMAP4rev1 connection consists of the establishment of a + client/server network connection, an initial greeting from the + server, and client/server interactions. These client/server + interactions consist of a client command, server data, and a server + completion result response. + + All interactions transmitted by client and server are in the form of + lines; that is, strings that end with a CRLF. The protocol receiver + of an IMAP4rev1 client or server is either reading a line, or is + reading a sequence of octets with a known count followed by a line. + +2.2.1. Client Protocol Sender and Server Protocol Receiver + + The client command begins an operation. Each client command is + prefixed with an identifier (typically a short alphanumeric string, + e.g. A0001, A0002, etc.) called a "tag". A different tag is + generated by the client for each command. + + There are two cases in which a line from the client does not + represent a complete command. In one case, a command argument is + quoted with an octet count (see the description of literal in String + under Data Formats); in the other case, the command arguments require + server feedback (see the AUTHENTICATE command). In either case, the + server sends a command continuation request response if it is ready + for the octets (if appropriate) and the remainder of the command. + This response is prefixed with the token "+". + + Note: If, instead, the server detected an error in the command, it + sends a BAD completion response with tag matching the command (as + described below) to reject the command and prevent the client from + sending any more of the command. + + It is also possible for the server to send a completion response + for some other command (if multiple commands are in progress), or + untagged data. In either case, the command continuation request + is still pending; the client takes the appropriate action for the + response, and reads another response from the server. In all + cases, the client MUST send a complete command (including + receiving all command continuation request responses and command + continuations for the command) before initiating a new command. + + The protocol receiver of an IMAP4rev1 server reads a command line + from the client, parses the command and its arguments, and transmits + server data and a server command completion result response. + + + + + +Crispin Standards Track [Page 6] + +RFC 2060 IMAP4rev1 December 1996 + + +2.2.2. Server Protocol Sender and Client Protocol Receiver + + Data transmitted by the server to the client and status responses + that do not indicate command completion are prefixed with the token + "*", and are called untagged responses. + + Server data MAY be sent as a result of a client command, or MAY be + sent unilaterally by the server. There is no syntactic difference + between server data that resulted from a specific command and server + data that were sent unilaterally. + + The server completion result response indicates the success or + failure of the operation. It is tagged with the same tag as the + client command which began the operation. Thus, if more than one + command is in progress, the tag in a server completion response + identifies the command to which the response applies. There are + three possible server completion responses: OK (indicating success), + NO (indicating failure), or BAD (indicating protocol error such as + unrecognized command or command syntax error). + + The protocol receiver of an IMAP4rev1 client reads a response line + from the server. It then takes action on the response based upon the + first token of the response, which can be a tag, a "*", or a "+". + + A client MUST be prepared to accept any server response at all times. + This includes server data that was not requested. Server data SHOULD + be recorded, so that the client can reference its recorded copy + rather than sending a command to the server to request the data. In + the case of certain server data, the data MUST be recorded. + + This topic is discussed in greater detail in the Server Responses + section. + +2.3. Message Attributes + + In addition to message text, each message has several attributes + associated with it. These attributes may be retrieved individually + or in conjunction with other attributes or message texts. + +2.3.1. Message Numbers + + Messages in IMAP4rev1 are accessed by one of two numbers; the unique + identifier and the message sequence number. + +2.3.1.1. Unique Identifier (UID) Message Attribute + + A 32-bit value assigned to each message, which when used with the + unique identifier validity value (see below) forms a 64-bit value + + + +Crispin Standards Track [Page 7] + +RFC 2060 IMAP4rev1 December 1996 + + + that is permanently guaranteed not to refer to any other message in + the mailbox. Unique identifiers are assigned in a strictly ascending + fashion in the mailbox; as each message is added to the mailbox it is + assigned a higher UID than the message(s) which were added + previously. + + Unlike message sequence numbers, unique identifiers are not + necessarily contiguous. Unique identifiers also persist across + sessions. This permits a client to resynchronize its state from a + previous session with the server (e.g. disconnected or offline access + clients); this is discussed further in [IMAP-DISC]. + + Associated with every mailbox is a unique identifier validity value, + which is sent in an UIDVALIDITY response code in an OK untagged + response at mailbox selection time. If unique identifiers from an + earlier session fail to persist to this session, the unique + identifier validity value MUST be greater than the one used in the + earlier session. + + Note: Unique identifiers MUST be strictly ascending in the mailbox + at all times. If the physical message store is re-ordered by a + non-IMAP agent, this requires that the unique identifiers in the + mailbox be regenerated, since the former unique identifers are no + longer strictly ascending as a result of the re-ordering. Another + instance in which unique identifiers are regenerated is if the + message store has no mechanism to store unique identifiers. + Although this specification recognizes that this may be + unavoidable in certain server environments, it STRONGLY ENCOURAGES + message store implementation techniques that avoid this problem. + + Another cause of non-persistance is if the mailbox is deleted and + a new mailbox with the same name is created at a later date, Since + the name is the same, a client may not know that this is a new + mailbox unless the unique identifier validity is different. A + good value to use for the unique identifier validity value is a + 32-bit representation of the creation date/time of the mailbox. + It is alright to use a constant such as 1, but only if it + guaranteed that unique identifiers will never be reused, even in + the case of a mailbox being deleted (or renamed) and a new mailbox + by the same name created at some future time. + + The unique identifier of a message MUST NOT change during the + session, and SHOULD NOT change between sessions. However, if it is + not possible to preserve the unique identifier of a message in a + subsequent session, each subsequent session MUST have a new unique + identifier validity value that is larger than any that was used + previously. + + + + +Crispin Standards Track [Page 8] + +RFC 2060 IMAP4rev1 December 1996 + + +2.3.1.2. Message Sequence Number Message Attribute + + A relative position from 1 to the number of messages in the mailbox. + This position MUST be ordered by ascending unique identifier. As + each new message is added, it is assigned a message sequence number + that is 1 higher than the number of messages in the mailbox before + that new message was added. + + Message sequence numbers can be reassigned during the session. For + example, when a message is permanently removed (expunged) from the + mailbox, the message sequence number for all subsequent messages is + decremented. Similarly, a new message can be assigned a message + sequence number that was once held by some other message prior to an + expunge. + + In addition to accessing messages by relative position in the + mailbox, message sequence numbers can be used in mathematical + calculations. For example, if an untagged "EXISTS 11" is received, + and previously an untagged "8 EXISTS" was received, three new + messages have arrived with message sequence numbers of 9, 10, and 11. + Another example; if message 287 in a 523 message mailbox has UID + 12345, there are exactly 286 messages which have lesser UIDs and 236 + messages which have greater UIDs. + +2.3.2. Flags Message Attribute + + A list of zero or more named tokens associated with the message. A + flag is set by its addition to this list, and is cleared by its + removal. There are two types of flags in IMAP4rev1. A flag of + either type may be permanent or session-only. + + A system flag is a flag name that is pre-defined in this + specification. All system flags begin with "\". Certain system + flags (\Deleted and \Seen) have special semantics described + elsewhere. The currently-defined system flags are: + + \Seen Message has been read + + \Answered Message has been answered + + \Flagged Message is "flagged" for urgent/special attention + + \Deleted Message is "deleted" for removal by later EXPUNGE + + \Draft Message has not completed composition (marked as a + draft). + + + + + +Crispin Standards Track [Page 9] + +RFC 2060 IMAP4rev1 December 1996 + + + \Recent Message is "recently" arrived in this mailbox. This + session is the first session to have been notified + about this message; subsequent sessions will not see + \Recent set for this message. This flag can not be + altered by the client. + + If it is not possible to determine whether or not + this session is the first session to be notified + about a message, then that message SHOULD be + considered recent. + + If multiple connections have the same mailbox + selected simultaneously, it is undefined which of + these connections will see newly-arrives messages + with \Recent set and which will see it without + \Recent set. + + A keyword is defined by the server implementation. Keywords do + not begin with "\". Servers MAY permit the client to define new + keywords in the mailbox (see the description of the + PERMANENTFLAGS response code for more information). + + A flag may be permanent or session-only on a per-flag basis. + Permanent flags are those which the client can add or remove + from the message flags permanently; that is, subsequent sessions + will see any change in permanent flags. Changes to session + flags are valid only in that session. + + Note: The \Recent system flag is a special case of a + session flag. \Recent can not be used as an argument in a + STORE command, and thus can not be changed at all. + +2.3.3. Internal Date Message Attribute + + The internal date and time of the message on the server. This is not + the date and time in the [RFC-822] header, but rather a date and time + which reflects when the message was received. In the case of + messages delivered via [SMTP], this SHOULD be the date and time of + final delivery of the message as defined by [SMTP]. In the case of + messages delivered by the IMAP4rev1 COPY command, this SHOULD be the + internal date and time of the source message. In the case of + messages delivered by the IMAP4rev1 APPEND command, this SHOULD be + the date and time as specified in the APPEND command description. + All other cases are implementation defined. + + + + + + + +Crispin Standards Track [Page 10] + +RFC 2060 IMAP4rev1 December 1996 + + +2.3.4. [RFC-822] Size Message Attribute + + The number of octets in the message, as expressed in [RFC-822] + format. + +2.3.5. Envelope Structure Message Attribute + + A parsed representation of the [RFC-822] envelope information (not to + be confused with an [SMTP] envelope) of the message. + +2.3.6. Body Structure Message Attribute + + A parsed representation of the [MIME-IMB] body structure information + of the message. + +2.4. Message Texts + + In addition to being able to fetch the full [RFC-822] text of a + message, IMAP4rev1 permits the fetching of portions of the full + message text. Specifically, it is possible to fetch the [RFC-822] + message header, [RFC-822] message body, a [MIME-IMB] body part, or a + [MIME-IMB] header. + +3. State and Flow Diagram + + An IMAP4rev1 server is in one of four states. Most commands are + valid in only certain states. It is a protocol error for the client + to attempt a command while the command is in an inappropriate state. + In this case, a server will respond with a BAD or NO (depending upon + server implementation) command completion result. + +3.1. Non-Authenticated State + + In non-authenticated state, the client MUST supply authentication + credentials before most commands will be permitted. This state is + entered when a connection starts unless the connection has been pre- + authenticated. + +3.2. Authenticated State + + In authenticated state, the client is authenticated and MUST select a + mailbox to access before commands that affect messages will be + permitted. This state is entered when a pre-authenticated connection + starts, when acceptable authentication credentials have been + provided, or after an error in selecting a mailbox. + + + + + + +Crispin Standards Track [Page 11] + +RFC 2060 IMAP4rev1 December 1996 + + +3.3. Selected State + + In selected state, a mailbox has been selected to access. This state + is entered when a mailbox has been successfully selected. + +3.4. Logout State + + In logout state, the connection is being terminated, and the server + will close the connection. This state can be entered as a result of + a client request or by unilateral server decision. + + +--------------------------------------+ + |initial connection and server greeting| + +--------------------------------------+ + || (1) || (2) || (3) + VV || || + +-----------------+ || || + |non-authenticated| || || + +-----------------+ || || + || (7) || (4) || || + || VV VV || + || +----------------+ || + || | authenticated |<=++ || + || +----------------+ || || + || || (7) || (5) || (6) || + || || VV || || + || || +--------+ || || + || || |selected|==++ || + || || +--------+ || + || || || (7) || + VV VV VV VV + +--------------------------------------+ + | logout and close connection | + +--------------------------------------+ + + (1) connection without pre-authentication (OK greeting) + (2) pre-authenticated connection (PREAUTH greeting) + (3) rejected connection (BYE greeting) + (4) successful LOGIN or AUTHENTICATE command + (5) successful SELECT or EXAMINE command + (6) CLOSE command, or failed SELECT or EXAMINE command + (7) LOGOUT command, server shutdown, or connection closed + +4. Data Formats + + IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can + be in one of several forms: atom, number, string, parenthesized list, + or NIL. + + + +Crispin Standards Track [Page 12] + +RFC 2060 IMAP4rev1 December 1996 + + +4.1. Atom + + An atom consists of one or more non-special characters. + +4.2. Number + + A number consists of one or more digit characters, and represents a + numeric value. + +4.3. String + + A string is in one of two forms: literal and quoted string. The + literal form is the general form of string. The quoted string form + is an alternative that avoids the overhead of processing a literal at + the cost of limitations of characters that can be used in a quoted + string. + + A literal is a sequence of zero or more octets (including CR and LF), + prefix-quoted with an octet count in the form of an open brace ("{"), + the number of octets, close brace ("}"), and CRLF. In the case of + literals transmitted from server to client, the CRLF is immediately + followed by the octet data. In the case of literals transmitted from + client to server, the client MUST wait to receive a command + continuation request (described later in this document) before + sending the octet data (and the remainder of the command). + + A quoted string is a sequence of zero or more 7-bit characters, + excluding CR and LF, with double quote (<">) characters at each end. + + The empty string is represented as either "" (a quoted string with + zero characters between double quotes) or as {0} followed by CRLF (a + literal with an octet count of 0). + + Note: Even if the octet count is 0, a client transmitting a + literal MUST wait to receive a command continuation request. + +4.3.1. 8-bit and Binary Strings + + 8-bit textual and binary mail is supported through the use of a + [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY + transmit 8-bit or multi-octet characters in literals, but SHOULD do + so only when the [CHARSET] is identified. + + + + + + + + + +Crispin Standards Track [Page 13] + +RFC 2060 IMAP4rev1 December 1996 + + + Although a BINARY body encoding is defined, unencoded binary strings + are not permitted. A "binary string" is any string with NUL + characters. Implementations MUST encode binary data into a textual + form such as BASE64 before transmitting the data. A string with an + excessive amount of CTL characters MAY also be considered to be + binary. + +4.4. Parenthesized List + + Data structures are represented as a "parenthesized list"; a sequence + of data items, delimited by space, and bounded at each end by + parentheses. A parenthesized list can contain other parenthesized + lists, using multiple levels of parentheses to indicate nesting. + + The empty list is represented as () -- a parenthesized list with no + members. + +4.5. NIL + + The special atom "NIL" represents the non-existence of a particular + data item that is represented as a string or parenthesized list, as + distinct from the empty string "" or the empty parenthesized list (). + +5. Operational Considerations + +5.1. Mailbox Naming + + The interpretation of mailbox names is implementation-dependent. + However, the case-insensitive mailbox name INBOX is a special name + reserved to mean "the primary mailbox for this user on this server". + +5.1.1. Mailbox Hierarchy Naming + + If it is desired to export hierarchical mailbox names, mailbox names + MUST be left-to-right hierarchical using a single character to + separate levels of hierarchy. The same hierarchy separator character + is used for all levels of hierarchy within a single name. + +5.1.2. Mailbox Namespace Naming Convention + + By convention, the first hierarchical element of any mailbox name + which begins with "#" identifies the "namespace" of the remainder of + the name. This makes it possible to disambiguate between different + types of mailbox stores, each of which have their own namespaces. + + + + + + + +Crispin Standards Track [Page 14] + +RFC 2060 IMAP4rev1 December 1996 + + + For example, implementations which offer access to USENET + newsgroups MAY use the "#news" namespace to partition the USENET + newsgroup namespace from that of other mailboxes. Thus, the + comp.mail.misc newsgroup would have an mailbox name of + "#news.comp.mail.misc", and the name "comp.mail.misc" could refer + to a different object (e.g. a user's private mailbox). + +5.1.3. Mailbox International Naming Convention + + By convention, international mailbox names are specified using a + modified version of the UTF-7 encoding described in [UTF-7]. The + purpose of these modifications is to correct the following problems + with UTF-7: + + 1) UTF-7 uses the "+" character for shifting; this conflicts with + the common use of "+" in mailbox names, in particular USENET + newsgroup names. + + 2) UTF-7's encoding is BASE64 which uses the "/" character; this + conflicts with the use of "/" as a popular hierarchy delimiter. + + 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with + the use of "\" as a popular hierarchy delimiter. + + 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with + the use of "~" in some servers as a home directory indicator. + + 5) UTF-7 permits multiple alternate forms to represent the same + string; in particular, printable US-ASCII chararacters can be + represented in encoded form. + + In modified UTF-7, printable US-ASCII characters except for "&" + represent themselves; that is, characters with octet values 0x20-0x25 + and 0x27-0x7e. The character "&" (0x26) is represented by the two- + octet sequence "&-". + + All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all + Unicode 16-bit octets) are represented in modified BASE64, with a + further modification from [UTF-7] that "," is used instead of "/". + Modified BASE64 MUST NOT be used to represent any printing US-ASCII + character which can represent itself. + + "&" is used to shift to modified BASE64 and "-" to shift back to US- + ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that + is, a name that ends with a Unicode 16-bit octet MUST end with a "- + "). + + + + + +Crispin Standards Track [Page 15] + +RFC 2060 IMAP4rev1 December 1996 + + + For example, here is a mailbox name which mixes English, Japanese, + and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw- + +5.2. Mailbox Size and Message Status Updates + + At any time, a server can send data that the client did not request. + Sometimes, such behavior is REQUIRED. For example, agents other than + the server MAY add messages to the mailbox (e.g. new mail delivery), + change the flags of message in the mailbox (e.g. simultaneous access + to the same mailbox by multiple agents), or even remove messages from + the mailbox. A server MUST send mailbox size updates automatically + if a mailbox size change is observed during the processing of a + command. A server SHOULD send message flag updates automatically, + without requiring the client to request such updates explicitly. + Special rules exist for server notification of a client about the + removal of messages to prevent synchronization errors; see the + description of the EXPUNGE response for more detail. + + Regardless of what implementation decisions a client makes on + remembering data from the server, a client implementation MUST record + mailbox size updates. It MUST NOT assume that any command after + initial mailbox selection will return the size of the mailbox. + +5.3. Response when no Command in Progress + + Server implementations are permitted to send an untagged response + (except for EXPUNGE) while there is no command in progress. Server + implementations that send such responses MUST deal with flow control + considerations. Specifically, they MUST either (1) verify that the + size of the data does not exceed the underlying transport's available + window size, or (2) use non-blocking writes. + +5.4. Autologout Timer + + If a server has an inactivity autologout timer, that timer MUST be of + at least 30 minutes' duration. The receipt of ANY command from the + client during that interval SHOULD suffice to reset the autologout + timer. + + + + + + + + + + + + + +Crispin Standards Track [Page 16] + +RFC 2060 IMAP4rev1 December 1996 + + +5.5. Multiple Commands in Progress + + The client MAY send another command without waiting for the + completion result response of a command, subject to ambiguity rules + (see below) and flow control constraints on the underlying data + stream. Similarly, a server MAY begin processing another command + before processing the current command to completion, subject to + ambiguity rules. However, any command continuation request responses + and command continuations MUST be negotiated before any subsequent + command is initiated. + + The exception is if an ambiguity would result because of a command + that would affect the results of other commands. Clients MUST NOT + send multiple commands without waiting if an ambiguity would result. + If the server detects a possible ambiguity, it MUST execute commands + to completion in the order given by the client. + + The most obvious example of ambiguity is when a command would affect + the results of another command; for example, a FETCH of a message's + flags and a STORE of that same message's flags. + + A non-obvious ambiguity occurs with commands that permit an untagged + EXPUNGE response (commands other than FETCH, STORE, and SEARCH), + since an untagged EXPUNGE response can invalidate sequence numbers in + a subsequent command. This is not a problem for FETCH, STORE, or + SEARCH commands because servers are prohibited from sending EXPUNGE + responses while any of those commands are in progress. Therefore, if + the client sends any command other than FETCH, STORE, or SEARCH, it + MUST wait for a response before sending a command with message + sequence numbers. + + For example, the following non-waiting command sequences are invalid: + + FETCH + NOOP + STORE + STORE + COPY + FETCH + COPY + COPY + CHECK + FETCH + + The following are examples of valid non-waiting command sequences: + + FETCH + STORE + SEARCH + CHECK + STORE + COPY + EXPUNGE + +6. Client Commands + + IMAP4rev1 commands are described in this section. Commands are + organized by the state in which the command is permitted. Commands + which are permitted in multiple states are listed in the minimum + + + +Crispin Standards Track [Page 17] + +RFC 2060 IMAP4rev1 December 1996 + + + permitted state (for example, commands valid in authenticated and + selected state are listed in the authenticated state commands). + + Command arguments, identified by "Arguments:" in the command + descriptions below, are described by function, not by syntax. The + precise syntax of command arguments is described in the Formal Syntax + section. + + Some commands cause specific server responses to be returned; these + are identified by "Responses:" in the command descriptions below. + See the response descriptions in the Responses section for + information on these responses, and the Formal Syntax section for the + precise syntax of these responses. It is possible for server data to + be transmitted as a result of any command; thus, commands that do not + specifically require server data specify "no specific responses for + this command" instead of "none". + + The "Result:" in the command description refers to the possible + tagged status responses to a command, and any special interpretation + of these status responses. + +6.1. Client Commands - Any State + + The following commands are valid in any state: CAPABILITY, NOOP, and + LOGOUT. + +6.1.1. CAPABILITY Command + + Arguments: none + + Responses: REQUIRED untagged response: CAPABILITY + + Result: OK - capability completed + BAD - command unknown or arguments invalid + + The CAPABILITY command requests a listing of capabilities that the + server supports. The server MUST send a single untagged + CAPABILITY response with "IMAP4rev1" as one of the listed + capabilities before the (tagged) OK response. This listing of + capabilities is not dependent upon connection state or user. It + is therefore not necessary to issue a CAPABILITY command more than + once in a connection. + + + + + + + + + +Crispin Standards Track [Page 18] + +RFC 2060 IMAP4rev1 December 1996 + + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. All + such names are, by definition, part of this specification. For + example, the authorization capability for an experimental + "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not + "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". + + Other capability names refer to extensions, revisions, or + amendments to this specification. See the documentation of the + CAPABILITY response for additional information. No capabilities, + beyond the base IMAP4rev1 set defined in this specification, are + enabled without explicit client action to invoke the capability. + + See the section entitled "Client Commands - + Experimental/Expansion" for information about the form of site or + implementation-specific capabilities. + + Example: C: abcd CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 + S: abcd OK CAPABILITY completed + +6.1.2. NOOP Command + + Arguments: none + + Responses: no specific responses for this command (but see below) + + Result: OK - noop completed + BAD - command unknown or arguments invalid + + The NOOP command always succeeds. It does nothing. + + Since any command can return a status update as untagged data, the + NOOP command can be used as a periodic poll for new messages or + message status updates during a period of inactivity. The NOOP + command can also be used to reset any inactivity autologout timer + on the server. + + Example: C: a002 NOOP + S: a002 OK NOOP completed + . . . + C: a047 NOOP + S: * 22 EXPUNGE + S: * 23 EXISTS + S: * 3 RECENT + S: * 14 FETCH (FLAGS (\Seen \Deleted)) + S: a047 OK NOOP completed + + + + +Crispin Standards Track [Page 19] + +RFC 2060 IMAP4rev1 December 1996 + + +6.1.3. LOGOUT Command + + Arguments: none + + Responses: REQUIRED untagged response: BYE + + Result: OK - logout completed + BAD - command unknown or arguments invalid + + The LOGOUT command informs the server that the client is done with + the connection. The server MUST send a BYE untagged response + before the (tagged) OK response, and then close the network + connection. + + Example: C: A023 LOGOUT + S: * BYE IMAP4rev1 Server logging out + S: A023 OK LOGOUT completed + (Server and client then close the connection) + +6.2. Client Commands - Non-Authenticated State + + In non-authenticated state, the AUTHENTICATE or LOGIN command + establishes authentication and enter authenticated state. The + AUTHENTICATE command provides a general mechanism for a variety of + authentication techniques, whereas the LOGIN command uses the + traditional user name and plaintext password pair. + + Server implementations MAY allow non-authenticated access to certain + mailboxes. The convention is to use a LOGIN command with the userid + "anonymous". A password is REQUIRED. It is implementation-dependent + what requirements, if any, are placed on the password and what access + restrictions are placed on anonymous users. + + Once authenticated (including as anonymous), it is not possible to + re-enter non-authenticated state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in non-authenticated state: + AUTHENTICATE and LOGIN. + + + + + + + + + + + + +Crispin Standards Track [Page 20] + +RFC 2060 IMAP4rev1 December 1996 + + +6.2.1. AUTHENTICATE Command + + Arguments: authentication mechanism name + + Responses: continuation data can be requested + + Result: OK - authenticate completed, now in authenticated state + NO - authenticate failure: unsupported authentication + mechanism, credentials rejected + BAD - command unknown or arguments invalid, + authentication exchange cancelled + + The AUTHENTICATE command indicates an authentication mechanism, + such as described in [IMAP-AUTH], to the server. If the server + supports the requested authentication mechanism, it performs an + authentication protocol exchange to authenticate and identify the + client. It MAY also negotiate an OPTIONAL protection mechanism + for subsequent protocol interactions. If the requested + authentication mechanism is not supported, the server SHOULD + reject the AUTHENTICATE command by sending a tagged NO 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 consists of a + command continuation request response with the "+" token followed + by a BASE64 encoded string. The client answer consists of a line + consisting of a BASE64 encoded string. If the client wishes to + cancel an authentication exchange, it issues a line with a single + "*". If the server receives such an answer, it MUST reject the + AUTHENTICATE command by sending a tagged BAD response. + + A protection mechanism provides integrity and privacy protection + to the connection. 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 tagged OK 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. + + Authentication mechanisms are OPTIONAL. Protection mechanisms are + also OPTIONAL; an authentication mechanism MAY be implemented + without any protection mechanism. If an AUTHENTICATE command + fails with a NO response, the client MAY try another + + + +Crispin Standards Track [Page 21] + +RFC 2060 IMAP4rev1 December 1996 + + + authentication mechanism by issuing another AUTHENTICATE command, + or MAY attempt to authenticate by using the LOGIN command. In + other words, the client MAY request authentication types in + decreasing order of preference, with the LOGIN command as a last + resort. + + Example: S: * OK KerberosV4 IMAP4rev1 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + Note: the line breaks in the first client answer are for editorial + clarity and are not in real authenticators. + +6.2.2. LOGIN Command + + Arguments: user name + password + + Responses: no specific responses for this command + + Result: OK - login completed, now in authenticated state + NO - login failure: user name or password rejected + BAD - command unknown or arguments invalid + + The LOGIN command identifies the client to the server and carries + the plaintext password authenticating this user. + + Example: C: a001 LOGIN SMITH SESAME + S: a001 OK LOGIN completed + +6.3. Client Commands - Authenticated State + + In authenticated state, commands that manipulate mailboxes as atomic + entities are permitted. Of these commands, the SELECT and EXAMINE + commands will select a mailbox for access and enter selected state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in authenticated state: SELECT, + EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, + STATUS, and APPEND. + + + + + +Crispin Standards Track [Page 22] + +RFC 2060 IMAP4rev1 December 1996 + + +6.3.1. SELECT Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - select completed, now in selected state + NO - select failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The SELECT command selects a mailbox so that messages in the + mailbox can be accessed. Before returning an OK to the client, + the server MUST send the following untagged data to the client: + + FLAGS Defined flags in the mailbox. See the description + of the FLAGS response for more detail. + + <n> EXISTS The number of messages in the mailbox. See the + description of the EXISTS response for more detail. + + <n> RECENT The number of messages with the \Recent flag set. + See the description of the RECENT response for more + detail. + + OK [UIDVALIDITY <n>] + The unique identifier validity value. See the + description of the UID command for more detail. + + to define the initial state of the mailbox at the client. + + The server SHOULD also send an UNSEEN response code in an OK + untagged response, indicating the message sequence number of the + first unseen message in the mailbox. + + If the client can not change the permanent state of one or more of + the flags listed in the FLAGS untagged response, the server SHOULD + send a PERMANENTFLAGS response code in an OK untagged response, + listing the flags that the client can change permanently. + + Only one mailbox can be selected at a time in a connection; + simultaneous access to multiple mailboxes requires multiple + connections. The SELECT command automatically deselects any + currently selected mailbox before attempting the new selection. + Consequently, if a mailbox is selected and a SELECT command that + fails is attempted, no mailbox is selected. + + + + +Crispin Standards Track [Page 23] + +RFC 2060 IMAP4rev1 December 1996 + + + If the client is permitted to modify the mailbox, the server + SHOULD prefix the text of the tagged OK response with the + "[READ-WRITE]" response code. + + If the client is not permitted to modify the mailbox but is + permitted read access, the mailbox is selected as read-only, and + the server MUST prefix the text of the tagged OK response to + SELECT with the "[READ-ONLY]" response code. Read-only access + through SELECT differs from the EXAMINE command in that certain + read-only mailboxes MAY permit the change of permanent state on a + per-user (as opposed to global) basis. Netnews messages marked in + a server-based .newsrc file are an example of such per-user + permanent state that can be modified with read-only mailboxes. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: A142 OK [READ-WRITE] SELECT completed + +6.3.2. EXAMINE Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - examine completed, now in selected state + NO - examine failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The EXAMINE command is identical to SELECT and returns the same + output; however, the selected mailbox is identified as read-only. + No changes to the permanent state of the mailbox, including + per-user state, are permitted. + + + + + + + + + + + + +Crispin Standards Track [Page 24] + +RFC 2060 IMAP4rev1 December 1996 + + + The text of the tagged OK response to the EXAMINE command MUST + begin with the "[READ-ONLY]" response code. + + Example: C: A932 EXAMINE blurdybloop + S: * 17 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 8] Message 8 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS ()] No permanent flags permitted + S: A932 OK [READ-ONLY] EXAMINE completed + +6.3.3. CREATE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - create completed + NO - create failure: can't create mailbox with that name + BAD - command unknown or arguments invalid + + The CREATE command creates a mailbox with the given name. An OK + response is returned only if a new mailbox with that name has been + created. It is an error to attempt to create INBOX or a mailbox + with a name that refers to an extant mailbox. Any error in + creation will return a tagged NO response. + + If the mailbox name is suffixed with the server's hierarchy + separator character (as returned from the server by a LIST + command), this is a declaration that the client intends to create + mailbox names under this name in the hierarchy. Server + implementations that do not require this declaration MUST ignore + it. + + If the server's hierarchy separator character appears elsewhere in + the name, the server SHOULD create any superior hierarchical names + that are needed for the CREATE command to complete successfully. + In other words, an attempt to create "foo/bar/zap" on a server in + which "/" is the hierarchy separator character SHOULD create foo/ + and foo/bar/ if they do not already exist. + + If a new mailbox is created with the same name as a mailbox which + was deleted, its unique identifiers MUST be greater than any + unique identifiers used in the previous incarnation of the mailbox + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + + +Crispin Standards Track [Page 25] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A003 CREATE owatagusiam/ + S: A003 OK CREATE completed + C: A004 CREATE owatagusiam/blurdybloop + S: A004 OK CREATE completed + + Note: the interpretation of this example depends on whether "/" + was returned as the hierarchy separator from LIST. If "/" is the + hierarchy separator, a new level of hierarchy named "owatagusiam" + with a member called "blurdybloop" is created. Otherwise, two + mailboxes at the same hierarchy level are created. + +6.3.4. DELETE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - delete completed + NO - delete failure: can't delete mailbox with that name + BAD - command unknown or arguments invalid + + The DELETE command permanently removes the mailbox with the given + name. A tagged OK response is returned only if the mailbox has + been deleted. It is an error to attempt to delete INBOX or a + mailbox name that does not exist. + + The DELETE command MUST NOT remove inferior hierarchical names. + For example, if a mailbox "foo" has an inferior "foo.bar" + (assuming "." is the hierarchy delimiter character), removing + "foo" MUST NOT remove "foo.bar". It is an error to attempt to + delete a name that has inferior hierarchical names and also has + the \Noselect mailbox name attribute (see the description of the + LIST response for more details). + + It is permitted to delete a name that has inferior hierarchical + names and does not have the \Noselect mailbox name attribute. In + this case, all messages in that mailbox are removed, and the name + will acquire the \Noselect mailbox name attribute. + + The value of the highest-used unique identifier of the deleted + mailbox MUST be preserved so that a new mailbox created with the + same name will not reuse the identifiers of the former + incarnation, UNLESS the new incarnation has a different unique + identifier validity value. See the description of the UID command + for more detail. + + + + + + +Crispin Standards Track [Page 26] + +RFC 2060 IMAP4rev1 December 1996 + + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 DELETE blurdybloop + S: A683 OK DELETE completed + C: A684 DELETE foo + S: A684 NO Name "foo" has inferior hierarchical names + C: A685 DELETE foo/bar + S: A685 OK DELETE Completed + C: A686 LIST "" * + S: * LIST (\Noselect) "/" foo + S: A686 OK LIST completed + C: A687 DELETE foo + S: A687 OK DELETE Completed + + + C: A82 LIST "" * + S: * LIST () "." blurdybloop + S: * LIST () "." foo + S: * LIST () "." foo.bar + S: A82 OK LIST completed + C: A83 DELETE blurdybloop + S: A83 OK DELETE completed + C: A84 DELETE foo + S: A84 OK DELETE Completed + C: A85 LIST "" * + S: * LIST () "." foo.bar + S: A85 OK LIST completed + C: A86 LIST "" % + S: * LIST (\Noselect) "." foo + S: A86 OK LIST completed + +6.3.5. RENAME Command + + Arguments: existing mailbox name + new mailbox name + + Responses: no specific responses for this command + + Result: OK - rename completed + NO - rename failure: can't rename mailbox with that name, + can't rename to mailbox with that name + BAD - command unknown or arguments invalid + + The RENAME command changes the name of a mailbox. A tagged OK + response is returned only if the mailbox has been renamed. It is + + + +Crispin Standards Track [Page 27] + +RFC 2060 IMAP4rev1 December 1996 + + + an error to attempt to rename from a mailbox name that does not + exist or to a mailbox name that already exists. Any error in + renaming will return a tagged NO response. + + If the name has inferior hierarchical names, then the inferior + hierarchical names MUST also be renamed. For example, a rename of + "foo" to "zap" will rename "foo/bar" (assuming "/" is the + hierarchy delimiter character) to "zap/bar". + + The value of the highest-used unique identifier of the old mailbox + name MUST be preserved so that a new mailbox created with the same + name will not reuse the identifiers of the former incarnation, + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + Renaming INBOX is permitted, and has special behavior. It moves + all messages in INBOX to a new mailbox with the given name, + leaving INBOX empty. If the server implementation supports + inferior hierarchical names of INBOX, these are unaffected by a + rename of INBOX. + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 RENAME blurdybloop sarasoop + S: A683 OK RENAME completed + C: A684 RENAME foo zowie + S: A684 OK RENAME Completed + C: A685 LIST "" * + S: * LIST () "/" sarasoop + S: * LIST (\Noselect) "/" zowie + S: * LIST () "/" zowie/bar + S: A685 OK LIST completed + + + + + + + + + + + + + + + +Crispin Standards Track [Page 28] + +RFC 2060 IMAP4rev1 December 1996 + + + C: Z432 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: Z432 OK LIST completed + C: Z433 RENAME INBOX old-mail + S: Z433 OK RENAME completed + C: Z434 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: * LIST () "." old-mail + S: Z434 OK LIST completed + +6.3.6. SUBSCRIBE Command + + Arguments: mailbox + + Responses: no specific responses for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE command adds the specified mailbox name to the + server's set of "active" or "subscribed" mailboxes as returned by + the LSUB command. This command returns a tagged OK response only + if the subscription is successful. + + A server MAY validate the mailbox argument to SUBSCRIBE to verify + that it exists. However, it MUST NOT unilaterally remove an + existing mailbox name from the subscription list even if a mailbox + by that name no longer exists. + + Note: this requirement is because some server sites may routinely + remove a mailbox with a well-known name (e.g. "system-alerts") + after its contents expire, with the intention of recreating it + when new contents are appropriate. + + Example: C: A002 SUBSCRIBE #news.comp.mail.mime + S: A002 OK SUBSCRIBE completed + + + + + + + + + + + + +Crispin Standards Track [Page 29] + +RFC 2060 IMAP4rev1 December 1996 + + +6.3.7. UNSUBSCRIBE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE command removes the specified mailbox name from + the server's set of "active" or "subscribed" mailboxes as returned + by the LSUB command. This command returns a tagged OK response + only if the unsubscription is successful. + + Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE completed + +6.3..8. LIST Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LIST + + Result: OK - list completed + NO - list failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LIST command returns a subset of names from the complete set + of all names available to the client. Zero or more untagged LIST + replies are returned, containing the name attributes, hierarchy + delimiter, and name; see the description of the LIST reply for + more detail. + + The LIST command SHOULD return its data quickly, without undue + delay. For example, it SHOULD NOT go to excess trouble to + calculate \Marked or \Unmarked status or perform other processing; + if each name requires 1 second of processing, then a list of 1200 + names would take 20 minutes! + + An empty ("" string) reference name argument indicates that the + mailbox name is interpreted as by SELECT. The returned mailbox + names MUST match the supplied mailbox name pattern. A non-empty + reference name argument is the name of a mailbox or a level of + mailbox hierarchy, and indicates a context in which the mailbox + name is interpreted in an implementation-defined manner. + + + + +Crispin Standards Track [Page 30] + +RFC 2060 IMAP4rev1 December 1996 + + + An empty ("" string) mailbox name argument is a special request to + return the hierarchy delimiter and the root name of the name given + in the reference. The value returned as the root MAY be null if + the reference is non-rooted or is null. In all cases, the + hierarchy delimiter is returned. This permits a client to get the + hierarchy delimiter even when no mailboxes by that name currently + exist. + + The reference and mailbox name arguments are interpreted, in an + implementation-dependent fashion, into a canonical form that + represents an unambiguous left-to-right hierarchy. The returned + mailbox names will be in the interpreted form. + + Any part of the reference argument that is included in the + interpreted form SHOULD prefix the interpreted form. It SHOULD + also be in the same form as the reference name argument. This + rule permits the client to determine if the returned mailbox name + is in the context of the reference argument, or if something about + the mailbox argument overrode the reference argument. Without + this rule, the client would have to have knowledge of the server's + naming semantics including what characters are "breakouts" that + override a naming context. + + For example, here are some examples of how references and mailbox + names might be interpreted on a UNIX-based server: + + Reference Mailbox Name Interpretation + ------------ ------------ -------------- + ~smith/Mail/ foo.* ~smith/Mail/foo.* + archive/ % archive/% + #news. comp.mail.* #news.comp.mail.* + ~smith/Mail/ /usr/doc/foo /usr/doc/foo + archive/ ~fred/Mail/* ~fred/Mail/* + + The first three examples demonstrate interpretations in the + context of the reference argument. Note that "~smith/Mail" SHOULD + NOT be transformed into something like "/u2/users/smith/Mail", or + it would be impossible for the client to determine that the + interpretation was in the context of the reference. + + The character "*" is a wildcard, and matches zero or more + characters at this position. The character "%" is similar to "*", + but it does not match a hierarchy delimiter. If the "%" wildcard + is the last character of a mailbox name argument, matching levels + of hierarchy are also returned. If these levels of hierarchy are + not also selectable mailboxes, they are returned with the + \Noselect mailbox name attribute (see the description of the LIST + response for more details). + + + +Crispin Standards Track [Page 31] + +RFC 2060 IMAP4rev1 December 1996 + + + Server implementations are permitted to "hide" otherwise + accessible mailboxes from the wildcard characters, by preventing + certain characters or names from matching a wildcard in certain + situations. For example, a UNIX-based server might restrict the + interpretation of "*" so that an initial "/" character does not + match. + + The special name INBOX is included in the output from LIST, if + INBOX is supported by this server for this user and if the + uppercase string "INBOX" matches the interpreted reference and + mailbox name arguments with wildcards as described above. The + criteria for omitting INBOX is whether SELECT INBOX will return + failure; it is not relevant whether the user's real INBOX resides + on this or some other server. + + Example: C: A101 LIST "" "" + S: * LIST (\Noselect) "/" "" + S: A101 OK LIST Completed + C: A102 LIST #news.comp.mail.misc "" + S: * LIST (\Noselect) "." #news. + S: A102 OK LIST Completed + C: A103 LIST /usr/staff/jones "" + S: * LIST (\Noselect) "/" / + S: A103 OK LIST Completed + C: A202 LIST ~/Mail/ % + S: * LIST (\Noselect) "/" ~/Mail/foo + S: * LIST () "/" ~/Mail/meetings + S: A202 OK LIST completed + +6.3.9. LSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LSUB + + Result: OK - lsub completed + NO - lsub failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LSUB command returns a subset of names from the set of names + that the user has declared as being "active" or "subscribed". + Zero or more untagged LSUB replies are returned. The arguments to + LSUB are in the same form as those for LIST. + + A server MAY validate the subscribed names to see if they still + exist. If a name does not exist, it SHOULD be flagged with the + \Noselect attribute in the LSUB response. The server MUST NOT + + + +Crispin Standards Track [Page 32] + +RFC 2060 IMAP4rev1 December 1996 + + + unilaterally remove an existing mailbox name from the subscription + list even if a mailbox by that name no longer exists. + + Example: C: A002 LSUB "#news." "comp.mail.*" + S: * LSUB () "." #news.comp.mail.mime + S: * LSUB () "." #news.comp.mail.misc + S: A002 OK LSUB completed + +6.3.10. STATUS Command + + Arguments: mailbox name + status data item names + + Responses: untagged responses: STATUS + + Result: OK - status completed + NO - status failure: no status for that name + BAD - command unknown or arguments invalid + + The STATUS command requests the status of the indicated mailbox. + It does not change the currently selected mailbox, nor does it + affect the state of any messages in the queried mailbox (in + particular, STATUS MUST NOT cause messages to lose the \Recent + flag). + + The STATUS command provides an alternative to opening a second + IMAP4rev1 connection and doing an EXAMINE command on a mailbox to + query that mailbox's status without deselecting the current + mailbox in the first IMAP4rev1 connection. + + Unlike the LIST command, the STATUS command is not guaranteed to + be fast in its response. In some implementations, the server is + obliged to open the mailbox read-only internally to obtain certain + status information. Also unlike the LIST command, the STATUS + command does not accept wildcards. + + The currently defined status data items that can be requested are: + + MESSAGES The number of messages in the mailbox. + + RECENT The number of messages with the \Recent flag set. + + UIDNEXT The next UID value that will be assigned to a new + message in the mailbox. It is guaranteed that this + value will not change unless new messages are added + to the mailbox; and that it will change when new + messages are added even if those new messages are + subsequently expunged. + + + +Crispin Standards Track [Page 33] + +RFC 2060 IMAP4rev1 December 1996 + + + UIDVALIDITY The unique identifier validity value of the + mailbox. + + UNSEEN The number of messages which do not have the \Seen + flag set. + + + Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) + S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + S: A042 OK STATUS completed + +6.3.11. APPEND Command + + Arguments: mailbox name + OPTIONAL flag parenthesized list + OPTIONAL date/time string + message literal + + Responses: 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 + BAD - command unknown or arguments invalid + + The APPEND command appends the literal argument as a new message + to the end of the specified destination mailbox. This argument + SHOULD be in the format of an [RFC-822] 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-822] 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. + + + + + + +Crispin Standards Track [Page 34] + +RFC 2060 IMAP4rev1 December 1996 + + + If the append is unsuccessful for any reason, the mailbox MUST be + restored to its state before the APPEND attempt; no partial appending + is permitted. + + 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 mail 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. + + Example: C: A003 APPEND saved-messages (\Seen) {310} + C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) + C: From: Fred Foobar <foobar@Blurdybloop.COM> + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: <B27397-0100000@Blurdybloop.COM> + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK APPEND completed + + Note: the APPEND command is not used for message delivery, because + it does not provide a mechanism to transfer [SMTP] envelope + information. + +6.4. Client Commands - Selected State + + In selected state, commands that manipulate messages in a mailbox are + permitted. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + and the authenticated state commands (SELECT, EXAMINE, CREATE, + DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and + APPEND), the following commands are valid in the selected state: + CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. + + + + + + +Crispin Standards Track [Page 35] + +RFC 2060 IMAP4rev1 December 1996 + + +6.4.1. CHECK Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - check completed + BAD - command unknown or arguments invalid + + The CHECK command requests a checkpoint of the currently selected + mailbox. A checkpoint refers to any implementation-dependent + housekeeping associated with the mailbox (e.g. resolving the + server's in-memory state of the mailbox with the state on its + disk) that is not normally executed as part of each command. A + checkpoint MAY take a non-instantaneous amount of real time to + complete. If a server implementation has no such housekeeping + considerations, CHECK is equivalent to NOOP. + + There is no guarantee that an EXISTS untagged response will happen + as a result of CHECK. NOOP, not CHECK, SHOULD be used for new + mail polling. + + Example: C: FXXZ CHECK + S: FXXZ OK CHECK Completed + +6.4.2. CLOSE Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - close completed, now in authenticated state + NO - close failure: no mailbox selected + BAD - command unknown or arguments invalid + + The CLOSE command permanently removes from the currently selected + mailbox all messages that have the \Deleted flag set, and returns + to authenticated state from selected state. No untagged EXPUNGE + responses are sent. + + No messages are removed, and no error is given, if the mailbox is + selected by an EXAMINE command or is otherwise selected read-only. + + Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT + command MAY be issued without previously issuing a CLOSE command. + The SELECT, EXAMINE, and LOGOUT commands implicitly close the + currently selected mailbox without doing an expunge. However, + when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT + + + +Crispin Standards Track [Page 36] + +RFC 2060 IMAP4rev1 December 1996 + + + sequence is considerably faster than an EXPUNGE-LOGOUT or + EXPUNGE-SELECT because no untagged EXPUNGE responses (which the + client would probably ignore) are sent. + + Example: C: A341 CLOSE + S: A341 OK CLOSE completed + +6.4.3. EXPUNGE Command + + Arguments: none + + Responses: untagged responses: EXPUNGE + + Result: OK - expunge completed + NO - expunge failure: can't expunge (e.g. permission + denied) + BAD - command unknown or arguments invalid + + The EXPUNGE command permanently removes from the currently + selected mailbox all messages that have the \Deleted flag set. + Before returning an OK to the client, an untagged EXPUNGE response + is sent for each message that is removed. + + Example: C: A202 EXPUNGE + S: * 3 EXPUNGE + S: * 3 EXPUNGE + S: * 5 EXPUNGE + S: * 8 EXPUNGE + S: A202 OK EXPUNGE completed + + Note: in this example, messages 3, 4, 7, and 11 had the + \Deleted flag set. See the description of the EXPUNGE + response for further explanation. + +6.4.4. SEARCH Command + + Arguments: OPTIONAL [CHARSET] specification + searching criteria (one or more) + + Responses: REQUIRED untagged response: SEARCH + + Result: OK - search completed + NO - search error: can't search that [CHARSET] or + criteria + BAD - command unknown or arguments invalid + + + + + + +Crispin Standards Track [Page 37] + +RFC 2060 IMAP4rev1 December 1996 + + + The SEARCH command searches the mailbox for messages that match + the given searching criteria. Searching criteria consist of one + or more search keys. The untagged SEARCH response from the server + contains a listing of message sequence numbers corresponding to + those messages that match the searching criteria. + + When multiple keys are specified, the result is the intersection + (AND function) of all the messages that match those keys. For + example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers + to all deleted messages from Smith that were placed in the mailbox + since February 1, 1994. A search key can also be a parenthesized + list of one or more search keys (e.g. for use with the OR and NOT + keys). + + Server implementations MAY exclude [MIME-IMB] body parts with + terminal content media types other than TEXT and MESSAGE from + consideration in SEARCH matching. + + The OPTIONAL [CHARSET] specification consists of the word + "CHARSET" followed by a registered [CHARSET]. It indicates the + [CHARSET] of the strings that appear in the search criteria. + [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in + [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing + text in a [CHARSET] other than US-ASCII. US-ASCII MUST be + supported; other [CHARSET]s MAY be supported. If the server does + not support the specified [CHARSET], it MUST return a tagged NO + response (not a BAD). + + In all search keys that use strings, a message matches the key if + the string is a substring of the field. The matching is case- + insensitive. + + The defined search keys are as follows. Refer to the Formal + Syntax section for the precise syntactic definitions of the + arguments. + + <message set> Messages with message sequence numbers + corresponding to the specified message sequence + number set + + ALL All messages in the mailbox; the default initial + key for ANDing. + + ANSWERED Messages with the \Answered flag set. + + BCC <string> Messages that contain the specified string in the + envelope structure's BCC field. + + + + +Crispin Standards Track [Page 38] + +RFC 2060 IMAP4rev1 December 1996 + + + BEFORE <date> Messages whose internal date is earlier than the + specified date. + + BODY <string> Messages that contain the specified string in the + body of the message. + + CC <string> Messages that contain the specified string in the + envelope structure's CC field. + + DELETED Messages with the \Deleted flag set. + + DRAFT Messages with the \Draft flag set. + + FLAGGED Messages with the \Flagged flag set. + + FROM <string> Messages that contain the specified string in the + envelope structure's FROM field. + + HEADER <field-name> <string> + Messages that have a header with the specified + field-name (as defined in [RFC-822]) and that + contains the specified string in the [RFC-822] + field-body. + + KEYWORD <flag> Messages with the specified keyword set. + + LARGER <n> Messages with an [RFC-822] size larger than the + specified number of octets. + + NEW Messages that have the \Recent flag set but not the + \Seen flag. This is functionally equivalent to + "(RECENT UNSEEN)". + + NOT <search-key> + Messages that do not match the specified search + key. + + OLD Messages that do not have the \Recent flag set. + This is functionally equivalent to "NOT RECENT" (as + opposed to "NOT NEW"). + + ON <date> Messages whose internal date is within the + specified date. + + OR <search-key1> <search-key2> + Messages that match either search key. + + RECENT Messages that have the \Recent flag set. + + + +Crispin Standards Track [Page 39] + +RFC 2060 IMAP4rev1 December 1996 + + + SEEN Messages that have the \Seen flag set. + + SENTBEFORE <date> + Messages whose [RFC-822] Date: header is earlier + than the specified date. + + SENTON <date> Messages whose [RFC-822] Date: header is within the + specified date. + + SENTSINCE <date> + Messages whose [RFC-822] Date: header is within or + later than the specified date. + + SINCE <date> Messages whose internal date is within or later + than the specified date. + + SMALLER <n> Messages with an [RFC-822] size smaller than the + specified number of octets. + + SUBJECT <string> + Messages that contain the specified string in the + envelope structure's SUBJECT field. + + TEXT <string> Messages that contain the specified string in the + header or body of the message. + + TO <string> Messages that contain the specified string in the + envelope structure's TO field. + + UID <message set> + Messages with unique identifiers corresponding to + the specified unique identifier set. + + UNANSWERED Messages that do not have the \Answered flag set. + + UNDELETED Messages that do not have the \Deleted flag set. + + UNDRAFT Messages that do not have the \Draft flag set. + + UNFLAGGED Messages that do not have the \Flagged flag set. + + UNKEYWORD <flag> + Messages that do not have the specified keyword + set. + + UNSEEN Messages that do not have the \Seen flag set. + + + + + +Crispin Standards Track [Page 40] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" + S: * SEARCH 2 84 882 + S: A282 OK SEARCH completed + +6.4.5. FETCH Command + + Arguments: message set + message data item names + + Responses: untagged responses: FETCH + + Result: OK - fetch completed + NO - fetch error: can't fetch that data + BAD - command unknown or arguments invalid + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched can be either a single atom + or a parenthesized list. + + The currently defined data items that can be fetched are: + + ALL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE) + + BODY Non-extensible form of BODYSTRUCTURE. + + BODY[<section>]<<partial>> + The text of a particular body section. The section + specification is a set of zero or more part + specifiers delimited by periods. A part specifier + is either a part number or one of the following: + HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and + TEXT. An empty section specification refers to the + entire message, including the header. + + Every message has at least one part number. + Non-[MIME-IMB] messages, and non-multipart + [MIME-IMB] messages with no encapsulated message, + only have a part 1. + + Multipart messages are assigned consecutive part + numbers, as they occur in the message. If a + particular part is of type message or multipart, + its parts MUST be indicated by a period followed by + the part number within that nested multipart part. + + + + + + +Crispin Standards Track [Page 41] + +RFC 2060 IMAP4rev1 December 1996 + + + A part of type MESSAGE/RFC822 also has nested part + numbers, referring to parts of the MESSAGE part's + body. + + The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and + TEXT part specifiers can be the sole part specifier + or can be prefixed by one or more numeric part + specifiers, provided that the numeric part + specifier refers to a part of type MESSAGE/RFC822. + The MIME part specifier MUST be prefixed by one or + more numeric part specifiers. + + The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT + part specifiers refer to the [RFC-822] header of + the message or of an encapsulated [MIME-IMT] + MESSAGE/RFC822 message. HEADER.FIELDS and + HEADER.FIELDS.NOT are followed by a list of + field-name (as defined in [RFC-822]) names, and + return a subset of the header. The subset returned + by HEADER.FIELDS contains only those header fields + with a field-name that matches one of the names in + the list; similarly, the subset returned by + HEADER.FIELDS.NOT contains only the header fields + with a non-matching field-name. The field-matching + is case-insensitive but otherwise exact. In all + cases, the delimiting blank line between the header + and the body is always included. + + The MIME part specifier refers to the [MIME-IMB] + header for this part. + + The TEXT part specifier refers to the text body of + the message, omitting the [RFC-822] header. + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 42] + +RFC 2060 IMAP4rev1 December 1996 + + + Here is an example of a complex message + with some of its part specifiers: + + HEADER ([RFC-822] header of the message) + TEXT MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.HEADER ([RFC-822] header of the message) + 3.TEXT ([RFC-822] text body of the message) + 3.1 TEXT/PLAIN + 3.2 APPLICATION/OCTET-STREAM + 4 MULTIPART/MIXED + 4.1 IMAGE/GIF + 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) + 4.2 MESSAGE/RFC822 + 4.2.HEADER ([RFC-822] header of the message) + 4.2.TEXT ([RFC-822] text body of the message) + 4.2.1 TEXT/PLAIN + 4.2.2 MULTIPART/ALTERNATIVE + 4.2.2.1 TEXT/PLAIN + 4.2.2.2 TEXT/RICHTEXT + + + It is possible to fetch a substring of the + designated text. This is done by appending an open + angle bracket ("<"), the octet position of the + first desired octet, a period, the maximum number + of octets desired, and a close angle bracket (">") + to the part specifier. If the starting octet is + beyond the end of the text, an empty string is + returned. + + Any partial fetch that attempts to read beyond the + end of the text is truncated as appropriate. A + partial fetch that starts at octet 0 is returned as + a partial fetch, even if this truncation happened. + + Note: this means that BODY[]<0.2048> of a + 1500-octet message will return BODY[]<0> + with a literal of size 1500, not BODY[]. + + Note: a substring fetch of a + HEADER.FIELDS or HEADER.FIELDS.NOT part + specifier is calculated after subsetting + the header. + + + + + +Crispin Standards Track [Page 43] + +RFC 2060 IMAP4rev1 December 1996 + + + The \Seen flag is implicitly set; if this causes + the flags to change they SHOULD be included as part + of the FETCH responses. + + BODY.PEEK[<section>]<<partial>> An alternate form of + BODY[<section>] that does not implicitly set the + \Seen flag. + + BODYSTRUCTURE The [MIME-IMB] body structure of the message. This + is computed by the server by parsing the [MIME-IMB] + header fields in the [RFC-822] header and + [MIME-IMB] headers. + + ENVELOPE The envelope structure of the message. This is + computed by the server by parsing the [RFC-822] + header into the component parts, defaulting various + fields as necessary. + + FAST Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE) + + FLAGS The flags that are set for this message. + + FULL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE BODY) + + INTERNALDATE The internal date of the message. + + RFC822 Functionally equivalent to BODY[], differing in the + syntax of the resulting untagged FETCH data (RFC822 + is returned). + + RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], + differing in the syntax of the resulting untagged + FETCH data (RFC822.HEADER is returned). + + RFC822.SIZE The [RFC-822] size of the message. + + RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in + the syntax of the resulting untagged FETCH data + (RFC822.TEXT is returned). + + UID The unique identifier for the message. + + + + + + + + +Crispin Standards Track [Page 44] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) + S: * 2 FETCH .... + S: * 3 FETCH .... + S: * 4 FETCH .... + S: A654 OK FETCH completed + +6.4.6. STORE Command + + Arguments: message set + message data item name + value for message data item + + Responses: untagged responses: FETCH + + Result: OK - store completed + NO - store error: can't store that data + BAD - command unknown or arguments invalid + + The STORE command alters data associated with a message in the + mailbox. Normally, STORE will return the updated value of the + data with an untagged FETCH response. A suffix of ".SILENT" in + the data item name prevents the untagged FETCH, and the server + SHOULD assume that the client has determined the updated value + itself or does not care about the updated value. + + Note: regardless of whether or not the ".SILENT" suffix was + used, the server SHOULD send an untagged FETCH response if a + change to a message's flags from an external source is + observed. The intent is that the status of the flags is + determinate without a race condition. + + The currently defined data items that can be stored are: + + FLAGS <flag list> + Replace the flags for the message with the + argument. The new value of the flags are returned + as if a FETCH of those flags was done. + + FLAGS.SILENT <flag list> + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS <flag list> + Add the argument to the flags for the message. The + new value of the flags are returned as if a FETCH + of those flags was done. + + + + + +Crispin Standards Track [Page 45] + +RFC 2060 IMAP4rev1 December 1996 + + + +FLAGS.SILENT <flag list> + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS <flag list> + Remove the argument from the flags for the message. + The new value of the flags are returned as if a + FETCH of those flags was done. + + -FLAGS.SILENT <flag list> + Equivalent to -FLAGS, but without returning a new + value. + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH FLAGS (\Deleted \Seen) + S: * 3 FETCH FLAGS (\Deleted) + S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) + S: A003 OK STORE completed + +6.4.7. COPY Command + + Arguments: message set + mailbox name + + Responses: no specific responses for this command + + Result: OK - copy completed + NO - copy error: can't copy those messages or to that + name + BAD - command unknown or arguments invalid + + The COPY command copies the specified message(s) to the end of the + specified destination mailbox. The flags and internal date of the + message(s) SHOULD be preserved in the copy. + + If the destination mailbox does not exist, a server SHOULD return + an error. It SHOULD 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 COPY if + the CREATE is successful. + + + + + + + + + +Crispin Standards Track [Page 46] + +RFC 2060 IMAP4rev1 December 1996 + + + If the COPY command is unsuccessful for any reason, server + implementations MUST restore the destination mailbox to its state + before the COPY attempt. + + Example: C: A003 COPY 2:4 MEETING + S: A003 OK COPY completed + +6.4.8. UID Command + + Arguments: command name + command arguments + + Responses: untagged responses: FETCH, SEARCH + + Result: OK - UID command completed + NO - UID command error + BAD - command unknown or arguments invalid + + The UID command has two forms. In the first form, it takes as its + arguments a COPY, FETCH, or STORE command with arguments + appropriate for the associated command. However, the numbers in + the message set argument are unique identifiers instead of message + sequence numbers. + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of the message sequence number set 1:100 and the + UID set 443:557. + + Message set ranges are permitted; however, there is no guarantee + that unique identifiers be contiguous. A non-existent unique + identifier within a message set range is ignored without any error + message generated. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether a UID was specified + as a message data item to the FETCH. + + + + + + + +Crispin Standards Track [Page 47] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A999 UID FETCH 4827313:4828442 FLAGS + S: * 23 FETCH (FLAGS (\Seen) UID 4827313) + S: * 24 FETCH (FLAGS (\Seen) UID 4827943) + S: * 25 FETCH (FLAGS (\Seen) UID 4828442) + S: A999 UID FETCH completed + +6.5. Client Commands - Experimental/Expansion + +6.5.1. X<atom> Command + + Arguments: implementation defined + + Responses: implementation defined + + Result: OK - command completed + NO - failure + BAD - command unknown or arguments invalid + + Any command prefixed with an X is an experimental command. + Commands which are not part of this specification, a standard or + standards-track revision of this specification, or an IESG- + approved experimental protocol, MUST use the X prefix. + + Any added untagged responses issued by an experimental command + MUST also be prefixed with an X. Server implementations MUST NOT + send any such untagged responses, unless the client requested it + by issuing the associated experimental command. + + Example: C: a441 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + S: a441 OK CAPABILITY completed + C: A442 XPIG-LATIN + S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay + S: A442 OK XPIG-LATIN ompleted-cay + +7. Server Responses + + Server responses are in three forms: status responses, server data, + and command continuation request. The information contained in a + server response, identified by "Contents:" in the response + descriptions below, is described by function, not by syntax. The + precise syntax of server responses is described in the Formal Syntax + section. + + The client MUST be prepared to accept any response at all times. + + + + + + +Crispin Standards Track [Page 48] + +RFC 2060 IMAP4rev1 December 1996 + + + Status responses can be tagged or untagged. Tagged status responses + indicate the completion result (OK, NO, or BAD status) of a client + command, and have a tag matching the command. + + Some status responses, and all server data, are untagged. An + untagged response is indicated by the token "*" instead of a tag. + Untagged status responses indicate server greeting, or server status + that does not indicate the completion of a command (for example, an + impending system shutdown alert). For historical reasons, untagged + server data responses are also called "unsolicited data", although + strictly speaking only unilateral server data is truly "unsolicited". + + Certain server data MUST be recorded by the client when it is + received; this is noted in the description of that data. Such data + conveys critical information which affects the interpretation of all + subsequent commands and responses (e.g. updates reflecting the + creation or destruction of messages). + + Other server data SHOULD be recorded for later reference; if the + client does not need to record the data, or if recording the data has + no obvious purpose (e.g. a SEARCH response when no SEARCH command is + in progress), the data SHOULD be ignored. + + An example of unilateral untagged server data occurs when the IMAP + connection is in selected state. In selected state, the server + checks the mailbox for new messages as part of command execution. + Normally, this is part of the execution of every command; hence, a + NOOP command suffices to check for new messages. If new messages are + found, the server sends untagged EXISTS and RECENT responses + reflecting the new size of the mailbox. Server implementations that + offer multiple simultaneous access to the same mailbox SHOULD also + send appropriate unilateral untagged FETCH and EXPUNGE responses if + another agent changes the state of any message flags or expunges any + messages. + + Command continuation request responses use the token "+" instead of a + tag. These responses are sent by the server to indicate acceptance + of an incomplete client command and readiness for the remainder of + the command. + +7.1. Server Responses - Status Responses + + Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD + may be tagged or untagged. PREAUTH and BYE are always untagged. + + Status responses MAY include an OPTIONAL "response code". A response + code consists of data inside square brackets in the form of an atom, + possibly followed by a space and arguments. The response code + + + +Crispin Standards Track [Page 49] + +RFC 2060 IMAP4rev1 December 1996 + + + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + The currently defined response codes are: + + ALERT The human-readable text contains a special alert + that MUST be presented to the user in a fashion + that calls the user's attention to the message. + + NEWNAME Followed by a mailbox name and a new mailbox name. + A SELECT or EXAMINE is failing because the target + mailbox name no longer exists because it was + renamed to the new mailbox name. This is a hint to + the client that the operation can succeed if the + SELECT or EXAMINE is reissued with the new mailbox + name. + + PARSE The human-readable text represents an error in + parsing the [RFC-822] header or [MIME-IMB] headers + of a message in the mailbox. + + PERMANENTFLAGS Followed by a parenthesized list of flags, + indicates which of the known flags that the client + can change permanently. Any flags that are in the + FLAGS untagged response, but not the PERMANENTFLAGS + list, can not be set permanently. If the client + attempts to STORE a flag that is not in the + PERMANENTFLAGS list, the server will either reject + it with a NO reply or store the state for the + remainder of the current session only. The + PERMANENTFLAGS list can also include the special + flag \*, which indicates that it is possible to + create new keywords by attempting to store those + flags in the mailbox. + + READ-ONLY The mailbox is selected read-only, or its access + while selected has changed from read-write to + read-only. + + READ-WRITE The mailbox is selected read-write, or its access + while selected has changed from read-only to + read-write. + + + + + + + +Crispin Standards Track [Page 50] + +RFC 2060 IMAP4rev1 December 1996 + + + TRYCREATE An APPEND or COPY attempt is failing because the + target mailbox does not exist (as opposed to some + other reason). This is a hint to the client that + the operation can succeed if the mailbox is first + created by the CREATE command. + + UIDVALIDITY Followed by a decimal number, indicates the unique + identifier validity value. + + UNSEEN Followed by a decimal number, indicates the number + of the first message without the \Seen flag set. + + Additional response codes defined by particular client or server + implementations SHOULD be prefixed with an "X" until they are + added to a revision of this protocol. Client implementations + SHOULD ignore response codes that they do not recognize. + +7.1.1. OK Response + + Contents: OPTIONAL response code + human-readable text + + The OK response indicates an information message from the server. + When tagged, it indicates successful completion of the associated + command. The human-readable text MAY be presented to the user as + an information message. The untagged form indicates an + information-only message; the nature of the information MAY be + indicated by a response code. + + The untagged form is also used as one of three possible greetings + at connection startup. It indicates that the connection is not + yet authenticated and that a LOGIN command is needed. + + Example: S: * OK IMAP4rev1 server ready + C: A001 LOGIN fred blurdybloop + S: * OK [ALERT] System shutdown in 10 minutes + S: A001 OK LOGIN Completed + +7.1.2. NO Response + + Contents: OPTIONAL response code + human-readable text + + The NO response indicates an operational error message from the + server. When tagged, it indicates unsuccessful completion of the + associated command. The untagged form indicates a warning; the + command can still complete successfully. The human-readable text + describes the condition. + + + +Crispin Standards Track [Page 51] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A222 COPY 1:2 owatagusiam + S: * NO Disk is 98% full, please delete unnecessary data + S: A222 OK COPY completed + C: A223 COPY 3:200 blurdybloop + S: * NO Disk is 98% full, please delete unnecessary data + S: * NO Disk is 99% full, please delete unnecessary data + S: A223 NO COPY failed: disk is full + +7.1.3. BAD Response + + Contents: OPTIONAL response code + human-readable text + + The BAD response indicates an error message from the server. When + tagged, it reports a protocol-level error in the client's command; + the tag indicates the command that caused the error. The untagged + form indicates a protocol-level error for which the associated + command can not be determined; it can also indicate an internal + server failure. The human-readable text describes the condition. + + Example: C: ...very long command line... + S: * BAD Command line too long + C: ...empty line... + S: * BAD Empty command line + C: A443 EXPUNGE + S: * BAD Disk crash, attempting salvage to a new disk! + S: * OK Salvage successful, no data lost + S: A443 OK Expunge completed + +7.1.4. PREAUTH Response + + Contents: OPTIONAL response code + human-readable text + + The PREAUTH response is always untagged, and is one of three + possible greetings at connection startup. It indicates that the + connection has already been authenticated by external means and + thus no LOGIN command is needed. + + Example: S: * PREAUTH IMAP4rev1 server logged in as Smith + +7.1.5. BYE Response + + Contents: OPTIONAL response code + human-readable text + + + + + + +Crispin Standards Track [Page 52] + +RFC 2060 IMAP4rev1 December 1996 + + + The BYE response is always untagged, and indicates that the server + is about to close the connection. The human-readable text MAY be + displayed to the user in a status report by the client. The BYE + response is sent under one of four conditions: + + 1) as part of a normal logout sequence. The server will close + the connection after sending the tagged OK response to the + LOGOUT command. + + 2) as a panic shutdown announcement. The server closes the + connection immediately. + + 3) as an announcement of an inactivity autologout. The server + closes the connection immediately. + + 4) as one of three possible greetings at connection startup, + indicating that the server is not willing to accept a + connection from this client. The server closes the + connection immediately. + + The difference between a BYE that occurs as part of a normal + LOGOUT sequence (the first case) and a BYE that occurs because of + a failure (the other three cases) is that the connection closes + immediately in the failure case. + + Example: S: * BYE Autologout; idle for too long + +7.2. Server Responses - Server and Mailbox Status + + These responses are always untagged. This is how server and mailbox + status data are transmitted from the server to the client. Many of + these responses typically result from a command with the same name. + +7.2.1. CAPABILITY Response + + Contents: capability listing + + The CAPABILITY response occurs as a result of a CAPABILITY + command. The capability listing contains a space-separated + listing of capability names that the server supports. The + capability listing MUST include the atom "IMAP4rev1". + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. + + + + + + + +Crispin Standards Track [Page 53] + +RFC 2060 IMAP4rev1 December 1996 + + + Other capability names indicate that the server supports an + extension, revision, or amendment to the IMAP4rev1 protocol. + Server responses MUST conform to this document until the client + issues a command that uses the associated capability. + + Capability names MUST either begin with "X" or be standard or + standards-track IMAP4rev1 extensions, revisions, or amendments + registered with IANA. A server MUST NOT offer unregistered or + non-standard capability names, unless such names are prefixed with + an "X". + + Client implementations SHOULD NOT require any capability name + other than "IMAP4rev1", and MUST ignore any unknown capability + names. + + Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN + +7.2.2. LIST Response + + Contents: name attributes + hierarchy delimiter + name + + The LIST response occurs as a result of a LIST command. It + returns a single name that matches the LIST specification. There + can be multiple LIST responses for a single LIST command. + + Four name attributes are defined: + + \Noinferiors It is not possible for any child levels of + hierarchy to exist under this name; no child levels + exist now and none can be created in the future. + + \Noselect It is not possible to use this name as a selectable + mailbox. + + \Marked The mailbox has been marked "interesting" by the + server; the mailbox probably contains messages that + have been added since the last time the mailbox was + selected. + + \Unmarked The mailbox does not contain any additional + messages since the last time the mailbox was + selected. + + If it is not feasible for the server to determine whether the + mailbox is "interesting" or not, or if the name is a \Noselect + name, the server SHOULD NOT send either \Marked or \Unmarked. + + + +Crispin Standards Track [Page 54] + +RFC 2060 IMAP4rev1 December 1996 + + + The hierarchy delimiter is a character used to delimit levels of + hierarchy in a mailbox name. A client can use it to create child + mailboxes, and to search higher or lower levels of naming + hierarchy. All children of a top-level hierarchy node MUST use + the same separator character. A NIL hierarchy delimiter means + that no hierarchy exists; the name is a "flat" name. + + The name represents an unambiguous left-to-right hierarchy, and + MUST be valid for use as a reference in LIST and LSUB commands. + Unless \Noselect is indicated, the name MUST also be valid as an + argument for commands, such as SELECT, that accept mailbox + names. + + Example: S: * LIST (\Noselect) "/" ~/Mail/foo + +7.2.3. LSUB Response + + Contents: name attributes + hierarchy delimiter + name + + The LSUB response occurs as a result of an LSUB command. It + returns a single name that matches the LSUB specification. There + can be multiple LSUB responses for a single LSUB command. The + data is identical in format to the LIST response. + + Example: S: * LSUB () "." #news.comp.mail.misc + +7.2.4 STATUS Response + + Contents: name + status parenthesized list + + The STATUS response occurs as a result of an STATUS command. It + returns the mailbox name that matches the STATUS specification and + the requested mailbox status information. + + Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + +7.2.5. SEARCH Response + + Contents: zero or more numbers + + + + + + + + + +Crispin Standards Track [Page 55] + +RFC 2060 IMAP4rev1 December 1996 + + + The SEARCH response occurs as a result of a SEARCH or UID SEARCH + command. The number(s) refer to those messages that match the + search criteria. For SEARCH, these are message sequence numbers; + for UID SEARCH, these are unique identifiers. Each number is + delimited by a space. + + Example: S: * SEARCH 2 3 6 + +7.2.6. FLAGS Response + + Contents: flag parenthesized list + + The FLAGS response occurs as a result of a SELECT or EXAMINE + command. The flag parenthesized list identifies the flags (at a + minimum, the system-defined flags) that are applicable for this + mailbox. Flags other than the system flags can also exist, + depending on server implementation. + + The update from the FLAGS response MUST be recorded by the client. + + Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + +7.3. Server Responses - Mailbox Size + + These responses are always untagged. This is how changes in the size + of the mailbox are trasnmitted from the server to the client. + Immediately following the "*" token is a number that represents a + message count. + +7.3.1. EXISTS Response + + Contents: none + + The EXISTS response reports the number of messages in the mailbox. + This response occurs as a result of a SELECT or EXAMINE command, + and if the size of the mailbox changes (e.g. new mail). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + + + + + + + + + +Crispin Standards Track [Page 56] + +RFC 2060 IMAP4rev1 December 1996 + + +7.3.2. RECENT Response + + Contents: none + + The RECENT response reports the number of messages with the + \Recent flag set. This response occurs as a result of a SELECT or + EXAMINE command, and if the size of the mailbox changes (e.g. new + mail). + + Note: It is not guaranteed that the message sequence numbers of + recent messages will be a contiguous range of the highest n + messages in the mailbox (where n is the value reported by the + RECENT response). Examples of situations in which this is not + the case are: multiple clients having the same mailbox open + (the first session to be notified will see it as recent, others + will probably see it as non-recent), and when the mailbox is + re-ordered by a non-IMAP agent. + + The only reliable way to identify recent messages is to look at + message flags to see which have the \Recent flag set, or to do + a SEARCH RECENT. + + The update from the RECENT response MUST be recorded by the + client. + + Example: S: * 5 RECENT + +7.4. Server Responses - Message Status + + These responses are always untagged. This is how message data are + transmitted from the server to the client, often as a result of a + command with the same name. Immediately following the "*" token is a + number that represents a message sequence number. + +7.4.1. EXPUNGE Response + + Contents: none + + The EXPUNGE response reports that the specified message sequence + number has been permanently removed from the mailbox. The message + sequence number for each successive message in the mailbox is + immediately decremented by 1, and this decrement is reflected in + message sequence numbers in subsequent responses (including other + untagged EXPUNGE responses). + + As a result of the immediate decrement rule, message sequence + numbers that appear in a set of successive EXPUNGE responses + depend upon whether the messages are removed starting from lower + + + +Crispin Standards Track [Page 57] + +RFC 2060 IMAP4rev1 December 1996 + + + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged; a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress; nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + +7.4.2. FETCH Response + + Contents: message data + + The FETCH response returns data about a message to the client. + The data are pairs of data item names and their values in + parentheses. This response occurs as the result of a FETCH or + STORE command, as well as by unilateral server decision (e.g. flag + updates). + + The current data items are: + + BODY A form of BODYSTRUCTURE without extension data. + + BODY[<section>]<<origin_octet>> + A string expressing the body contents of the + specified section. The string SHOULD be + interpreted by the client according to the content + transfer encoding, body type, and subtype. + + If the origin octet is specified, this string is a + substring of the entire body contents, starting at + that origin octet. This means that BODY[]<0> MAY + be truncated, but BODY[] is NEVER truncated. + + 8-bit textual data is permitted if a [CHARSET] + identifier is part of the body parameter + parenthesized list for this section. Note that + headers (part specifiers HEADER or MIME, or the + header portion of a MESSAGE/RFC822 part), MUST be + + + +Crispin Standards Track [Page 58] + +RFC 2060 IMAP4rev1 December 1996 + + + 7-bit; 8-bit characters are not permitted in + headers. Note also that the blank line at the end + of the header is always included in header data. + + Non-textual data such as binary data MUST be + transfer encoded into a textual form such as BASE64 + prior to being sent to the client. To derive the + original binary data, the client MUST decode the + transfer encoded string. + + BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] + body structure of a message. This is computed by + the server by parsing the [MIME-IMB] header fields, + defaulting various fields as necessary. + + For example, a simple text message of 48 lines and + 2279 octets can have a body structure of: ("TEXT" + "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 + 48) + + Multiple parts are indicated by parenthesis + nesting. Instead of a body type as the first + element of the parenthesized list there is a nested + body. The second element of the parenthesized list + is the multipart subtype (mixed, digest, parallel, + alternative, etc.). + + For example, a two part message consisting of a + text and a BASE645-encoded text attachment can have + a body structure of: (("TEXT" "PLAIN" ("CHARSET" + "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" + ("CHARSET" "US-ASCII" "NAME" "cc.diff") + "<960723163407.20117h@cac.washington.edu>" + "Compiler diff" "BASE64" 4554 73) "MIXED")) + + Extension data follows the multipart subtype. + Extension data is never returned with the BODY + fetch, but can be returned with a BODYSTRUCTURE + fetch. Extension data, if present, MUST be in the + defined order. + + The extension data of a multipart body part are in + the following order: + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + + + +Crispin Standards Track [Page 59] + +RFC 2060 IMAP4rev1 December 1996 + + + "baz"] as defined in [MIME-IMB]. + + body disposition + A parenthesized list, consisting of a + disposition type string followed by a + parenthesized list of disposition + attribute/value pairs. The disposition type and + attribute names will be defined in a future + standards-track revision to [DISPOSITION]. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol. Such extension data + can consist of zero or more NILs, strings, numbers, + or potentially nested parenthesized lists of such + data. Client implementations that do a + BODYSTRUCTURE fetch MUST be prepared to accept such + extension data. Server implementations MUST NOT + send such extension data until it has been defined + by a revision of this protocol. + + The basic fields of a non-multipart body part are + in the following order: + + body type + A string giving the content media type name as + defined in [MIME-IMB]. + + body subtype + A string giving the content subtype name as + defined in [MIME-IMB]. + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. ("foo" "bar" "baz" "rag") where "bar" is + the value of "foo" and "rag" is the value of + "baz"] as defined in [MIME-IMB]. + + body id + A string giving the content id as defined in + [MIME-IMB]. + + body description + A string giving the content description as + defined in [MIME-IMB]. + + + +Crispin Standards Track [Page 60] + +RFC 2060 IMAP4rev1 December 1996 + + + body encoding + A string giving the content transfer encoding as + defined in [MIME-IMB]. + + body size + A number giving the size of the body in octets. + Note that this size is the size in its transfer + encoding and not the resulting size after any + decoding. + + A body type of type MESSAGE and subtype RFC822 + contains, immediately after the basic fields, the + envelope structure, body structure, and size in + text lines of the encapsulated message. + + A body type of type TEXT contains, immediately + after the basic fields, the size of the body in + text lines. Note that this size is the size in its + content transfer encoding and not the resulting + size after any decoding. + + Extension data follows the basic fields and the + type-specific fields listed above. Extension data + is never returned with the BODY fetch, but can be + returned with a BODYSTRUCTURE fetch. Extension + data, if present, MUST be in the defined order. + + The extension data of a non-multipart body part are + in the following order: + + body MD5 + A string giving the body MD5 value as defined in + [MD5]. + + body disposition + A parenthesized list with the same content and + function as the body disposition for a multipart + body part. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + Any following extension data are not yet defined in + this version of the protocol, and would be as + described above under multipart extension data. + + + + + +Crispin Standards Track [Page 61] + +RFC 2060 IMAP4rev1 December 1996 + + + ENVELOPE A parenthesized list that describes the envelope + structure of a message. This is computed by the + server by parsing the [RFC-822] header into the + component parts, defaulting various fields as + necessary. + + The fields of the envelope structure are in the + following order: date, subject, from, sender, + reply-to, to, cc, bcc, in-reply-to, and message-id. + The date, subject, in-reply-to, and message-id + fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of + address structures. + + An address structure is a parenthesized list that + describes an electronic mail address. The fields + of an address structure are in the following order: + personal name, [SMTP] at-domain-list (source + route), mailbox name, and host name. + + [RFC-822] group syntax is indicated by a special + form of address structure in which the host name + field is NIL. If the mailbox name field is also + NIL, this is an end of group marker (semi-colon in + RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the + mailbox name field holds the group name phrase. + + Any field of an envelope or address structure that + is not applicable is presented as NIL. Note that + the server MUST default the reply-to and sender + fields from the from field; a client is not + expected to know to do this. + + FLAGS A parenthesized list of flags that are set for this + message. + + INTERNALDATE A string representing the internal date of the + message. + + RFC822 Equivalent to BODY[]. + + RFC822.HEADER Equivalent to BODY.PEEK[HEADER]. + + RFC822.SIZE A number expressing the [RFC-822] size of the + message. + + RFC822.TEXT Equivalent to BODY[TEXT]. + + + +Crispin Standards Track [Page 62] + +RFC 2060 IMAP4rev1 December 1996 + + + UID A number expressing the unique identifier of the + message. + + + Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) + +7.5. Server Responses - Command Continuation Request + + The command continuation request response is indicated by a "+" token + instead of a tag. This form of response indicates that the server is + ready to accept the continuation of a command from the client. The + remainder of this response is a line of text. + + This response is used in the AUTHORIZATION command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it expects it. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + +8. Sample IMAP4rev1 connection + + The following is a transcript of an IMAP4rev1 connection. A long + line in this sample is broken for editorial clarity. + +S: * OK IMAP4rev1 Service Ready +C: a001 login mrc secret +S: a001 OK LOGIN completed +C: a002 select inbox +S: * 18 EXISTS +S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) +S: * 2 RECENT +S: * OK [UNSEEN 17] Message 17 is the first unseen message +S: * OK [UIDVALIDITY 3857529045] UIDs valid + + + +Crispin Standards Track [Page 63] + +RFC 2060 IMAP4rev1 December 1996 + + +S: a002 OK [READ-WRITE] SELECT completed +C: a003 fetch 12 full +S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" + RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" + "IMAP4rev1 WG mtg summary and minutes" + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + ((NIL NIL "imap" "cac.washington.edu")) + ((NIL NIL "minutes" "CNRI.Reston.VA.US") + ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL + "<B27397-0100000@cac.washington.edu>") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) +S: a003 OK FETCH completed +C: a004 fetch 12 body[header] +S: * 12 FETCH (BODY[HEADER] {350} +S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) +S: From: Terry Gray <gray@cac.washington.edu> +S: Subject: IMAP4rev1 WG mtg summary and minutes +S: To: imap@cac.washington.edu +S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU> +S: Message-Id: <B27397-0100000@cac.washington.edu> +S: MIME-Version: 1.0 +S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII +S: +S: ) +S: a004 OK FETCH completed +C: a005 store 12 +flags \deleted +S: * 12 FETCH (FLAGS (\Seen \Deleted)) +S: a005 OK +FLAGS completed +C: a006 logout +S: * BYE IMAP4rev1 server terminating connection +S: a006 OK LOGOUT completed + +9. 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 (SPACE) and + not one or more commas. + + In the case of alternative or optional rules in which a later rule + overlaps an earlier rule, the rule which is listed earlier MUST take + priority. For example, "\Seen" when parsed as a flag is the \Seen + flag name and not a flag_extension, even though "\Seen" could be + parsed as a flag_extension. Some, but not all, instances of this + rule are noted below. + + + + +Crispin Standards Track [Page 64] + +RFC 2060 IMAP4rev1 December 1996 + + + 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. + +address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox + SPACE addr_host ")" + +addr_adl ::= nstring + ;; Holds route from [RFC-822] route-addr if + ;; non-NIL + +addr_host ::= nstring + ;; NIL indicates [RFC-822] group syntax. + ;; Otherwise, holds [RFC-822] domain name + +addr_mailbox ::= nstring + ;; NIL indicates end of [RFC-822] group; if + ;; non-NIL and addr_host is NIL, holds + ;; [RFC-822] group name. + ;; Otherwise, holds [RFC-822] local-part + +addr_name ::= nstring + ;; Holds phrase from [RFC-822] mailbox if + ;; non-NIL + +alpha ::= "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" + ;; Case-sensitive + +append ::= "APPEND" SPACE mailbox [SPACE flag_list] + [SPACE date_time] SPACE literal + +astring ::= atom / string + +atom ::= 1*ATOM_CHAR + +ATOM_CHAR ::= <any CHAR except atom_specials> + +atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / + quoted_specials + + + + +Crispin Standards Track [Page 65] + +RFC 2060 IMAP4rev1 December 1996 + + +authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) + +auth_type ::= atom + ;; Defined by [IMAP-AUTH] + +base64 ::= *(4base64_char) [base64_terminal] + +base64_char ::= alpha / digit / "+" / "/" + +base64_terminal ::= (2base64_char "==") / (3base64_char "=") + +body ::= "(" body_type_1part / body_type_mpart ")" + +body_extension ::= nstring / number / "(" 1#body_extension ")" + ;; Future expansion. Client implementations + ;; MUST accept body_extension fields. Server + ;; implementations MUST NOT generate + ;; body_extension fields except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp + [SPACE body_fld_lang + [SPACE 1#body_extension]]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_ext_mpart ::= body_fld_param + [SPACE body_fld_dsp SPACE body_fld_lang + [SPACE 1#body_extension]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_fields ::= body_fld_param SPACE body_fld_id SPACE + body_fld_desc SPACE body_fld_enc SPACE + body_fld_octets + +body_fld_desc ::= nstring + +body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil + +body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") <">) / string + +body_fld_id ::= nstring + +body_fld_lang ::= nstring / "(" 1#string ")" + + + + +Crispin Standards Track [Page 66] + +RFC 2060 IMAP4rev1 December 1996 + + +body_fld_lines ::= number + +body_fld_md5 ::= nstring + +body_fld_octets ::= number + +body_fld_param ::= "(" 1#(string SPACE string) ")" / nil + +body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) + [SPACE body_ext_1part] + +body_type_basic ::= media_basic SPACE body_fields + ;; MESSAGE subtype MUST NOT be "RFC822" + +body_type_mpart ::= 1*body SPACE media_subtype + [SPACE body_ext_mpart] + +body_type_msg ::= media_message SPACE body_fields SPACE envelope + SPACE body SPACE body_fld_lines + +body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines + +capability ::= "AUTH=" auth_type / atom + ;; New capabilities MUST begin with "X" or be + ;; registered with IANA as standard or + ;; standards-track + +capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" + [SPACE 1#capability] + ;; IMAP4rev1 servers which offer RFC 1730 + ;; compatibility MUST list "IMAP4" as the first + ;; capability. + +CHAR ::= <any 7-bit US-ASCII character except NUL, + 0x01 - 0x7f> + +CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff> + +command ::= tag SPACE (command_any / command_auth / + command_nonauth / command_select) CRLF + ;; Modal based on state + +command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command + ;; Valid in all states + +command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + ;; Valid only in Authenticated or Selected state + + + +Crispin Standards Track [Page 67] + +RFC 2060 IMAP4rev1 December 1996 + + +command_nonauth ::= login / authenticate + ;; Valid only when in Non-Authenticated state + +command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / + copy / fetch / store / uid / search + ;; Valid only when in Selected state + +continue_req ::= "+" SPACE (resp_text / base64) + +copy ::= "COPY" SPACE set SPACE mailbox + +CR ::= <ASCII CR, carriage return, 0x0D> + +create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + +CRLF ::= CR LF + +CTL ::= <any ASCII control character and DEL, + 0x00 - 0x1f, 0x7f> + +date ::= date_text / <"> date_text <"> + +date_day ::= 1*2digit + ;; Day of month + +date_day_fixed ::= (SPACE digit) / 2digit + ;; Fixed-format version of date_day + +date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + +date_text ::= date_day "-" date_month "-" date_year + +date_year ::= 4digit + +date_time ::= <"> date_day_fixed "-" date_month "-" date_year + SPACE time SPACE zone <"> + +delete ::= "DELETE" SPACE mailbox + ;; Use of INBOX gives a NO error + +digit ::= "0" / digit_nz + +digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / + "9" + + + + + +Crispin Standards Track [Page 68] + +RFC 2060 IMAP4rev1 December 1996 + + +envelope ::= "(" env_date SPACE env_subject SPACE env_from + SPACE env_sender SPACE env_reply_to SPACE env_to + SPACE env_cc SPACE env_bcc SPACE env_in_reply_to + SPACE env_message_id ")" + +env_bcc ::= "(" 1*address ")" / nil + +env_cc ::= "(" 1*address ")" / nil + +env_date ::= nstring + +env_from ::= "(" 1*address ")" / nil + +env_in_reply_to ::= nstring + +env_message_id ::= nstring + +env_reply_to ::= "(" 1*address ")" / nil + +env_sender ::= "(" 1*address ")" / nil + +env_subject ::= nstring + +env_to ::= "(" 1*address ")" / nil + +examine ::= "EXAMINE" SPACE mailbox + +fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / + "FAST" / fetch_att / "(" 1#fetch_att ")") + +fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / + "BODY" ["STRUCTURE"] / "UID" / + "BODY" [".PEEK"] section + ["<" number "." nz_number ">"] + +flag ::= "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag_keyword / flag_extension + +flag_extension ::= "\" atom + ;; Future expansion. Client implementations + ;; MUST accept flag_extension flags. Server + ;; implementations MUST NOT generate + ;; flag_extension flags except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +flag_keyword ::= atom + + + +Crispin Standards Track [Page 69] + +RFC 2060 IMAP4rev1 December 1996 + + +flag_list ::= "(" #flag ")" + +greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF + +header_fld_name ::= astring + +header_list ::= "(" 1#header_fld_name ")" + +LF ::= <ASCII LF, line feed, 0x0A> + +list ::= "LIST" SPACE mailbox SPACE list_mailbox + +list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string + +list_wildcards ::= "%" / "*" + +literal ::= "{" number "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + +login ::= "LOGIN" SPACE userid SPACE password + +lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox + +mailbox ::= "INBOX" / astring + ;; INBOX is case-insensitive. All case variants of + ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX + ;; not as an astring. Refer to section 5.1 for + ;; further semantic details of mailbox names. + +mailbox_data ::= "FLAGS" SPACE flag_list / + "LIST" SPACE mailbox_list / + "LSUB" SPACE mailbox_list / + "MAILBOX" SPACE text / + "SEARCH" [SPACE 1#nz_number] / + "STATUS" SPACE mailbox SPACE + "(" #<status_att number ")" / + number SPACE "EXISTS" / number SPACE "RECENT" + +mailbox_list ::= "(" #("\Marked" / "\Noinferiors" / + "\Noselect" / "\Unmarked" / flag_extension) ")" + SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox + +media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") <">) / string) + SPACE media_subtype + ;; Defined in [MIME-IMT] + +media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> + + + +Crispin Standards Track [Page 70] + +RFC 2060 IMAP4rev1 December 1996 + + + ;; Defined in [MIME-IMT] + +media_subtype ::= string + ;; Defined in [MIME-IMT] + +media_text ::= <"> "TEXT" <"> SPACE media_subtype + ;; Defined in [MIME-IMT] + +message_data ::= nz_number SPACE ("EXPUNGE" / + ("FETCH" SPACE msg_att)) + +msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / + "FLAGS" SPACE "(" #(flag / "\Recent") ")" / + "INTERNALDATE" SPACE date_time / + "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / + "RFC822.SIZE" SPACE number / + "BODY" ["STRUCTURE"] SPACE body / + "BODY" section ["<" number ">"] SPACE nstring / + "UID" SPACE uniqueid) ")" + +nil ::= "NIL" + +nstring ::= string / nil + +number ::= 1*digit + ;; Unsigned 32-bit integer + ;; (0 <= n < 4,294,967,296) + +nz_number ::= digit_nz *digit + ;; Non-zero unsigned 32-bit integer + ;; (0 < n < 4,294,967,296) + +password ::= astring + +quoted ::= <"> *QUOTED_CHAR <"> + +QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> / + "\" quoted_specials + +quoted_specials ::= <"> / "\" + +rename ::= "RENAME" SPACE mailbox SPACE mailbox + ;; Use of INBOX as a destination gives a NO error + +response ::= *(continue_req / response_data) response_done + +response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / + mailbox_data / message_data / capability_data) + + + +Crispin Standards Track [Page 71] + +RFC 2060 IMAP4rev1 December 1996 + + + CRLF + +response_done ::= response_tagged / response_fatal + +response_fatal ::= "*" SPACE resp_cond_bye CRLF + ;; Server closes connection immediately + +response_tagged ::= tag SPACE resp_cond_state CRLF + +resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text + ;; Authentication condition + +resp_cond_bye ::= "BYE" SPACE resp_text + +resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text + ;; Status condition + +resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) + ;; text SHOULD NOT begin with "[" or "=" + +resp_text_code ::= "ALERT" / "PARSE" / + "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDVALIDITY" SPACE nz_number / + "UNSEEN" SPACE nz_number / + atom [SPACE 1*<any TEXT_CHAR except "]">] + +search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] + 1#search_key + ;; [CHARSET] MUST be registered with IANA + +search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / + "BEFORE" SPACE date / "BODY" SPACE astring / + "CC" SPACE astring / "DELETED" / "FLAGGED" / + "FROM" SPACE astring / + "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / + "ON" SPACE date / "RECENT" / "SEEN" / + "SINCE" SPACE date / "SUBJECT" SPACE astring / + "TEXT" SPACE astring / "TO" SPACE astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / + ;; Above this line were in [IMAP2] + "DRAFT" / + "HEADER" SPACE header_fld_name SPACE astring / + "LARGER" SPACE number / "NOT" SPACE search_key / + "OR" SPACE search_key SPACE search_key / + "SENTBEFORE" SPACE date / "SENTON" SPACE date / + "SENTSINCE" SPACE date / "SMALLER" SPACE number / + + + +Crispin Standards Track [Page 72] + +RFC 2060 IMAP4rev1 December 1996 + + + "UID" SPACE set / "UNDRAFT" / set / + "(" 1#search_key ")" + +section ::= "[" [section_text / (nz_number *["." nz_number] + ["." (section_text / "MIME")])] "]" + +section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] + SPACE header_list / "TEXT" + +select ::= "SELECT" SPACE mailbox + +sequence_num ::= nz_number / "*" + ;; * is the largest number in use. For message + ;; sequence numbers, it is the number of messages + ;; in the mailbox. For unique identifiers, it is + ;; the unique identifier of the last message in + ;; the mailbox. + +set ::= sequence_num / (sequence_num ":" sequence_num) / + (set "," set) + ;; Identifies a set of messages. For message + ;; sequence numbers, these are consecutive + ;; numbers from 1 to the number of messages in + ;; the mailbox + ;; Comma delimits individual numbers, colon + ;; delimits between two numbers inclusive. + ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, + ;; 14,15 for a mailbox with 15 messages. + +SPACE ::= <ASCII SP, space, 0x20> + +status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" + +status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / + "UNSEEN" + +store ::= "STORE" SPACE set SPACE store_att_flags + +store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE + (flag_list / #flag) + +string ::= quoted / literal + +subscribe ::= "SUBSCRIBE" SPACE mailbox + +tag ::= 1*<any ATOM_CHAR except "+"> + +text ::= 1*TEXT_CHAR + + + +Crispin Standards Track [Page 73] + +RFC 2060 IMAP4rev1 December 1996 + + +text_mime2 ::= "=?" <charset> "?" <encoding> "?" + <encoded-text> "?=" + ;; Syntax defined in [MIME-HDRS] + +TEXT_CHAR ::= <any CHAR except CR and LF> + +time ::= 2digit ":" 2digit ":" 2digit + ;; Hours minutes seconds + +uid ::= "UID" SPACE (copy / fetch / search / store) + ;; Unique identifiers used instead of message + ;; sequence numbers + +uniqueid ::= nz_number + ;; Strictly ascending + +unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox + +userid ::= astring + +x_command ::= "X" atom <experimental command arguments> + +zone ::= ("+" / "-") 4digit + ;; Signed four-digit value of hhmm representing + ;; hours and minutes west of Greenwich (that is, + ;; (the amount that the given time differs from + ;; Universal Time). Subtracting the timezone + ;; from the given time will give the UT form. + ;; The Universal Time zone is "+0000". + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: RFC 1730, + unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. + +11. Security Considerations + + IMAP4rev1 protocol transactions, including electronic mail data, are + sent in the clear over the network unless privacy protection is + negotiated in the AUTHENTICATE command. + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials SHOULD NOT detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command instead. + + + +Crispin Standards Track [Page 74] + +RFC 2060 IMAP4rev1 December 1996 + + + A server error message for a failing LOGIN command SHOULD NOT specify + that the user name, as opposed to the password, is invalid. + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + +12. 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 Standards Track [Page 75] + +RFC 2060 IMAP4rev1 December 1996 + + +Appendices + +A. References + +[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", +Work in Progress. + +[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, +RFC 1700, USC/Information Sciences Institute, October 1994. + +[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation +Information in Internet Messages: The Content-Disposition Header", +RFC 1806, June 1995. + +[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. +Carnegie-Mellon University, December 1994. + +[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC +2061, University of Washington, November 1996. + +[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected +IMAP4 Clients", Work in Progress. + +[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and +IMAP2bis", RFC 1732, University of Washington, December 1994. + +[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in +IMAP4", RFC 1733, University of Washington, December 1994. + +[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - +Obsolete Syntax", RFC 2062, University of Washington, November 1996. + +[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", +RFC 1176, University of Washington, August 1990. + +[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of +Languages", RFC 1766, March 1995. + +[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC +1864, October 1995. + +[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet +Mail Extensions) Part One: Format of Internet Message Bodies", RFC +2045, November 1996. + +[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose +Internet Mail Extensions) Part Two: Media Types", RFC 2046, +November 1996. + + + +Crispin Standards Track [Page 76] + +RFC 2060 IMAP4rev1 December 1996 + + +[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) +Part Three: Message Header Extensions for Non-ASCII Text", RFC +2047, November 1996. + +[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text +Messages", STD 11, RFC 822, University of Delaware, August 1982. + +[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, +RFC 821, USC/Information Sciences Institute, August 1982. + +[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe +Transformation Format of Unicode", RFC 1642, July 1994. + +B. Changes from RFC 1730 + +1) The STATUS command has been added. + +2) Clarify in the formal syntax that the "#" construct can never +refer to multiple spaces. + +3) Obsolete syntax has been moved to a separate document. + +4) The PARTIAL command has been obsoleted. + +5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and +RFC822.TEXT.PEEK fetch attributes have been obsoleted. + +6) The "<" origin "." size ">" suffix for BODY text attributes has +been added. + +7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part +specifiers have been added. + +8) Support for Content-Disposition and Content-Language has been +added. + +9) The restriction on fetching nested MULTIPART parts has been +removed. + +10) Body part number 0 has been obsoleted. + +11) Server-supported authenticators are now identified by +capabilities. + + + + + + + + +Crispin Standards Track [Page 77] + +RFC 2060 IMAP4rev1 December 1996 + + +12) The capability that identifies this protocol is now called +"IMAP4rev1". A server that provides backwards support for RFC 1730 +SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its +CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as +the first capability, it MUST listed first in the response. + +13) A description of the mailbox name namespace convention has been +added. + +14) A description of the international mailbox name convention has +been added. + +15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT +and UIDVALIDITY. This is a change from the IMAP STATUS +Work in Progress and not from RFC-1730 + +16) Add a clarification that a null mailbox name argument to the LIST +command returns an untagged LIST response with the hierarchy +delimiter and root of the reference argument. + +17) Define terms such as "MUST", "SHOULD", and "MUST NOT". + +18) Add a section which defines message attributes and more +thoroughly details the semantics of message sequence numbers, UIDs, +and flags. + +19) Add a clarification detailing the circumstances when a client may +send multiple commands without waiting for a response, and the +circumstances in which ambiguities may result. + +20) Add a recommendation on server behavior for DELETE and RENAME +when inferior hierarchical names of the given name exist. + +21) Add a clarification that a mailbox name may not be unilaterally +unsubscribed by the server, even if that mailbox name no longer +exists. + +22) Add a clarification that LIST should return its results quickly +without undue delay. + +23) Add a clarification that the date_time argument to APPEND sets +the internal date of the message. + +24) Add a clarification on APPEND behavior when the target mailbox is +the currently selected mailbox. + + + + + + +Crispin Standards Track [Page 78] + +RFC 2060 IMAP4rev1 December 1996 + + +25) Add a clarification that external changes to flags should be +always announced via an untagged FETCH even if the current command is +a STORE with the ".SILENT" suffix. + +26) Add a clarification that COPY appends to the target mailbox. + +27) Add the NEWNAME response code. + +28) Rewrite the description of the untagged BYE response to clarify +its semantics. + +29) Change the reference for the body MD5 to refer to the proper RFC. + +30) Clarify that the formal syntax contains rules which may overlap, +and that in the event of such an overlap the rule which occurs first +takes precedence. + +31) Correct the definition of body_fld_param. + +32) More formal syntax for capability_data. + +33) Clarify that any case variant of "INBOX" must be interpreted as +INBOX. + +34) Clarify that the human-readable text in resp_text should not +begin with "[" or "=". + +35) Change MIME references to Draft Standard documents. + +36) Clarify \Recent semantics. + +37) Additional examples. + +C. Key Word Index + + +FLAGS <flag list> (store command data item) ............... 45 + +FLAGS.SILENT <flag list> (store command data item) ........ 46 + -FLAGS <flag list> (store command data item) ............... 46 + -FLAGS.SILENT <flag list> (store command data item) ........ 46 + ALERT (response code) ...................................... 50 + ALL (fetch item) ........................................... 41 + ALL (search key) ........................................... 38 + ANSWERED (search key) ...................................... 38 + APPEND (command) ........................................... 34 + AUTHENTICATE (command) ..................................... 20 + BAD (response) ............................................. 52 + BCC <string> (search key) .................................. 38 + BEFORE <date> (search key) ................................. 39 + + + +Crispin Standards Track [Page 79] + +RFC 2060 IMAP4rev1 December 1996 + + + BODY (fetch item) .......................................... 41 + BODY (fetch result) ........................................ 58 + BODY <string> (search key) ................................. 39 + BODY.PEEK[<section>]<<partial>> (fetch item) ............... 44 + BODYSTRUCTURE (fetch item) ................................. 44 + BODYSTRUCTURE (fetch result) ............................... 59 + BODY[<section>]<<origin_octet>> (fetch result) ............. 58 + BODY[<section>]<<partial>> (fetch item) .................... 41 + BYE (response) ............................................. 52 + Body Structure (message attribute) ......................... 11 + CAPABILITY (command) ....................................... 18 + CAPABILITY (response) ...................................... 53 + CC <string> (search key) ................................... 39 + CHECK (command) ............................................ 36 + CLOSE (command) ............................................ 36 + COPY (command) ............................................. 46 + CREATE (command) ........................................... 25 + DELETE (command) ........................................... 26 + DELETED (search key) ....................................... 39 + DRAFT (search key) ......................................... 39 + ENVELOPE (fetch item) ...................................... 44 + ENVELOPE (fetch result) .................................... 62 + EXAMINE (command) .......................................... 24 + EXISTS (response) .......................................... 56 + EXPUNGE (command) .......................................... 37 + EXPUNGE (response) ......................................... 57 + Envelope Structure (message attribute) ..................... 11 + FAST (fetch item) .......................................... 44 + FETCH (command) ............................................ 41 + FETCH (response) ........................................... 58 + FLAGGED (search key) ....................................... 39 + FLAGS (fetch item) ......................................... 44 + FLAGS (fetch result) ....................................... 62 + FLAGS (response) ........................................... 56 + FLAGS <flag list> (store command data item) ................ 45 + FLAGS.SILENT <flag list> (store command data item) ......... 45 + FROM <string> (search key) ................................. 39 + FULL (fetch item) .......................................... 44 + Flags (message attribute) .................................. 9 + HEADER (part specifier) .................................... 41 + HEADER <field-name> <string> (search key) .................. 39 + HEADER.FIELDS <header_list> (part specifier) ............... 41 + HEADER.FIELDS.NOT <header_list> (part specifier) ........... 41 + INTERNALDATE (fetch item) .................................. 44 + INTERNALDATE (fetch result) ................................ 62 + Internal Date (message attribute) .......................... 10 + KEYWORD <flag> (search key) ................................ 39 + Keyword (type of flag) ..................................... 10 + + + +Crispin Standards Track [Page 80] + +RFC 2060 IMAP4rev1 December 1996 + + + LARGER <n> (search key) .................................... 39 + LIST (command) ............................................. 30 + LIST (response) ............................................ 54 + LOGIN (command) ............................................ 22 + LOGOUT (command) ........................................... 20 + LSUB (command) ............................................. 32 + LSUB (response) ............................................ 55 + MAY (specification requirement term) ....................... 5 + MESSAGES (status item) ..................................... 33 + MIME (part specifier) ...................................... 42 + MUST (specification requirement term) ...................... 4 + MUST NOT (specification requirement term) .................. 4 + Message Sequence Number (message attribute) ................ 9 + NEW (search key) ........................................... 39 + NEWNAME (response code) .................................... 50 + NO (response) .............................................. 51 + NOOP (command) ............................................. 19 + NOT <search-key> (search key) .............................. 39 + OK (response) .............................................. 51 + OLD (search key) ........................................... 39 + ON <date> (search key) ..................................... 39 + OPTIONAL (specification requirement term) .................. 5 + OR <search-key1> <search-key2> (search key) ................ 39 + PARSE (response code) ...................................... 50 + PERMANENTFLAGS (response code) ............................. 50 + PREAUTH (response) ......................................... 52 + Permanent Flag (class of flag) ............................. 10 + READ-ONLY (response code) .................................. 50 + READ-WRITE (response code) ................................. 50 + RECENT (response) .......................................... 57 + RECENT (search key) ........................................ 39 + RECENT (status item) ....................................... 33 + RENAME (command) ........................................... 27 + REQUIRED (specification requirement term) .................. 4 + RFC822 (fetch item) ........................................ 44 + RFC822 (fetch result) ...................................... 63 + RFC822.HEADER (fetch item) ................................. 44 + RFC822.HEADER (fetch result) ............................... 62 + RFC822.SIZE (fetch item) ................................... 44 + RFC822.SIZE (fetch result) ................................. 62 + RFC822.TEXT (fetch item) ................................... 44 + RFC822.TEXT (fetch result) ................................. 62 + SEARCH (command) ........................................... 37 + SEARCH (response) .......................................... 55 + SEEN (search key) .......................................... 40 + SELECT (command) ........................................... 23 + SENTBEFORE <date> (search key) ............................. 40 + SENTON <date> (search key) ................................. 40 + + + +Crispin Standards Track [Page 81] + +RFC 2060 IMAP4rev1 December 1996 + + + SENTSINCE <date> (search key) .............................. 40 + SHOULD (specification requirement term) .................... 5 + SHOULD NOT (specification requirement term) ................ 5 + SINCE <date> (search key) .................................. 40 + SMALLER <n> (search key) ................................... 40 + STATUS (command) ........................................... 33 + STATUS (response) .......................................... 55 + STORE (command) ............................................ 45 + SUBJECT <string> (search key) .............................. 40 + SUBSCRIBE (command) ........................................ 29 + Session Flag (class of flag) ............................... 10 + System Flag (type of flag) ................................. 9 + TEXT (part specifier) ...................................... 42 + TEXT <string> (search key) ................................. 40 + TO <string> (search key) ................................... 40 + TRYCREATE (response code) .................................. 51 + UID (command) .............................................. 47 + UID (fetch item) ........................................... 44 + UID (fetch result) ......................................... 63 + UID <message set> (search key) ............................. 40 + UIDNEXT (status item) ...................................... 33 + UIDVALIDITY (response code) ................................ 51 + UIDVALIDITY (status item) .................................. 34 + UNANSWERED (search key) .................................... 40 + UNDELETED (search key) ..................................... 40 + UNDRAFT (search key) ....................................... 40 + UNFLAGGED (search key) ..................................... 40 + UNKEYWORD <flag> (search key) .............................. 40 + UNSEEN (response code) ..................................... 51 + UNSEEN (search key) ........................................ 40 + UNSEEN (status item) ....................................... 34 + UNSUBSCRIBE (command) ...................................... 30 + Unique Identifier (UID) (message attribute) ................ 7 + X<atom> (command) .......................................... 48 + [RFC-822] Size (message attribute) ......................... 11 + \Answered (system flag) .................................... 9 + \Deleted (system flag) ..................................... 9 + \Draft (system flag) ....................................... 9 + \Flagged (system flag) ..................................... 9 + \Marked (mailbox name attribute) ........................... 54 + \Noinferiors (mailbox name attribute) ...................... 54 + \Noselect (mailbox name attribute) ......................... 54 + \Recent (system flag) ...................................... 10 + \Seen (system flag) ........................................ 9 + \Unmarked (mailbox name attribute) ......................... 54 + + + + + + +Crispin Standards Track [Page 82] + diff --git a/RFC/rfc2061.txt b/RFC/rfc2061.txt new file mode 100644 index 00000000..7cb02bb2 --- /dev/null +++ b/RFC/rfc2061.txt @@ -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] + diff --git a/RFC/rfc2062.txt b/RFC/rfc2062.txt new file mode 100644 index 00000000..865d1dad --- /dev/null +++ b/RFC/rfc2062.txt @@ -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] + diff --git a/RFC/rfc2177.txt b/RFC/rfc2177.txt new file mode 100644 index 00000000..ef28fad3 --- /dev/null +++ b/RFC/rfc2177.txt @@ -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]
+
diff --git a/RFC/rfc2195.txt b/RFC/rfc2195.txt new file mode 100644 index 00000000..4a2725bf --- /dev/null +++ b/RFC/rfc2195.txt @@ -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] + diff --git a/RFC/rfc2449.txt b/RFC/rfc2449.txt new file mode 100644 index 00000000..dbea10b2 --- /dev/null +++ b/RFC/rfc2449.txt @@ -0,0 +1,1067 @@ +
+
+
+
+
+
+Network Working Group R. Gellens
+Request for Comments: 2449 Qualcomm
+Updates: 1939 C. Newman
+Category: Standards Track Innosoft
+ L. Lundblade
+ Qualcomm
+ November 1998
+
+
+ POP3 Extension 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 (1998). All Rights Reserved.
+
+IESG Note
+
+ This extension to the POP3 protocol is to be used by a server to
+ express policy descisions taken by the server administrator. It is
+ not an endorsement of implementations of further POP3 extensions
+ generally. It is the general view that the POP3 protocol should stay
+ simple, and for the simple purpose of downloading email from a mail
+ server. If more complicated operations are needed, the IMAP protocol
+ [RFC 2060] should be used. The first paragraph of section 7 should
+ be read very carefully.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions Used in this Document . . . . . . . . . . . . . 3
+ 3. General Command and Response Grammar . . . . . . . . . . . . 3
+ 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
+ 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
+ 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
+ 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
+ 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
+ 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
+ 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
+ 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
+
+
+
+Gellens, et. al. Standards Track [Page 1]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
+ 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
+ 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
+ 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
+ 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
+ 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
+ 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
+ 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . 17
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
+ 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
+
+1. Introduction
+
+ The Post Office Protocol version 3 [POP3] is very widely used.
+ However, while it includes some optional commands (and some useful
+ protocol extensions have been published), it lacks a mechanism for
+ advertising support for these extensions or for behavior variations.
+
+ Currently these optional features and extensions can only be detected
+ by probing, if at all. This is at best inefficient, and possibly
+ worse. As a result, some clients have manual configuration options
+ for POP3 server capabilities.
+
+ Because one of the most important characteristics of POP3 is its
+ simplicity, it is desirable that extensions be few in number (see
+ section 7). However, some extensions are necessary (such as ones
+ that provide improved security [POP-AUTH]), while others are very
+ desirable in certain situations. In addition, a means for
+ discovering server behavior is needed.
+
+ This memo updates RFC 1939 [POP3] to define a mechanism to announce
+ support for optional commands, extensions, and unconditional server
+ behavior. Included is an initial set of currently deployed
+ capabilities which vary between server implementations, and several
+ new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE
+ and IMPLEMENTATION). This document also extends POP3 error messages
+ so that machine parsable codes can be provided to the client. An
+ initial set of response codes is included. In addition, an [ABNF]
+ specification of POP3 commands and responses is defined.
+
+ Public comments should be sent to the IETF POP3 Extensions mailing
+ list, <ietf-pop3ext@imc.org>. To subscribe, send a message
+ containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.
+
+
+
+
+Gellens, et. al. Standards Track [Page 2]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+2. Conventions Used in this Document
+
+ The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
+ and "MAY" in this document are to be interpreted as described in "Key
+ words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+3. General Command and Response Grammar
+
+ The general form of POP3 commands and responses is described using
+ [ABNF]:
+
+ POP3 commands:
+
+ command = keyword *(SP param) CRLF ;255 octets maximum
+ keyword = 3*4VCHAR
+ param = 1*VCHAR
+
+ POP3 responses:
+
+ response = greeting / single-line / capa-resp / multi-line
+ capa-resp = single-line *capability "." CRLF
+ capa-tag = 1*cchar
+ capability = capa-tag *(SP param) CRLF ;512 octets maximum
+ cchar = %x21-2D / %x2F-7F
+ ;printable ASCII, excluding "."
+ dot-stuffed = *CHAR CRLF ;must be dot-stuffed
+ gchar = %x21-3B / %x3D-7F
+ ;printable ASCII, excluding "<"
+ greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
+ ;512 octets maximum
+ multi-line = single-line *dot-stuffed "." CRLF
+ rchar = %x21-2E / %x30-5C / %x5E-7F
+ ;printable ASCII, excluding "/" and "]"
+ resp-code = "[" resp-level *("/" resp-level) "]"
+ resp-level = 1*rchar
+ schar = %x21-5A / %x5C-7F
+ ;printable ASCII, excluding "["
+ single-line = status [SP text] CRLF ;512 octets maximum
+ status = "+OK" / "-ERR"
+ text = *schar / resp-code *CHAR
+ timestamp = "<" *VCHAR ">"
+ ;MUST conform to RFC-822 msg-id
+
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 3]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+4. Parameter and Response Lengths
+
+ This specification increases the length restrictions on commands and
+ parameters imposed by RFC 1939.
+
+ The maximum length of a command is increased from 47 characters (4
+ character command, single space, 40 character argument, CRLF) to 255
+ octets, including the terminating CRLF.
+
+ Servers which support the CAPA command MUST support commands up to
+ 255 octets. Servers MUST also support the largest maximum command
+ length specified by any supported capability.
+
+ The maximum length of the first line of a command response (including
+ the initial greeting) is unchanged at 512 octets (including the
+ terminating CRLF).
+
+5. The CAPA Command
+
+ The POP3 CAPA command returns a list of capabilities supported by the
+ POP3 server. It is available in both the AUTHORIZATION and
+ TRANSACTION states.
+
+ A capability description MUST document in which states the capability
+ is announced, and in which states the commands are valid.
+
+ Capabilities available in the AUTHORIZATION state MUST be announced
+ in both states.
+
+ If a capability is announced in both states, but the argument might
+ differ after authentication, this possibility MUST be stated in the
+ capability description.
+
+ (These requirements allow a client to issue only one CAPA command if
+ it does not use any TRANSACTION-only capabilities, or any
+ capabilities whose values may differ after authentication.)
+
+ If the authentication step negotiates an integrity protection layer,
+ the client SHOULD reissue the CAPA command after authenticating, to
+ check for active down-negotiation attacks.
+
+ Each capability may enable additional protocol commands, additional
+ parameters and responses for existing commands, or describe an aspect
+ of server behavior. These details are specified in the description
+ of the capability.
+
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 4]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ Section 3 describes the CAPA response using [ABNF]. When a
+ capability response describes an optional command, the <capa-tag>
+ SHOULD be identical to the command keyword. CAPA response tags are
+ case-insensitive.
+
+ CAPA
+
+ Arguments:
+ none
+
+ Restrictions:
+ none
+
+ Discussion:
+ An -ERR response indicates the capability command is not
+ implemented and the client will have to probe for
+ capabilities as before.
+
+ An +OK response is followed by a list of capabilities, one
+ per line. Each capability name MAY be followed by a single
+ space and a space-separated list of parameters. Each
+ capability line is limited to 512 octets (including the
+ CRLF). The capability list is terminated by a line
+ containing a termination octet (".") and a CRLF pair.
+
+ Possible Responses:
+ +OK -ERR
+
+ Examples:
+ C: CAPA
+ S: +OK Capability list follows
+ S: TOP
+ S: USER
+ S: SASL CRAM-MD5 KERBEROS_V4
+ S: RESP-CODES
+ S: LOGIN-DELAY 900
+ S: PIPELINING
+ S: EXPIRE 60
+ S: UIDL
+ S: IMPLEMENTATION Shlemazle-Plotz-v302
+ S: .
+
+6. Initial Set of Capabilities
+
+ This section defines an initial set of POP3 capabilities. These
+ include the optional POP3 commands, already published POP3
+ extensions, and behavior variations between POP3 servers which can
+ impact clients.
+
+
+
+Gellens, et. al. Standards Track [Page 5]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ Note that there is no APOP capability, even though APOP is an
+ optional command in [POP3]. Clients discover server support of APOP
+ by the presence in the greeting banner of an initial challenge
+ enclosed in angle brackets ("<>"). Therefore, an APOP capability
+ would introduce two ways for a server to announce the same thing.
+
+6.1. TOP capability
+
+ CAPA tag:
+ TOP
+
+ Arguments:
+ none
+
+ Added commands:
+ TOP
+
+ Standard commands affected:
+ none
+
+ Announced states / possible differences:
+ both / no
+
+ Commands valid in states:
+ TRANSACTION
+
+ Specification reference:
+ [POP3]
+
+ Discussion:
+ The TOP capability indicates the optional TOP command is
+ available.
+
+6.2. USER capability
+
+ CAPA tag:
+ USER
+
+ Arguments:
+ none
+
+ Added commands:
+ USER PASS
+
+ Standard commands affected:
+ none
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 6]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ Announced states / possible differences:
+ both / no
+
+ Commands valid in states:
+ AUTHENTICATION
+
+ Specification reference:
+ [POP3]
+
+ Discussion:
+ The USER capability indicates that the USER and PASS commands
+ are supported, although they may not be available to all users.
+
+6.3. SASL capability
+
+ CAPA tag:
+ SASL
+
+ Arguments:
+ Supported SASL mechanisms
+
+ Added commands:
+ AUTH
+
+ Standard commands affected:
+ none
+
+ Announced states / possible differences:
+ both / no
+
+ Commands valid in states:
+ AUTHENTICATION
+
+ Specification reference:
+ [POP-AUTH, SASL]
+
+ Discussion:
+ The POP3 AUTH command [POP-AUTH] permits the use of [SASL]
+ authentication mechanisms with POP3. The SASL capability
+ indicates that the AUTH command is available and that it supports
+ an optional base64 encoded second argument for an initial client
+ response as described in the SASL specification. The argument to
+ the SASL capability is a space separated list of SASL mechanisms
+ which are supported.
+
+
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 7]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+6.4. RESP-CODES capability
+
+ CAPA tag:
+ RESP-CODES
+
+ 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 RESP-CODES capability indicates that any response text issued
+ by this server which begins with an open square bracket ("[") is
+ an extended response code (see section 8).
+
+6.5. LOGIN-DELAY capability
+
+ CAPA tag:
+ LOGIN-DELAY
+
+ Arguments:
+ minimum seconds between logins; optionally followed by USER in
+ AUTHENTICATION state.
+
+ Added commands:
+ none
+
+ Standard commands affected:
+ USER PASS APOP AUTH
+
+ Announced states / possible differences:
+ both / yes
+
+ Commands valid in states:
+ n/a
+
+
+
+Gellens, et. al. Standards Track [Page 8]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ Specification reference:
+ this document
+
+ Discussion:
+ POP3 clients often login frequently to check for new mail.
+ Unfortunately, the process of creating a connection,
+ authenticating the user, and opening the user's maildrop can be
+ very resource intensive on the server. A number of deployed POP3
+ servers try to reduce server load by requiring a delay between
+ logins. The LOGIN-DELAY capability includes an integer argument
+ which indicates the number of seconds after an "+OK" response to
+ a PASS, APOP, or AUTH command before another authentication will
+ be accepted. Clients which permit the user to configure a mail
+ check interval SHOULD use this capability to determine the
+ minimum permissible interval. Servers which advertise LOGIN-
+ DELAY SHOULD enforce it.
+
+ If the minimum login delay period could differ per user (that is,
+ the LOGIN-DELAY argument might change after authentication), the
+ server MUST announce in AUTHENTICATION state the largest value
+ which could be set for any user. This might be the largest value
+ currently in use for any user (so only one value per server), or
+ even the largest value which the server permits to be set for any
+ user. The server SHOULD append the token "USER" to the LOGIN-
+ DELAY parameter in AUTHENTICATION state, to inform the client
+ that a more accurate value is available after authentication.
+ The server SHOULD announce the more accurate value in TRANSACTION
+ state. (The "USER" token allows the client to decide if a second
+ CAPA command is needed or not.)
+
+ Servers enforce LOGIN-DELAY by rejecting an authentication
+ command with or without the LOGIN-DELAY error response. See
+ section 8.1.1 for more information.
+
+6.6. PIPELINING capability
+
+ CAPA tag:
+ PIPELINING
+
+ Arguments:
+ none
+
+ Added commands:
+ none
+
+ Standard commands affected:
+ all
+
+
+
+
+Gellens, et. al. Standards Track [Page 9]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ Announced states / possible differences:
+ both / no
+
+ Commands valid in states:
+ n/a
+
+ Specification reference:
+ this document
+
+ Discussion:
+ The PIPELINING capability indicates the server is capable of
+ accepting multiple commands at a time; the client does not have
+ to wait for the response to a command before issuing a subsequent
+ command. If a server supports PIPELINING, it MUST process each
+ command in turn. If a client uses PIPELINING, it MUST keep track
+ of which commands it has outstanding, and match server responses
+ to commands in order. If either the client or server uses
+ blocking writes, it MUST not exceed the window size of the
+ underlying transport layer.
+
+ Some POP3 clients have an option to indicate the server supports
+ "Overlapped POP3 commands." This capability removes the need to
+ configure this at the client.
+
+ This is roughly synonymous with the ESMTP PIPELINING extension
+ [PIPELINING], however, since SMTP [SMTP] tends to have short
+ commands and responses, the benefit is in grouping multiple
+ commands and sending them as a unit. While there are cases of
+ this in POP (for example, USER and PASS could be batched,
+ multiple RETR and/or DELE commands could be sent as a group),
+ because POP has short commands and sometimes lengthy responses,
+ there is also an advantage is sending new commands while still
+ receiving the response to an earlier command (for example,
+ sending RETR and/or DELE commands while processing a UIDL reply).
+
+6.7. EXPIRE capability
+
+ CAPA tag:
+ EXPIRE
+
+ Arguments:
+ server-guaranteed minimum retention days, or NEVER; optionally
+ followed by USER in AUTHENTICATION state
+
+ Added commands:
+ none
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 10]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ Standard commands affected:
+ none
+
+ Announced states / possible differences:
+ both / yes
+
+ Commands valid in states:
+ n/a
+
+ Specification reference:
+ this document
+
+ Discussion:
+ While POP3 allows clients to leave messages on the server, RFC
+ 1939 [POP3] warns about the problems that may arise from this,
+ and allows servers to delete messages based on site policy.
+
+ The EXPIRE capability avoids the problems mentioned in RFC 1939,
+ by allowing the server to inform the client as to the policy in
+ effect. The argument to the EXPIRE capability indicates the
+ minimum server retention period, in days, for messages on the
+ server.
+
+ EXPIRE 0 indicates the client is not permitted to leave mail on
+ the server; when the session enters the UPDATE state the server
+ MAY assume an implicit DELE for each message which was downloaded
+ with RETR.
+
+ EXPIRE NEVER asserts that the server does not delete messages.
+
+ The concept of a "retention period" is intentionally vague.
+ Servers may start counting days to expiration when a message is
+ added to a maildrop, when a client becomes aware of the existence
+ of a message through the LIST or UIDL commands, when a message
+ has been acted upon in some way (for example, TOP or RETR), or at
+ some other event. The EXPIRE capability cannot provide a precise
+ indication as to exactly when any specific message will expire.
+ The capability is intended to make it easier for clients to
+ behave in ways which conform to site policy and user wishes. For
+ example, a client might display a warning for attempts to
+ configure a "leave mail on server" period which is greater than
+ or equal to some percentage of the value announced by the server.
+
+ If a site uses any automatic deletion policy, it SHOULD use the
+ EXPIRE capability to announce this.
+
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 11]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ The EXPIRE capability, with a parameter other than 0 or NEVER, is
+ intended to let the client know that the server does permit mail
+ to be left on the server, and to present a value which is the
+ smallest which might be in force.
+
+ Sites which permit users to retain messages indefinitely SHOULD
+ announce this with the EXPIRE NEVER response.
+
+ If the expiration policy differs per user (that is, the EXPIRE
+ argument might change after authentication), the server MUST
+ announce in AUTHENTICATION state the smallest value which could
+ be set for any user. This might be the smallest value currently
+ in use for any user (so only one value per server), or even the
+ smallest value which the server permits to be set for any user.
+ The server SHOULD append the token "USER" to the EXPIRE parameter
+ in AUTHENTICATION state, to inform the client that a more
+ accurate value is available after authentication. The server
+ SHOULD announce the more accurate value in TRANSACTION state.
+ (The "USER" token allows the client to decide if a second CAPA
+ command is needed or not.)
+
+ A site may have a message expiration policy which treats messages
+ differently depending on which user actions have been performed,
+ or based on other factors. For example, a site might delete
+ unseen messages after 60 days, and completely- or partially-seen
+ messages after 15 days.
+
+ The announced EXPIRE value is the smallest retention period which
+ is or might be used by any category or condition of the current
+ site policy, for any user (in AUTHENTICATION state) or the
+ specific user (in TRANSACTION state). That is, EXPIRE informs
+ the client of the minimum number of days messages may remain on
+ the server under any circumstances.
+
+ Examples:
+ EXPIRE 5 USER
+ EXPIRE 30
+ EXPIRE NEVER
+ EXPIRE 0
+
+ The first example indicates the server might delete messages
+ after five days, but the period differs per user, and so a more
+ accurate value can be obtained by issuing a second CAPA command
+ in TRANSACTION state. The second example indicates the server
+ could delete messages after 30 days. In the third example, the
+ server announces it does not delete messages. The fourth example
+ specifies that the site does not permit messages to be left on
+ the server.
+
+
+
+Gellens, et. al. Standards Track [Page 12]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+6.8. UIDL capability
+
+ CAPA tag:
+ UIDL
+
+ Arguments:
+ none
+
+ Added commands:
+ UIDL
+
+ Standard commands affected:
+ none
+
+ Announced states / possible differences:
+ both / no
+
+ Commands valid in states:
+ TRANSACTION
+
+ Specification reference:
+ [POP3]
+
+ Discussion:
+ The UIDL capability indicates that the optional UIDL command is
+ supported.
+
+6.9. IMPLEMENTATION capability
+
+ CAPA tag:
+ IMPLEMENTATION
+
+ Arguments:
+ string giving server implementation information
+
+ Added commands:
+ none
+
+ Standard commands affected:
+ none
+
+ Announced states / possible differences:
+ both (optionally TRANSACTION only) / no
+
+ Commands valid in states:
+ n/a
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 13]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ Specification reference:
+ this document
+
+ Discussion:
+ It is often useful to identify an implementation of a particular
+ server (for example, when logging). This is commonly done in the
+ welcome banner, but one must guess if a string is an
+ implementation ID or not.
+
+ The argument to the IMPLEMENTATION capability consists of one or
+ more tokens which identify the server. (Note that since CAPA
+ response tag arguments are space-separated, it may be convenient
+ for the IMPLEMENTATION capability argument to not contain spaces,
+ so that it is a single token.)
+
+ Normally, servers announce IMPLEMENTATION in both states.
+ However, a server MAY chose to do so only in TRANSACTION state.
+
+ A server MAY include the implementation identification both in
+ the welcome banner and in the IMPLEMENTATION capability.
+
+ Clients MUST NOT modify their behavior based on the server
+ implementation. Instead the server and client should agree on a
+ private extension.
+
+7. Future Extensions to POP3
+
+ Future extensions to POP3 are in general discouraged, as POP3's
+ usefulness lies in its simplicity. POP3 is intended as a download-
+ and-delete protocol; mail access capabilities are available in IMAP
+ [IMAP4]. Extensions which provide support for additional mailboxes,
+ allow uploading of messages to the server, or which deviate from
+ POP's download-and-delete model are strongly discouraged and unlikely
+ to be permitted on the IETF standards track.
+
+ Clients MUST NOT require the presence of any extension for basic
+ functionality, with the exception of the authentication commands
+ (APOP, AUTH [section 6.3] and USER/PASS).
+
+ Section 9 specifies how additional capabilities are defined.
+
+8. Extended POP3 Response Codes
+
+ Unextended POP3 is only capable of indicating success or failure to
+ most commands. Unfortunately, clients often need to know more
+ information about the cause of a failure in order to gracefully
+ recover. This is especially important in response to a failed login
+
+
+
+
+Gellens, et. al. Standards Track [Page 14]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ (there are widely-deployed clients which attempt to decode the error
+ text of a PASS command result, to try and distinguish between "unable
+ to get maildrop lock" and "bad login").
+
+ This specification amends the POP3 standard to permit an optional
+ response code, enclosed in square brackets, at the beginning of the
+ human readable text portion of an "+OK" or "-ERR" response. Clients
+ supporting this extension MAY remove any information enclosed in
+ square brackets prior to displaying human readable text to the user.
+ Immediately following the open square bracket "[" character is a
+ response code which is interpreted in a case-insensitive fashion by
+ the client.
+
+ The response code is hierarchical, with a "/" separating levels of
+ detail about the error. Clients MUST ignore unknown hierarchical
+ detail about the response code. This is important, as it could be
+ necessary to provide further detail for response codes in the future.
+
+ Section 3 describes response codes using [ABNF].
+
+ If a server supports extended response codes, it indicates this by
+ including the RESP-CODES capability in the CAPA response.
+
+ Examples:
+ C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+ S: -ERR [IN-USE] Do you have another POP session running?
+
+8.1. Initial POP3 response codes
+
+ This specification defines two POP3 response codes which can be used
+ to determine the reason for a failed login. Section 9 specifies how
+ additional response codes are defined.
+
+8.1.1. The LOGIN-DELAY response code
+
+ This occurs on an -ERR response to an AUTH, USER (see note), PASS or
+ APOP command and indicates that the user has logged in recently and
+ will not be allowed to login again until the login delay period has
+ expired.
+
+ NOTE: Returning the LOGIN-DELAY response code to the USER command
+ avoids the work of authenticating the user but reveals to the client
+ that the specified user exists. Unless the server is operating in an
+ environment where user names are not secret (for example, many
+ popular email clients advertise the POP server and user name in an
+ outgoing mail header), or where server access is restricted, or the
+ server can verify that the connection is to the same user, it is
+
+
+
+
+Gellens, et. al. Standards Track [Page 15]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ strongly recommended that the server not issue this response code to
+ the USER command. The server still saves the cost of opening the
+ maildrop, which in some environments is the most expensive step.
+
+8.1.2. The IN-USE response code
+
+ This occurs on an -ERR response to an AUTH, APOP, or PASS command.
+ It indicates the authentication was successful, but the user's
+ maildrop is currently in use (probably by another POP3 client).
+
+9. IANA Considerations
+
+ This document requests that IANA maintain two new registries: POP3
+ capabilities and POP3 response codes.
+
+ New POP3 capabilities MUST be defined in a standards track or IESG
+ approved experimental RFC, and MUST NOT begin with the letter "X".
+
+ New POP3 capabilities MUST include the following information:
+ CAPA tag
+ Arguments
+ Added commands
+ Standard commands affected
+ Announced states / possible differences
+ Commands valid in states
+ Specification reference
+ Discussion
+
+ In addition, new limits for POP3 command and response lengths may
+ need to be included.
+
+ New POP3 response codes MUST be defined in an RFC or other permanent
+ and readily available reference, in sufficient detail so that
+ interoperability between independent implementations is possible.
+ (This is the "Specification Required" policy described in [IANA]).
+
+ New POP3 response code specifications MUST include the following
+ information: the complete response code, for which responses (+OK
+ or -ERR) and commands it is valid, and a definition of its meaning and
+ expected client behavior.
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 16]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+10. Security Considerations
+
+ A capability list can reveal information about the server's
+ authentication mechanisms which can be used to determine if certain
+ attacks will be successful. However, allowing clients to
+ automatically detect availability of stronger mechanisms and alter
+ their configurations to use them can improve overall security at a
+ site.
+
+ Section 8.1 discusses the security issues related to use of the
+ LOGIN-DELAY response code with the USER command.
+
+11. Acknowledgments
+
+ This document has been revised in part based on comments and
+ discussions which took place on and off the IETF POP3 Extensions
+ mailing list. The help of those who took the time to review this
+ memo and make suggestions is appreciated, especially that of Alexey
+ Melnikov, Harald Alvestrand, and Mike Gahrns.
+
+12. References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [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", BCP 14, RFC 2119, March 1997.
+
+ [PIPELINING] Freed, N., "SMTP Service Extension for Command
+ Pipelining", RFC 2197, September 1997.
+
+ [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
+ 3", STD 53, RFC 1939, May 1996.
+
+ [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+ December 1994.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 17]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+ [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+13. Authors' Addresses
+
+ Randall Gellens
+ QUALCOMM Incorporated
+ 6455 Lusk Blvd.
+ San Diego, CA 92121-2779
+ USA
+
+ Phone: +1 619 651 5115
+ Fax: +1 619 845 7268
+ EMail: randy@qualcomm.com
+
+
+ Chris Newman
+ Innosoft International, Inc.
+ 1050 Lakes Drive
+ West Covina, CA 91790
+ USA
+
+ EMail: chris.newman@innosoft.com
+
+
+ Laurence Lundblade
+ QUALCOMM Incorporated
+ 6455 Lusk Blvd.
+ San Diego, Ca, 92121-2779
+ USA
+
+ Phone: +1 619 658 3584
+ Fax: +1 619 845 7268
+ EMail: lgl@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 18]
+
+RFC 2449 POP3 Extension Mechanism November 1998
+
+
+14. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens, et. al. Standards Track [Page 19]
+
diff --git a/RFC/rfc2554.txt b/RFC/rfc2554.txt new file mode 100644 index 00000000..2922deae --- /dev/null +++ b/RFC/rfc2554.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 2554 Netscape Communications +Category: Standards Track March 1999 + + + SMTP Service Extension + for Authentication + +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 (1999). All Rights Reserved. + + +1. Introduction + + This document defines an SMTP service extension [ESMTP] whereby an + SMTP client may indicate an authentication mechanism to the server, + perform an authentication protocol exchange, and optionally negotiate + a security layer for subsequent protocol interactions. This + extension is a profile of the Simple Authentication and Security + Layer [SASL]. + + +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]. + + +3. The Authentication service extension + + + (1) the name of the SMTP service extension is "Authentication" + + (2) the EHLO keyword value associated with this extension is "AUTH" + + + + +Myers Standards Track [Page 1] + +RFC 2554 SMTP Authentication March 1999 + + + (3) The AUTH EHLO keyword contains as a parameter a space separated + list of the names of supported SASL mechanisms. + + (4) a new SMTP verb "AUTH" is defined + + (5) an optional parameter using the keyword "AUTH" is added to the + MAIL FROM command, and extends the maximum line length of the + MAIL FROM command by 500 characters. + + (6) this extension is appropriate for the submission protocol + [SUBMIT]. + + +4. The AUTH command + + AUTH mechanism [initial-response] + + Arguments: + a string identifying a SASL authentication mechanism. + an optional base64-encoded response + + Restrictions: + After an AUTH command has successfully completed, no more AUTH + commands may be issued in the same session. After a successful + AUTH command completes, a server MUST reject any further AUTH + commands with a 503 reply. + + The AUTH command is not permitted during a mail transaction. + + 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 security layer for subsequent protocol + interactions. If the requested authentication mechanism is not + supported, the server rejects the AUTH command with a 504 + reply. + + 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 334 reply with the text part + containing 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 issues a line + with a single "*". If the server receives such an answer, it + MUST reject the AUTH command by sending a 501 reply. + + + +Myers Standards Track [Page 2] + +RFC 2554 SMTP Authentication March 1999 + + + The optional initial-response argument to the AUTH command is + used to save a round trip when using authentication mechanisms + that are defined to send no data in the initial challenge. + When the initial-response argument is used with such a + mechanism, the initial empty challenge is not sent to the + client and the server uses the data in the initial-response + argument as if it were sent in response to the empty challenge. + Unlike a zero-length client answer to a 334 reply, a zero- + length initial response is sent as a single equals sign ("="). + If the client uses an initial-response argument to the AUTH + command with a mechanism that sends data in the initial + challenge, the server rejects the AUTH command with a 535 + reply. + + If the server cannot BASE64 decode the argument, it rejects the + AUTH command with a 501 reply. If the server rejects the + authentication data, it SHOULD reject the AUTH command with a + 535 reply unless a more specific error code, such as one listed + in section 6, is appropriate. Should the client successfully + complete the authentication exchange, the SMTP server issues a + 235 reply. + + The service name specified by this protocol's profile of SASL + is "smtp". + + If a security layer is negotiated through the SASL + authentication exchange, it takes effect immediately following + the CRLF that concludes the authentication exchange for the + client, and the CRLF of the success reply for the server. Upon + a security layer's taking effect, the SMTP protocol is reset to + the initial state (the state in SMTP after a server issues a + 220 service ready greeting). The server MUST discard any + knowledge obtained from the client, such as the argument to the + EHLO command, which was not obtained from the SASL negotiation + itself. The client MUST discard any knowledge obtained from + the server, such as the list of SMTP service extensions, which + was not obtained from the SASL negotiation itself (with the + exception that a client MAY compare the list of advertised SASL + mechanisms before and after authentication in order to detect + an active down-negotiation attack). The client SHOULD send an + EHLO command as the first command after a successful SASL + negotiation which results in the enabling of a security layer. + + The server is not required to support any particular + authentication mechanism, nor are authentication mechanisms + required to support any security layers. If an AUTH command + fails, the client may try another authentication mechanism by + issuing another AUTH command. + + + +Myers Standards Track [Page 3] + +RFC 2554 SMTP Authentication March 1999 + + + If an AUTH command fails, the server MUST behave the same as if + the client had not issued the AUTH command. + + The BASE64 string may in general be arbitrarily long. Clients + and servers MUST be able to support challenges and responses + that are as long as are generated by the authentication + mechanisms they support, independent of any line length + limitations the client or server may have in other parts of its + protocol implementation. + + Examples: + S: 220 smtp.example.com ESMTP server ready + C: EHLO jgm.example.com + S: 250-smtp.example.com + S: 250 AUTH CRAM-MD5 DIGEST-MD5 + C: AUTH FOOBAR + S: 504 Unrecognized authentication type. + C: AUTH CRAM-MD5 + S: 334 + PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= + C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== + S: 235 Authentication successful. + + + +5. The AUTH parameter to the MAIL FROM command + + AUTH=addr-spec + + Arguments: + An addr-spec containing the identity which submitted the message + to the delivery system, or the two character sequence "<>" + indicating such an identity is unknown or insufficiently + authenticated. To comply with the restrictions imposed on ESMTP + parameters, the addr-spec is encoded inside an xtext. The syntax + of an xtext is described in section 5 of [ESMTP-DSN]. + + Discussion: + The optional AUTH parameter to the MAIL FROM command allows + cooperating agents in a trusted environment to communicate the + authentication of individual messages. + + If the server trusts the authenticated identity of the client to + assert that the message was originally submitted by the supplied + addr-spec, then the server SHOULD supply the same addr-spec in an + AUTH parameter when relaying the message to any server which + supports the AUTH extension. + + + + +Myers Standards Track [Page 4] + +RFC 2554 SMTP Authentication March 1999 + + + A MAIL FROM parameter of AUTH=<> indicates that the original + submitter of the message is not known. The server MUST NOT treat + the message as having been originally submitted by the client. + + If the AUTH parameter to the MAIL FROM is not supplied, the + client has authenticated, and the server believes the message is + an original submission by the client, the server MAY supply the + client's identity in the addr-spec in an AUTH parameter when + relaying the message to any server which supports the AUTH + extension. + + If the server does not sufficiently trust the authenticated + identity of the client, or if the client is not authenticated, + then the server MUST behave as if the AUTH=<> parameter was + supplied. The server MAY, however, write the value of the AUTH + parameter to a log file. + + If an AUTH=<> parameter was supplied, either explicitly or due to + the requirement in the previous paragraph, then the server MUST + supply the AUTH=<> parameter when relaying the message to any + server which it has authenticated to using the AUTH extension. + + A server MAY treat expansion of a mailing list as a new + submission, setting the AUTH parameter to the mailing list + address or mailing list administration address when relaying the + message to list subscribers. + + It is conforming for an implementation to be hard-coded to treat + all clients as being insufficiently trusted. In that case, the + implementation does nothing more than parse and discard + syntactically valid AUTH parameters to the MAIL FROM command and + supply AUTH=<> parameters to any servers to which it + authenticates using the AUTH extension. + + Examples: + C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com + S: 250 OK + + + + + + + + + + + + + + +Myers Standards Track [Page 5] + +RFC 2554 SMTP Authentication March 1999 + + +6. Error Codes + + The following error codes may be used to indicate various conditions + as described. + + 432 A password transition is needed + + This response to the AUTH command indicates that the user needs to + transition to the selected authentication mechanism. This typically + done by authenticating once using the PLAIN authentication mechanism. + + 534 Authentication mechanism is too weak + + This response to the AUTH command indicates that the selected + authentication mechanism is weaker than server policy permits for + that user. + + 538 Encryption required for requested authentication mechanism + + This response to the AUTH command indicates that the selected + authentication mechanism may only be used when the underlying SMTP + connection is encrypted. + + 454 Temporary authentication failure + + This response to the AUTH command indicates that the authentication + failed due to a temporary server failure. + + 530 Authentication required + + This response may be returned by any command other than AUTH, EHLO, + HELO, NOOP, RSET, or QUIT. It indicates that server policy requires + authentication in order to perform the requested action. + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 6] + +RFC 2554 SMTP Authentication March 1999 + + +7. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [ABNF]. + + 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. + + UPALPHA = %x41-5A ;; Uppercase: A-Z + + LOALPHA = %x61-7A ;; Lowercase: a-z + + ALPHA = UPALPHA / LOALPHA ;; case insensitive + + DIGIT = %x30-39 ;; Digits 0-9 + + HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase) + + hexchar = "+" HEXDIGIT HEXDIGIT + + xchar = %x21-2A / %x2C-3C / %x3E-7E + ;; US-ASCII except for "+", "=", SPACE and CTL + + xtext = *(xchar / hexchar) + + AUTH_CHAR = ALPHA / DIGIT / "-" / "_" + + auth_type = 1*20AUTH_CHAR + + auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] + *(CRLF [base64]) CRLF + + auth_param = "AUTH=" xtext + ;; The decoded form of the xtext MUST be either + ;; an addr-spec or the two characters "<>" + + base64 = base64_terminal / + ( 1*(4base64_CHAR) [base64_terminal] ) + + base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" + ;; Case-sensitive + + base64_terminal = (2base64_char "==") / (3base64_char "=") + + continue_req = "334" SPACE [base64] CRLF + + + + +Myers Standards Track [Page 7] + +RFC 2554 SMTP Authentication March 1999 + + + CR = %x0C ;; ASCII CR, carriage return + + CRLF = CR LF + + CTL = %x00-1F / %x7F ;; any ASCII control character and DEL + + LF = %x0A ;; ASCII LF, line feed + + SPACE = %x20 ;; ASCII SP, space + + + + +8. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + + [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. + Crocker, "SMTP Service Extensions", RFC 1869, November + 1995. + + [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status + Notifications", RFC 1891, January 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC + 2476, December 1998. + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, August 1982. + + + + + + + + +Myers Standards Track [Page 8] + +RFC 2554 SMTP Authentication March 1999 + + +9. Security Considerations + + Security issues are discussed throughout this memo. + + If a client uses this extension to get an encrypted tunnel through an + insecure network to a cooperating server, it needs to be configured + to never send mail to that server when the connection is not mutually + authenticated and encrypted. Otherwise, an attacker could steal the + client's mail by hijacking the SMTP connection and either pretending + the server does not support the Authentication extension or causing + all AUTH commands to fail. + + Before the SASL negotiation has begun, any protocol interactions are + performed in the clear and may be modified by an active attacker. + For this reason, clients and servers MUST discard any knowledge + obtained prior to the start of the SASL negotiation upon completion + of a SASL negotiation which results in a security layer. + + This mechanism does not protect the TCP port, so an active attacker + may redirect a relay connection attempt to the submission port + [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing + an relayed message without an envelope authentication to pick up the + authentication of the relay client. + + A message submission client may require the user to authenticate + whenever a suitable SASL mechanism is advertised. Therefore, it may + not be desirable for a submission server [SUBMIT] to advertise a SASL + mechanism when use of that mechanism grants the client no benefits + over anonymous submission. + + This extension is not intended to replace or be used instead of end- + to-end message signature and encryption systems such as S/MIME or + PGP. This extension addresses a different problem than end-to-end + systems; it has the following key differences: + + (1) it is generally useful only within a trusted enclave + + (2) it protects the entire envelope of a message, not just the + message's body. + + (3) it authenticates the message submission, not authorship of the + message content + + (4) it can give the sender some assurance the message was + delivered to the next hop in the case where the sender + mutually authenticates with the next hop and negotiates an + appropriate security layer. + + + + +Myers Standards Track [Page 9] + +RFC 2554 SMTP Authentication March 1999 + + + Additional security considerations are mentioned in the SASL + specification [SASL]. + + + +10. Author's Address + + John Gardiner Myers + Netscape Communications + 501 East Middlefield Road + Mail Stop MV-029 + Mountain View, CA 94043 + + EMail: jgmyers@netscape.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 10] + +RFC 2554 SMTP Authentication March 1999 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Myers Standards Track [Page 11] + diff --git a/RFC/rfc2645.txt b/RFC/rfc2645.txt new file mode 100644 index 00000000..cb99fc84 --- /dev/null +++ b/RFC/rfc2645.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group R. Gellens +Request for Comments: 2645 Qualcomm +Category: Standards Track August 1999 + + + ON-DEMAND MAIL RELAY (ODMR) + SMTP with Dynamic IP Addresses + +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 (1999). All Rights Reserved. + +Table of Contents + + 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 + 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 + 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1.1. EHLO . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1.2. AUTH . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5.1.3. QUIT . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5.2. Authenticated State . . . . . . . . . . . . . . . . . . . 4 + 5.2.1. ATRN (Authenticated TURN) . . . . . . . . . . . . . 4 + 5.3. Reversed State . . . . . . . . . . . . . . . . . . . . . 5 + 5.4. Other Commands . . . . . . . . . . . . . . . . . . . . . 6 + 6. Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6 + 7. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 11. Author's Address . . . . . . . . . . . . . . . . . . . . . 8 + 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 + +1. Abstract + + With the spread of low-cost computer systems and Internet + connectivity, the demand for local mail servers has been rising. + Many people now want to operate a mail server on a system which has + + + +Gellens Standards Track [Page 1] + +RFC 2645 On-Demand Mail Relay August 1999 + + + only an intermittent connection to a service provider. If the system + has a static IP address, the ESMTP ETRN command [ETRN] can be used. + However, systems with dynamic IP addresses (which are very common + with low-cost connections) have no widely-deployed solution. + + This memo proposes a new service, On-Demand Mail Relay (ODMR), which + is a profile of SMTP [SMTP, ESMTP], providing for a secure, + extensible, easy to implement approach to the problem. + +2. Conventions Used in this Document + + Because the client and server roles reverse during the session, to + avoid confusion, the terms "customer" and "provider" will be used in + place of "client" and "server", although of course this protocol may + be useful in cases other than commercial service providers and + customers. + + In examples, "P:" is used to indicate lines sent by the provider, and + "C:" indicates those sent by the customer. Line breaks within a + command are for editorial purposes only. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as defined in [KEYWORDS]. + + Examples use 'example.net' as the provider, and 'example.org' and ' + example.com' as the customers. + +3. Comments + + Private comments should be sent to the author. Public comments may + be sent to the IETF Disconnected SMTP mailing list, + <ietf-disconn-smtp@imc.org>. To subscribe, send a message to + <ietf-disconn-smtp-request@imc.org> containing the word SUBSCRIBE as + the body. + +4. Description + + On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP]. + Port 366 is reserved for On-Demand Mail Relay. The initial client + and server roles are short-lived, as the point is to allow the + intermittently-connected host to request mail held for it by a + service provider. + + The customer initiates a connection to the provider, authenticates, + and requests its mail. The roles of client and server then reverse, + and normal SMTP [SMTP, ESMTP] proceeds. + + + + + +Gellens Standards Track [Page 2] + +RFC 2645 On-Demand Mail Relay August 1999 + + + The provider has an On-Demand Mail Relay process listening for + connections on the ODMR port. This process does not need to be a + full SMTP server. It does need to be an SMTP client with access to + the outgoing mail queues, and as a server implement the EHLO, AUTH, + ATRN, and QUIT commands. + + An MTA normally has a mail client component which processes the + outgoing mail queues, attempting to send mail for particular domains, + based on time or event (such as new mail being placed in the queue, + or receipt of an ETRN command by the SMTP server component). The + On-Demand Mail Relay service processes the outgoing queue not on a + timer or new mail creation, but on request. + + The provider side has normal SMTP server responsibilities [SMTP], + including generation of delivery failure notices, etc. as needed. + +5. States + + The On-Demand Mail Relay service has three states: an initial state, + an authenticated state, and a reversed state. The state progression + is illustrated in the following diagram: + + --------------------------- + ! initial state ! + --------------------------- + ! ! + QUIT AUTH + ! ! + ! V + ! ----------------------- + ! ! authenticated state ! + ! ----------------------- + ! ! ! + ! QUIT ATRN + ! ! ! + ! ! V + ! ! ------------------ + ! ! ! reversed state ! + ! ! ------------------ + ! ! ! + ! ! QUIT + ! ! ! + V V V + --------------------- + ! termination ! + --------------------- + + + + + +Gellens Standards Track [Page 3] + +RFC 2645 On-Demand Mail Relay August 1999 + + + (Note that in the reversed state, commands are sent by the provider, + not the customer.) + +5.1. Initial State + + In the initial state, the provider is the server and the customer is + the client. Three commands are valid: EHLO, AUTH, and QUIT. + +5.1.1. EHLO + + The EHLO command is the same as in [ESMTP]. The response MUST + include AUTH and ATRN. + +5.1.2. AUTH + + The AUTH command is specified in [AUTH]. The AUTH command uses a + [SASL] mechanism to authenticate the session. The session is not + considered authenticated until a success response to AUTH has been + sent. + + For interoperability, implementations MUST support the CRAM-MD5 + mechanism [CRAM]. Other SASL mechanisms may be supported. A site + MAY disable CRAM-MD5 support if it uses more secure methods. The + EXTERNAL mechanism [SASL] might be useful in some cases, for example, + if the provider has already authenticated the client, such as during + a PPP connection. + +5.1.3. QUIT + + The QUIT command is the same as in [SMTP]. + +5.2. Authenticated State + + The authenticated state is entered after a successful AUTH command. + Two commands are valid in the authenticated state: ATRN and QUIT. + +5.2.1. ATRN (Authenticated TURN) + + Unlike the TURN command in [SMTP], the ATRN command optionally takes + one or more domains as a parameter. The ATRN command MUST be + rejected if the session has not been authenticated. Response code + 530 [AUTH] is used for this. + + The timeout for this command MUST be at least 10 minutes to allow the + provider time to process its mail queue. + + An ATRN command sent with no domains is equivalent to an ATRN command + specifying all domains to which the customer has access. + + + +Gellens Standards Track [Page 4] + +RFC 2645 On-Demand Mail Relay August 1999 + + + If the authentication used by the customer does not provide access to + all of the domains specified in ATRN, the provider MUST NOT send mail + for any domains to the customer; the provider MUST reject the ATRN + command with a 450 code. + + If the customer does have access to all of the specified domains, but + none of them have any queued mail, the provider normally rejects the + ATRN command with response code 453. The provider MAY instead issue + a 250 success code, and after the roles are reversed, send a QUIT + following the EHLO. + + The provider MAY also reject the ATRN command with a 450 response to + indicate refusal to accept multiple requests issued within a + particular time interval. + + If the customer has access to all of the specified domains and mail + exists in at least one of them, the provider issues a 250 success + code. + + If the server is unable to verify access to the requested domains + (for example, a mapping database is temporarily unavailable), + response code 451 is sent. + + [ABNF] for ATRN: + + atrn = "ATRN" [SP domain *("," domain)] + + domain = sub-domain 1*("." sub-domain) + + sub-domain = (ALPHA / DIGIT) *(ldh-str) + + ldh-str = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) + +5.3. Reversed State + + After the provider has sent a success reply to the ATRN command, the + roles reverse, and the customer becomes the server, and the provider + becomes the client. + + After receiving the success response to ATRN, the customer sends a + standard SMTP initial greeting line. At this point normal SMTP + [SMTP, ESMTP] commands are used. Typically the provider sends EHLO + after seeing the customer's greeting, to be followed by MAIL FROM and + so on. + + + + + + + +Gellens Standards Track [Page 5] + +RFC 2645 On-Demand Mail Relay August 1999 + + +5.4. Other Commands + + The provider MAY reject all commands other than EHLO, AUTH, ATRN, and + QUIT with response code 502. + +6. Example On-Demand Mail Relay Session + + P: 220 EXAMPLE.NET on-demand mail relay server ready + C: EHLO example.org + P: 250-EXAMPLE.NET + P: 250-AUTH CRAM-MD5 EXTERNAL + P: 250 ATRN + C: AUTH CRAM-MD5 + P: 334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo= + C: Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo= + P: 235 now authenticated as example.org + C: ATRN example.org,example.com + P: 250 OK now reversing the connection + C: 220 example.org ready to receive email + P: EHLO EXAMPLE.NET + C: 250-example.org + C: 250 SIZE + P: MAIL FROM: <Lester.Tester@dot.foo.bar> + C: 250 OK + P: RCPT TO: <l.eva.msg@example.com> + C: 250 OK, recipient accepted + ... + P: QUIT + C: 221 example.org closing connection + +7. Response Codes + + The response codes used in this document are: + + 250 Requested mail action okay, completed + 450 ATRN request refused + 451 Unable to process ATRN request now + 453 You have no mail + 502 Command not implemented + 530 Authentication required [AUTH] + +8. Security Considerations + + Because access to the On-Demand Mail Relay server is only useful with + a prior arrangement between the parties (so the provider is the + target of MX records for the customer's domains and thus has mail to + relay), it may be useful for the provider to restrict access to the + On-Demand Mail Relay port. For example, the ODMR server could be + + + +Gellens Standards Track [Page 6] + +RFC 2645 On-Demand Mail Relay August 1999 + + + configurable, or a TCP wrapper or firewall could be used, to block + access to port 366 except within the provider's network. This might + be useful when the provider is the customer's ISP. Use of such + mechanisms does not reduce the need for the AUTH command, however, + but can increase the security it provides. + + Use of SASL in the AUTH command allows for substitution of more + secure authentication mechanisms in the future. + + See sections 5.1.2 and 5.2.1 for additional security details. + +9. Acknowledgments + + This memo has been developed in part based on comments and + discussions which took place on and off the IETF-disconn-smtp mailing + list. Special thanks to Chris Newman and Ned Freed for their + comments. + +10. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [AUTH] Myers, J., "SMTP Service Extension for Authentication", + RFC 2554, March 1999. + + [CRAM] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + + [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. + Crocker, "SMTP Service Extensions", RFC 1869, November + 1995. + + [ETRN] De Winter, J., "SMTP Service Extension for Remote Message + Queue Starting", RFC 1985, August 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + + + + + +Gellens Standards Track [Page 7] + +RFC 2645 On-Demand Mail Relay August 1999 + + +11. Author's Address + + Randall Gellens + QUALCOMM Incorporated + 5775 Morehouse Dr. + San Diego, CA 92121-2779 + U.S.A. + + Phone: +1.619.651.5115 + EMail: randy@qualcomm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens Standards Track [Page 8] + +RFC 2645 On-Demand Mail Relay August 1999 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (1999). 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 9] + diff --git a/RFC/rfc2683.txt b/RFC/rfc2683.txt new file mode 100644 index 00000000..651447b3 --- /dev/null +++ b/RFC/rfc2683.txt @@ -0,0 +1,1291 @@ +
+
+
+
+
+
+Network Working Group B. Leiba
+Request for Comments: 2683 IBM T.J. Watson Research Center
+Category: Informational September 1999
+
+
+ IMAP4 Implementation Recommendations
+
+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 (1999). All Rights Reserved.
+
+1. Abstract
+
+ The IMAP4 specification [RFC-2060] describes a rich protocol for use
+ in building clients and servers for storage, retrieval, and
+ manipulation of electronic mail. Because the protocol is so rich and
+ has so many implementation choices, there are often trade-offs that
+ must be made and issues that must be considered when designing such
+ clients and servers. This document attempts to outline these issues
+ and to make recommendations in order to make the end products as
+ interoperable as possible.
+
+2. Conventions used in this document
+
+ In examples, "C:" indicates lines sent by a client that is connected
+ to a server. "S:" indicates lines sent by the server to the client.
+
+ The words "must", "must not", "should", "should not", and "may" are
+ used with specific meaning in this document; since their meaning is
+ somewhat different from that specified in RFC 2119, we do not put
+ them in all caps here. Their meaning is as follows:
+
+ must -- This word means that the action described is necessary
+ to ensure interoperability. The recommendation should
+ not be ignored.
+ must not -- This phrase means that the action described will be
+ almost certain to hurt interoperability. The
+ recommendation should not be ignored.
+
+
+
+
+
+
+
+Leiba Informational [Page 1]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ should -- This word means that the action described is strongly
+ recommended and will enhance interoperability or
+ usability. The recommendation should not be ignored
+ without careful consideration.
+ should not -- This phrase means that the action described is strongly
+ recommended against, and might hurt interoperability or
+ usability. The recommendation should not be ignored
+ without careful consideration.
+ may -- This word means that the action described is an
+ acceptable implementation choice. No specific
+ recommendation is implied; this word is used to point
+ out a choice that might not be obvious, or to let
+ implementors know what choices have been made by
+ existing implementations.
+
+3. Interoperability Issues and Recommendations
+
+3.1. Accessibility
+
+ This section describes the issues related to access to servers and
+ server resources. Concerns here include data sharing and maintenance
+ of client/server connections.
+
+3.1.1. Multiple Accesses of the Same Mailbox
+
+ One strong point of IMAP4 is that, unlike POP3, it allows for
+ multiple simultaneous access to a single mailbox. A user can, thus,
+ read mail from a client at home while the client in the office is
+ still connected; or the help desk staff can all work out of the same
+ inbox, all seeing the same pool of questions. An important point
+ about this capability, though is that NO SERVER IS GUARANTEED TO
+ SUPPORT THIS. If you are selecting an IMAP server and this facility
+ is important to you, be sure that the server you choose to install,
+ in the configuration you choose to use, supports it.
+
+ If you are designing a client, you must not assume that you can
+ access the same mailbox more than once at a time. That means
+
+ 1. you must handle gracefully the failure of a SELECT command if the
+ server refuses the second SELECT,
+ 2. you must handle reasonably the severing of your connection (see
+ "Severed Connections", below) if the server chooses to allow the
+ second SELECT by forcing the first off,
+ 3. you must avoid making multiple connections to the same mailbox in
+ your own client (for load balancing or other such reasons), and
+ 4. you must avoid using the STATUS command on a mailbox that you have
+ selected (with some server implementations the STATUS command has
+ the same problems with multiple access as do the SELECT and
+
+
+
+Leiba Informational [Page 2]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ EXAMINE commands).
+
+ A further note about STATUS: The STATUS command is sometimes used to
+ check a non-selected mailbox for new mail. This mechanism must not
+ be used to check for new mail in the selected mailbox; section 5.2 of
+ [RFC-2060] specifically forbids this in its last paragraph. Further,
+ since STATUS takes a mailbox name it is an independent operation, not
+ operating on the selected mailbox. Because of this, the information
+ it returns is not necessarily in synchronization with the selected
+ mailbox state.
+
+3.1.2. Severed Connections
+
+ The client/server connection may be severed for one of three reasons:
+ the client severs the connection, the server severs the connection,
+ or the connection is severed by outside forces beyond the control of
+ the client and the server (a telephone line drops, for example).
+ Clients and servers must both deal with these situations.
+
+ When the client wants to sever a connection, it's usually because it
+ has finished the work it needed to do on that connection. The client
+ should send a LOGOUT command, wait for the tagged response, and then
+ close the socket. But note that, while this is what's intended in
+ the protocol design, there isn't universal agreement here. Some
+ contend that sending the LOGOUT and waiting for the two responses
+ (untagged BYE and tagged OK) is wasteful and unnecessary, and that
+ the client can simply close the socket. The server should interpret
+ the closed socket as a log out by the client. The counterargument is
+ that it's useful from the standpoint of cleanup, problem
+ determination, and the like, to have an explicit client log out,
+ because otherwise there is no way for the server to tell the
+ difference between "closed socket because of log out" and "closed
+ socket because communication was disrupted". If there is a
+ client/server interaction problem, a client which routinely
+ terminates a session by breaking the connection without a LOGOUT will
+ make it much more difficult to determine the problem.
+
+ Because of this disagreement, server designers must be aware that
+ some clients might close the socket without sending a LOGOUT. In any
+ case, whether or not a LOGOUT was sent, the server should not
+ implicitly expunge any messages from the selected mailbox. If a
+ client wants the server to do so, it must send a CLOSE or EXPUNGE
+ command explicitly.
+
+ When the server wants to sever a connection it's usually due to an
+ inactivity timeout or is because a situation has arisen that has
+ changed the state of the mail store in a way that the server can not
+ communicate to the client. The server should send an untagged BYE
+
+
+
+Leiba Informational [Page 3]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ response to the client and then close the socket. Sending an
+ untagged BYE response before severing allows the server to send a
+ human-readable explanation of the problem to the client, which the
+ client may then log, display to the user, or both (see section 7.1.5
+ of [RFC-2060]).
+
+ Regarding inactivity timeouts, there is some controversy. Unlike
+ POP, for which the design is for a client to connect, retrieve mail,
+ and log out, IMAP's design encourages long-lived (and mostly
+ inactive) client/server sessions. As the number of users grows, this
+ can use up a lot of server resources, especially with clients that
+ are designed to maintain sessions for mailboxes that the user has
+ finished accessing. To alleviate this, a server may implement an
+ inactivity timeout, unilaterally closing a session (after first
+ sending an untagged BYE, as noted above). Some server operators have
+ reported dramatic improvements in server performance after doing
+ this. As specified in [RFC-2060], if such a timeout is done it must
+ not be until at least 30 minutes of inactivity. The reason for this
+ specification is to prevent clients from sending commands (such as
+ NOOP) to the server at frequent intervals simply to avert a too-early
+ timeout. If the client knows that the server may not time out the
+ session for at least 30 minutes, then the client need not poll at
+ intervals more frequent than, say, 25 minutes.
+
+3.2. Scaling
+
+ IMAP4 has many features that allow for scalability, as mail stores
+ become larger and more numerous. Large numbers of users, mailboxes,
+ and messages, and very large messages require thought to handle
+ efficiently. This document will not address the administrative
+ issues involved in large numbers of users, but we will look at the
+ other items.
+
+3.2.1. Flood Control
+
+ There are three situations when a client can make a request that will
+ result in a very large response - too large for the client reasonably
+ to deal with: there are a great many mailboxes available, there are a
+ great many messages in the selected mailbox, or there is a very large
+ message part. The danger here is that the end user will be stuck
+ waiting while the server sends (and the client processes) an enormous
+ response. In all of these cases there are things a client can do to
+ reduce that danger.
+
+ There is also the case where a client can flood a server, by sending
+ an arbitratily long command. We'll discuss that issue, too, in this
+ section.
+
+
+
+
+Leiba Informational [Page 4]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+3.2.1.1. Listing Mailboxes
+
+ Some servers present Usenet newsgroups to IMAP users. Newsgroups,
+ and other such hierarchical mailbox structures, can be very numerous
+ but may have only a few entries at the top level of hierarchy. Also,
+ some servers are built against mail stores that can, unbeknownst to
+ the server, have circular hierarchies - that is, it's possible for
+ "a/b/c/d" to resolve to the same file structure as "a", which would
+ then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy
+ will never end. The LIST response in this case will be unlimited.
+
+ Clients that will have trouble with this are those that use
+
+ C: 001 LIST "" *
+
+ to determine the mailbox list. Because of this, clients should not
+ use an unqualified "*" that way in the LIST command. A safer
+ approach is to list each level of hierarchy individually, allowing
+ the user to traverse the tree one limb at a time, thus:
+
+ C: 001 LIST "" %
+ S: * LIST () "/" Banana
+ S: * LIST ...etc...
+ S: 001 OK done
+
+ and then
+
+ C: 002 LIST "" Banana/%
+ S: * LIST () "/" Banana/Apple
+ S: * LIST ...etc...
+ S: 002 OK done
+
+ Using this technique the client's user interface can give the user
+ full flexibility without choking on the voluminous reply to "LIST *".
+
+ Of course, it is still possible that the reply to
+
+ C: 005 LIST "" alt.fan.celebrity.%
+
+ may be thousands of entries long, and there is, unfortunately,
+ nothing the client can do to protect itself from that. This has not
+ yet been a notable problem.
+
+ Servers that may export circular hierarchies (any server that
+ directly presents a UNIX file system, for instance) should limit the
+ hierarchy depth to prevent unlimited LIST responses. A suggested
+ depth limit is 20 hierarchy levels.
+
+
+
+
+Leiba Informational [Page 5]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+3.2.1.2. Fetching the List of Messages
+
+ When a client selects a mailbox, it is given a count, in the untagged
+ EXISTS response, of the messages in the mailbox. This number can be
+ very large. In such a case it might be unwise to use
+
+ C: 004 FETCH 1:* ALL
+
+ to populate the user's view of the mailbox. One good method to avoid
+ problems with this is to batch the requests, thus:
+
+ C: 004 FETCH 1:50 ALL
+ S: * 1 FETCH ...etc...
+ S: 004 OK done
+ C: 005 FETCH 51:100 ALL
+ S: * 51 FETCH ...etc...
+ S: 005 OK done
+ C: 006 FETCH 101:150 ALL
+ ...etc...
+
+ Using this method, another command, such as "FETCH 6 BODY[1]" can be
+ inserted as necessary, and the client will not have its access to the
+ server blocked by a storm of FETCH replies. (Such a method could be
+ reversed to fetch the LAST 50 messages first, then the 50 prior to
+ that, and so on.)
+
+ As a smart extension of this, a well designed client, prepared for
+ very large mailboxes, will not automatically fetch data for all
+ messages AT ALL. Rather, the client will populate the user's view
+ only as the user sees it, possibly pre-fetching selected information,
+ and only fetching other information as the user scrolls to it. For
+ example, to select only those messages beginning with the first
+ unseen one:
+
+ C: 003 SELECT INBOX
+ S: * 10000 EXISTS
+ S: * 80 RECENT
+ S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
+ S: * OK [UIDVALIDITY 824708485] UID validity status
+ S: * OK [UNSEEN 9921] First unseen message
+ S: 003 OK [READ-WRITE] SELECT completed
+ C: 004 FETCH 9921:* ALL
+ ... etc...
+
+ If the server does not return an OK [UNSEEN] response, the client may
+ use SEARCH UNSEEN to obtain that value.
+
+
+
+
+
+Leiba Informational [Page 6]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ This mechanism is good as a default presentation method, but only
+ works well if the default message order is acceptable. A client may
+ want to present various sort orders to the user (by subject, by date
+ sent, by sender, and so on) and in that case (lacking a SORT
+ extension on the server side) the client WILL have to retrieve all
+ message descriptors. A client that provides this service should not
+ do it by default and should inform the user of the costs of choosing
+ this option for large mailboxes.
+
+3.2.1.3. Fetching a Large Body Part
+
+ The issue here is similar to the one for a list of messages. In the
+ BODYSTRUCTURE response the client knows the size, in bytes, of the
+ body part it plans to fetch. Suppose this is a 70 MB video clip. The
+ client can use partial fetches to retrieve the body part in pieces,
+ avoiding the problem of an uninterruptible 70 MB literal coming back
+ from the server:
+
+ C: 022 FETCH 3 BODY[1]<0.20000>
+ S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
+ S: ...data...)
+ S: 022 OK done
+ C: 023 FETCH 3 BODY[1]<20001.20000>
+ S: * 3 FETCH (BODY[1]<20001> {20000}
+ S: ...data...)
+ S: 023 OK done
+ C: 024 FETCH 3 BODY[1]<40001.20000>
+ ...etc...
+
+3.2.1.4. BODYSTRUCTURE vs. Entire Messages
+
+ Because FETCH BODYSTRUCTURE is necessary in order to determine the
+ number of body parts, and, thus, whether a message has "attachments",
+ clients often use FETCH FULL as their normal method of populating the
+ user's view of a mailbox. The benefit is that the client can display
+ a paperclip icon or some such indication along with the normal
+ message summary. However, this comes at a significant cost with some
+ server configurations. The parsing needed to generate the FETCH
+ BODYSTRUCTURE response may be time-consuming compared with that
+ needed for FETCH ENVELOPE. The client developer should consider this
+ issue when deciding whether the ability to add a paperclip icon is
+ worth the tradeoff in performance, especially with large mailboxes.
+
+ Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]
+ (or the equivalent FETCH RFC822) to retrieve the entire message.
+ They then do the MIME parsing in the client. This may give the
+ client slightly more flexibility in some areas (access, for instance,
+ to header fields that aren't returned in the BODYSTRUCTURE and
+
+
+
+Leiba Informational [Page 7]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ ENVELOPE responses), but it can cause severe performance problems by
+ forcing the transfer of all body parts when the user might only want
+ to see some of them - a user logged on by modem and reading a small
+ text message with a large ZIP file attached may prefer to read the
+ text only and save the ZIP file for later. Therefore, a client
+ should not normally retrieve entire messages and should retrieve
+ message body parts selectively.
+
+3.2.1.5. Long Command Lines
+
+ A client can wind up building a very long command line in an effort to
+ try to be efficient about requesting information from a server. This
+ can typically happen when a client builds a message set from selected
+ messages and doesn't recognise that contiguous blocks of messages may
+ be group in a range. Suppose a user selects all 10,000 messages in a
+ large mailbox and then unselects message 287. The client could build
+ that message set as "1:286,288:10000", but a client that doesn't
+ handle that might try to enumerate each message individually and build
+ "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command
+ results in a command line that's almost 49,000 octets long, and,
+ clearly, one can construct a command line that's even longer.
+
+ A client should limit the length of the command lines it generates to
+ approximately 1000 octets (including all quoted strings but not
+ including literals). If the client is unable to group things into
+ ranges so that the command line is within that length, it should
+ split the request into multiple commands. The client should use
+ literals instead of long quoted strings, in order to keep the command
+ length down.
+
+ For its part, a server should allow for a command line of at least
+ 8000 octets. This provides plenty of leeway for accepting reasonable
+ length commands from clients. The server should send a BAD response
+ to a command that does not end within the server's maximum accepted
+ command length.
+
+3.2.2. Subscriptions
+
+ The client isn't the only entity that can get flooded: the end user,
+ too, may need some flood control. The IMAP4 protocol provides such
+ control in the form of subscriptions. Most servers support the
+ SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to
+ narrow down a large list of available mailboxes by subscribing to the
+ ones that they usually want to see. Clients, with this in mind,
+ should give the user a way to see only subscribed mailboxes. A
+ client that never uses the LSUB command takes a significant usability
+ feature away from the user. Of course, the client would not want to
+ hide the LIST command completely; the user needs to have a way to
+
+
+
+Leiba Informational [Page 8]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ choose between LIST and LSUB. The usual way to do this is to provide
+ a setting like "show which mailboxes?: [] all [] subscribed only".
+
+3.2.3. Searching
+
+ IMAP SEARCH commands can become particularly troublesome (that is,
+ slow) on mailboxes containing a large number of messages. So let's
+ put a few things in perspective in that regard.
+
+ The flag searches should be fast. The flag searches (ALL, [UN]SEEN,
+ [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
+ are known to be used by clients for the client's own use (for
+ instance, some clients use "SEARCH UNSEEN" to find unseen mail and
+ "SEARCH DELETED" to warn the user before expunging messages).
+
+ Other searches, particularly the text searches (HEADER, TEXT, BODY)
+ are initiated by the user, rather than by the client itself, and
+ somewhat slower performance can be tolerated, since the user is aware
+ that the search is being done (and is probably aware that it might be
+ time-consuming). A smart server might use dynamic indexing to speed
+ commonly used text searches.
+
+ The client may allow other commands to be sent to the server while a
+ SEARCH is in progress, but at the time of this writing there is
+ little or no server support for parallel processing of multiple
+ commands in the same session (and see "Multiple Accesses of the Same
+ Mailbox" above for a description of the dangers of trying to work
+ around this by doing your SEARCH in another session).
+
+ Another word about text searches: some servers, built on database
+ back-ends with indexed search capabilities, may return search results
+ that do not match the IMAP spec's "case-insensitive substring"
+ requirements. While these servers are in violation of the protocol,
+ there is little harm in the violation as long as the search results
+ are used only in response to a user's request. Still, developers of
+ such servers should be aware that they ARE violating the protocol,
+ should think carefully about that behaviour, and must be certain that
+ their servers respond accurately to the flag searches for the reasons
+ outlined above.
+
+ In addition, servers should support CHARSET UTF-8 [UTF-8] in
+ searches.
+
+
+
+
+
+
+
+
+
+Leiba Informational [Page 9]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+3.3 Avoiding Invalid Requests
+
+ IMAP4 provides ways for a server to tell a client in advance what is
+ and isn't permitted in some circumstances. Clients should use these
+ features to avoid sending requests that a well designed client would
+ know to be invalid. This section explains this in more detail.
+
+3.3.1. The CAPABILITY Command
+
+ All IMAP4 clients should use the CAPABILITY command to determine what
+ version of IMAP and what optional features a server supports. The
+ client should not send IMAP4rev1 commands and arguments to a server
+ that does not advertize IMAP4rev1 in its CAPABILITY response.
+ Similarly, the client should not send IMAP4 commands that no longer
+ exist in IMAP4rev1 to a server that does not advertize IMAP4 in its
+ CAPABILITY response. An IMAP4rev1 server is NOT required to support
+ obsolete IMAP4 or IMAP2bis commands (though some do; do not let this
+ fact lull you into thinking that it's valid to send such commands to
+ an IMAP4rev1 server).
+
+ A client should not send commands to probe for the existance of
+ certain extensions. All standard and standards-track extensions
+ include CAPABILITY tokens indicating their presense. All private and
+ experimental extensions should do the same, and clients that take
+ advantage of them should use the CAPABILITY response to determine
+ whether they may be used or not.
+
+3.3.2. Don't Do What the Server Says You Can't
+
+ In many cases, the server, in response to a command, will tell the
+ client something about what can and can't be done with a particular
+ mailbox. The client should pay attention to this information and
+ should not try to do things that it's been told it can't do.
+
+ Examples:
+
+ * Do not try to SELECT a mailbox that has the \Noselect flag set.
+ * Do not try to CREATE a sub-mailbox in a mailbox that has the
+ \Noinferiors flag set.
+ * Do not respond to a failing COPY or APPEND command by trying to
+ CREATE the target mailbox if the server does not respond with a
+ [TRYCREATE] response code.
+ * Do not try to expunge a mailbox that has been selected with the
+ [READ-ONLY] response code.
+
+
+
+
+
+
+
+Leiba Informational [Page 10]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+3.4. Miscellaneous Protocol Considerations
+
+ We describe here a number of important protocol-related issues, the
+ misunderstanding of which has caused significant interoperability
+ problems in IMAP4 implementations. One general item is that every
+ implementer should be certain to take note of and to understand
+ section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec
+ [RFC-2060].
+
+3.4.1. Well Formed Protocol
+
+ We cannot stress enough the importance of adhering strictly to the
+ protocol grammar. The specification of the protocol is quite rigid;
+ do not assume that you can insert blank space for "readability" if
+ none is called for. Keep in mind that there are parsers out there
+ that will crash if there are protocol errors. There are clients that
+ will report every parser burp to the user. And in any case,
+ information that cannot be parsed is information that is lost. Be
+ careful in your protocol generation. And see "A Word About Testing",
+ below.
+
+ In particular, note that the string in the INTERNALDATE response is
+ NOT an RFC-822 date string - that is, it is not in the same format as
+ the first string in the ENVELOPE response. Since most clients will,
+ in fact, accept an RFC-822 date string in the INTERNALDATE response,
+ it's easy to miss this in your interoperability testing. But it will
+ cause a problem with some client, so be sure to generate the correct
+ string for this field.
+
+3.4.2. Special Characters
+
+ Certain characters, currently the double-quote and the backslash, may
+ not be sent as-is inside a quoted string. These characters must be
+ preceded by the escape character if they are in a quoted string, or
+ else the string must be sent as a literal. Both clients and servers
+ must handle this, both on output (they must send these characters
+ properly) and on input (they must be able to receive escaped
+ characters in quoted strings). Example:
+
+ C: 001 LIST "" %
+ S: * LIST () "" INBOX
+ S: * LIST () "\\" TEST
+ S: * LIST () "\\" {12}
+ S: "My" mailbox
+ S: 001 OK done
+ C: 002 LIST "" "\"My\" mailbox\\%"
+ S: * LIST () "\\" {17}
+ S: "My" mailbox\Junk
+
+
+
+Leiba Informational [Page 11]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ S: 002 OK done
+
+ Note that in the example the server sent the hierarchy delimiter as
+ an escaped character in the quoted string and sent the mailbox name
+ containing imbedded double-quotes as a literal. The client used only
+ quoted strings, escaping both the backslash and the double-quote
+ characters.
+
+ The CR and LF characters may be sent ONLY in literals; they are not
+ allowed, even if escaped, inside quoted strings.
+
+ And while we're talking about special characters: the IMAP spec, in
+ the section titled "Mailbox International Naming Convention",
+ describes how to encode mailbox names in modified UTF-7 [UTF-7 and
+ RFC-2060]. Implementations must adhere to this in order to be
+ interoperable in the international market, and servers should
+ validate mailbox names sent by client and reject names that do not
+ conform.
+
+ As to special characters in userids and passwords: clients must not
+ restrict what a user may type in for a userid or a password. The
+ formal grammar specifies that these are "astrings", and an astring
+ can be a literal. A literal, in turn can contain any 8-bit
+ character, and clients must allow users to enter all 8-bit characters
+ here, and must pass them, unchanged, to the server (being careful to
+ send them as literals when necessary). In particular, some server
+ configurations use "@" in user names, and some clients do not allow
+ that character to be entered; this creates a severe interoperability
+ problem.
+
+3.4.3. UIDs and UIDVALIDITY
+
+ Servers that support existing back-end mail stores often have no good
+ place to save UIDs for messages. Often the existing mail store will
+ not have the concept of UIDs in the sense that IMAP has: strictly
+ increasing, never re-issued, 32-bit integers. Some servers solve
+ this by storing the UIDs in a place that's accessible to end users,
+ allowing for the possibility that the users will delete them. Others
+ solve it by re-assigning UIDs every time a mailbox is selected.
+
+ The server should maintain UIDs permanently for all messages if it
+ can. If that's not possible, the server must change the UIDVALIDITY
+ value for the mailbox whenever any of the UIDs may have become
+ invalid. Clients must recognize that the UIDVALIDITY has changed and
+ must respond to that condition by throwing away any information that
+ they have saved about UIDs in that mailbox. There have been many
+ problems in this area when clients have failed to do this; in the
+ worst case it will result in loss of mail when a client deletes the
+
+
+
+Leiba Informational [Page 12]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ wrong piece of mail by using a stale UID.
+
+ It seems to be a common misunderstanding that "the UIDVALIDITY and
+ the UID, taken together, form a 64-bit identifier that uniquely
+ identifies a message on a server". This is absolutely NOT TRUE.
+ There is no assurance that the UIDVALIDITY values of two mailboxes be
+ different, so the UIDVALIDITY in no way identifies a mailbox. The
+ ONLY purpose of UIDVALIDITY is, as its name indicates, to give the
+ client a way to check the validity of the UIDs it has cached. While
+ it is a valid implementation choice to put these values together to
+ make a 64-bit identifier for the message, the important concept here
+ is that UIDs are not unique between mailboxes; they are only unique
+ WITHIN a given mailbox.
+
+ Some server implementations have attempted to make UIDs unique across
+ the entire server. This is inadvisable, in that it limits the life
+ of UIDs unnecessarily. The UID is a 32-bit number and will run out
+ in reasonably finite time if it's global across the server. If you
+ assign UIDs sequentially in one mailbox, you will not have to start
+ re-using them until you have had, at one time or another, 2**32
+ different messages in that mailbox. In the global case, you will
+ have to reuse them once you have had, at one time or another, 2**32
+ different messages in the entire mail store. Suppose your server has
+ around 8000 users registered (2**13). That gives an average of 2**19
+ UIDs per user. Suppose each user gets 32 messages (2**5) per day.
+ That gives you 2**14 days (16000+ days = about 45 years) before you
+ run out. That may seem like enough, but multiply the usage just a
+ little (a lot of spam, a lot of mailing list subscriptions, more
+ users) and you limit yourself too much.
+
+ What's worse is that if you have to wrap the UIDs, and, thus, you
+ have to change UIDVALIDITY and invalidate the UIDs in the mailbox,
+ you have to do it for EVERY mailbox in the system, since they all
+ share the same UID pool. If you assign UIDs per mailbox and you have
+ a problem, you only have to kill the UIDs for that one mailbox.
+
+ Under extreme circumstances (and this is extreme, indeed), the server
+ may have to invalidate UIDs while a mailbox is in use by a client -
+ that is, the UIDs that the client knows about in its active mailbox
+ are no longer valid. In that case, the server must immediately
+ change the UIDVALIDITY and must communicate this to the client. The
+ server may do this by sending an unsolicited UIDVALIDITY message, in
+ the same form as in response to the SELECT command. Clients must be
+ prepared to handle such a message and the possibly coincident failure
+ of the command in process. For example:
+
+
+
+
+
+
+Leiba Informational [Page 13]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ C: 032 UID STORE 382 +Flags.silent \Deleted
+ S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
+ S: 032 NO UID command rejected because UIDVALIDITY changed!
+ C: ...invalidates local information and re-fetches...
+ C: 033 FETCH 1:* UID
+ ...etc...
+
+ At the time of the writing of this document, the only server known to
+ do this does so only under the following condition: the client
+ selects INBOX, but there is not yet a physical INBOX file created.
+ Nonetheless, the SELECT succeeds, exporting an empty INBOX with a
+ temporary UIDVALIDITY of 1. While the INBOX remains selected, mail
+ is delivered to the user, which creates the real INBOX file and
+ assigns a permanent UIDVALIDITY (that is likely not to be 1). The
+ server reports the change of UIDVALIDITY, but as there were no
+ messages before, so no UIDs have actually changed, all the client
+ must do is accept the change in UIDVALIDITY.
+
+ Alternatively, a server may force the client to re-select the
+ mailbox, at which time it will obtain a new UIDVALIDITY value. To do
+ this, the server closes this client session (see "Severed
+ Connections" above) and the client then reconnects and gets back in
+ synch. Clients must be prepared for either of these behaviours.
+
+ We do not know of, nor do we anticipate the future existance of, a
+ server that changes UIDVALIDITY while there are existing messages,
+ but clients must be prepared to handle this eventuality.
+
+3.4.4. FETCH Responses
+
+ When a client asks for certain information in a FETCH command, the
+ server may return the requested information in any order, not
+ necessarily in the order that it was requested. Further, the server
+ may return the information in separate FETCH responses and may also
+ return information that was not explicitly requested (to reflect to
+ the client changes in the state of the subject message). Some
+ examples:
+
+ C: 001 FETCH 1 UID FLAGS INTERNALDATE
+ S: * 5 FETCH (FLAGS (\Deleted))
+ S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
+ S: 001 OK done
+
+ (In this case, the responses are in a different order. Also, the
+ server returned a flag update for message 5, which wasn't part of the
+ client's request.)
+
+
+
+
+
+Leiba Informational [Page 14]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ C: 002 FETCH 2 UID FLAGS INTERNALDATE
+ S: * 2 FETCH (INTERNALDATE "...")
+ S: * 2 FETCH (UID 399)
+ S: * 2 FETCH (FLAGS ())
+ S: 002 OK done
+
+ (In this case, the responses are in a different order and were
+ returned in separate responses.)
+
+ C: 003 FETCH 2 BODY[1]
+ S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
+ S: Hello world!
+ S: )
+ S: 003 OK done
+
+ (In this case, the FLAGS response was added by the server, since
+ fetching the body part caused the server to set the \Seen flag.)
+
+ Because of this characteristic a client must be ready to receive any
+ FETCH response at any time and should use that information to update
+ its local information about the message to which the FETCH response
+ refers. A client must not assume that any FETCH responses will come
+ in any particular order, or even that any will come at all. If after
+ receiving the tagged response for a FETCH command the client finds
+ that it did not get all of the information requested, the client
+ should send a NOOP command to the server to ensure that the server
+ has an opportunity to send any pending EXPUNGE responses to the
+ client (see [RFC-2180]).
+
+3.4.5. RFC822.SIZE
+
+ Some back-end mail stores keep the mail in a canonical form, rather
+ than retaining the original MIME format of the messages. This means
+ that the server must reassemble the message to produce a MIME stream
+ when a client does a fetch such as RFC822 or BODY[], requesting the
+ entire message. It also may mean that the server has no convenient
+ way to know the RFC822.SIZE of the message. Often, such a server
+ will actually have to build the MIME stream to compute the size, only
+ to throw the stream away and report the size to the client.
+
+ When this is the case, some servers have chosen to estimate the size,
+ rather than to compute it precisely. Such an estimate allows the
+ client to display an approximate size to the user and to use the
+ estimate in flood control considerations (q.v.), but requires that
+ the client not use the size for things such as allocation of buffers,
+ because those buffers might then be too small to hold the actual MIME
+ stream. Instead, a client should use the size that's returned in the
+ literal when you fetch the data.
+
+
+
+Leiba Informational [Page 15]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ The protocol requires that the RFC822.SIZE value returned by the
+ server be EXACT. Estimating the size is a protocol violation, and
+ server designers must be aware that, despite the performance savings
+ they might realize in using an estimate, this practice will cause
+ some clients to fail in various ways. If possible, the server should
+ compute the RFC822.SIZE for a particular message once, and then save
+ it for later retrieval. If that's not possible, the server must
+ compute the value exactly every time. Incorrect estimates do cause
+ severe interoperability problems with some clients.
+
+3.4.6. Expunged Messages
+
+ If the server allows multiple connections to the same mailbox, it is
+ often possible for messages to be expunged in one client unbeknownst
+ to another client. Since the server is not allowed to tell the
+ client about these expunged messages in response to a FETCH command,
+ the server may have to deal with the issue of how to return
+ information about an expunged message. There was extensive
+ discussion about this issue, and the results of that discussion are
+ summarized in [RFC-2180]. See that reference for a detailed
+ explanation and for recommendations.
+
+3.4.7. The Namespace Issue
+
+ Namespaces are a very muddy area in IMAP4 implementation right now
+ (see [NAMESPACE] for a proposal to clear the water a bit). Until the
+ issue is resolved, the important thing for client developers to
+ understand is that some servers provide access through IMAP to more
+ than just the user's personal mailboxes, and, in fact, the user's
+ personal mailboxes may be "hidden" somewhere in the user's default
+ hierarchy. The client, therefore, should provide a setting wherein
+ the user can specify a prefix to be used when accessing mailboxes. If
+ the user's mailboxes are all in "~/mail/", for instance, then the
+ user can put that string in the prefix. The client would then put
+ the prefix in front of any name pattern in the LIST and LSUB
+ commands:
+
+ C: 001 LIST "" ~/mail/%
+
+ (See also "Reference Names in the LIST Command" below.)
+
+3.4.8. Creating Special-Use Mailboxes
+
+ It may seem at first that this is part of the namespace issue; it is
+ not, and is only indirectly related to it. A number of clients like
+ to create special-use mailboxes with particular names. Most
+ commonly, clients with a "trash folder" model of message deletion
+ want to create a mailbox with the name "Trash" or "Deleted". Some
+
+
+
+Leiba Informational [Page 16]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a
+ "Sent Mail" mailbox. And so on. There are two major
+ interoperability problems with this practice:
+
+ 1. different clients may use different names for mailboxes with
+ similar functions (such as "Trash" and "Deleted"), or may manage
+ the same mailboxes in different ways, causing problems if a user
+ switches between clients and
+ 2. there is no guarantee that the server will allow the creation of
+ the desired mailbox.
+
+ The client developer is, therefore, well advised to consider
+ carefully the creation of any special-use mailboxes on the server,
+ and, further, the client must not require such mailbox creation -
+ that is, if you do decide to do this, you must handle gracefully the
+ failure of the CREATE command and behave reasonably when your
+ special-use mailboxes do not exist and can not be created.
+
+ In addition, the client developer should provide a convenient way for
+ the user to select the names for any special-use mailboxes, allowing
+ the user to make these names the same in all clients used and to put
+ them where the user wants them.
+
+3.4.9. Reference Names in the LIST Command
+
+ Many implementers of both clients and servers are confused by the
+ "reference name" on the LIST command. The reference name is intended
+ to be used in much the way a "cd" (change directory) command is used
+ on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox
+ name is interpreted in much the same way as a file of that name would
+ be found if one had done a "cd" command into the directory specified
+ by the reference name. For example, in Unix we have the following:
+
+ > cd /u/jones/junk
+ > vi banana [file is "/u/jones/junk/banana"]
+ > vi stuff/banana [file is "/u/jones/junk/stuff/banana"]
+ > vi /etc/hosts [file is "/etc/hosts"]
+
+ In the past, there have been several interoperability problems with
+ this. First, while some IMAP servers are built on Unix or PC file
+ systems, many others are not, and the file system semantics do not
+ make sense in those configurations. Second, while some IMAP servers
+ expose the underlying file system to the clients, others allow access
+ only to the user's personal mailboxes, or to some other limited set
+ of files, making such file-system-like semantics less meaningful.
+ Third, because the IMAP spec leaves the interpretation of the
+ reference name as "implementation-dependent", in the past the various
+ server implementations handled it in vastly differing ways.
+
+
+
+Leiba Informational [Page 17]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ The following recommendations are the result of significant
+ operational experience, and are intended to maximize
+ interoperability.
+
+ Server implementations must implement the reference argument in a way
+ that matches the intended "change directory" operation as closely as
+ possible. As a minimum implementation, the reference argument may be
+ prepended to the mailbox name (while suppressing double delimiters;
+ see the next paragraph). Even servers that do not provide a way to
+ break out of the current hierarchy (see "breakout facility" below)
+ must provide a reasonable implementation of the reference argument,
+ as described here, so that they will interoperate with clients that
+ use it.
+
+ Server implementations that prepend the reference argument to the
+ mailbox name should insert a hierarchy delimiter between them, and
+ must not insert a second if one is already present:
+
+ C: A001 LIST ABC DEF
+ S: * LIST () "/" ABC/DEF <=== should do this
+ S: A001 OK done
+
+ C: A002 LIST ABC/ /DEF
+ S: * LIST () "/" ABC//DEF <=== must not do this
+ S: A002 OK done
+
+ On clients, the reference argument is chiefly used to implement a
+ "breakout facility", wherein the user may directly access a mailbox
+ outside the "current directory" hierarchy. Client implementations
+ should have an operational mode that does not use the reference
+ argument. This is to interoperate with older servers that did not
+ implement the reference argument properly. While it's a good idea to
+ give the user access to a breakout facility, clients that do not
+ intend to do so should not use the reference argument at all.
+
+ Client implementations should always place a trailing hierarchy
+ delimiter on the reference argument. This is because some servers
+ prepend the reference argument to the mailbox name without inserting
+ a hierarchy delimiter, while others do insert a hierarchy delimiter
+ if one is not already present. A client that puts the delimiter in
+ will work with both varieties of server.
+
+ Client implementations that implement a breakout facility should
+ allow the user to choose whether or not to use a leading hierarchy
+ delimiter on the mailbox argument. This is because the handling of a
+ leading mailbox hierarchy delimiter also varies from server to
+ server, and even between different mailstores on the same server. In
+ some cases, a leading hierarchy delimiter means "discard the
+
+
+
+Leiba Informational [Page 18]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ reference argument" (implementing the intended breakout facility),
+ thus:
+
+ C: A001 LIST ABC/ /DEF
+ S: * LIST () "/" /DEF
+ S: A001 OK done
+
+ In other cases, however, the two are catenated and the extra
+ hierarchy delimiter is discarded, thus:
+
+ C: A001 LIST ABC/ /DEF
+ S: * LIST () "/" ABC/DEF
+ S: A001 OK done
+
+ Client implementations must not assume that the server supports a
+ breakout facility, but may provide a way for the user to use one if
+ it is available. Any breakout facility should be exported to the
+ user interface. Note that there may be other "breakout" characters
+ besides the hierarchy delimiter (for instance, UNIX filesystem
+ servers are likely to use a leading "~" as well), and that their
+ interpretation is server-dependent.
+
+3.4.10. Mailbox Hierarchy Delimiters
+
+ The server's selection of what to use as a mailbox hierarchy
+ delimiter is a difficult one, involving several issues: What
+ characters do users expect to see? What characters can they enter
+ for a hierarchy delimiter if it is desired (or required) that the
+ user enter it? What character can be used for the hierarchy
+ delimiter, noting that the chosen character can not otherwise be used
+ in the mailbox name?
+
+ Because some interfaces show users the hierarchy delimiters or allow
+ users to enter qualified mailbox names containing them, server
+ implementations should use delimiter characters that users generally
+ expect to see as name separators. The most common characters used
+ for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows
+ file names), and "." (as in news groups). There is little to choose
+ among these apart from what users may expect or what is dictated by
+ the underlying file system, if any. One consideration about using
+ "\" is that it's also a special character in the IMAP protocol. While
+ the use of other hierarchy delimiter characters is permissible, A
+ DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the
+ server is intended for special purposes only. Implementers might be
+ thinking about using characters such as "-", "_", ";", "&", "#", "@",
+ and "!", but they should be aware of the surprise to the user as well
+ as of the effect on URLs and other external specifications (since
+ some of these characters have special meanings there). Also, a
+
+
+
+Leiba Informational [Page 19]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ server that uses "\" (and clients of such a server) must remember to
+ escape that character in quoted strings or to send literals instead.
+ Literals are recommended over escaped characters in quoted strings in
+ order to maintain compatibility with older IMAP versions that did not
+ allow escaped characters in quoted strings (but check the grammar to
+ see where literals are allowed):
+
+ C: 001 LIST "" {13}
+ S: + send literal
+ C: this\%\%\%\h*
+ S: * LIST () "\\" {27}
+ S: this\is\a\mailbox\hierarchy
+ S: 001 OK LIST complete
+
+ In any case, a server should not use normal alpha-numeric characters
+ (such as "X" or "0") as delimiters; a user would be very surprised to
+ find that "EXPENDITURES" actually represented a two-level hierarchy.
+ And a server should not use characters that are non-printable or
+ difficult or impossible to enter on a standard US keyboard. Control
+ characters, box-drawing characters, and characters from non-US
+ alphabets fit into this category. Their use presents
+ interoperability problems that are best avoided.
+
+ The UTF-7 encoding of mailbox names also raises questions about what
+ to do with the hierarchy delimiters in encoded names: do we encode
+ each hierarchy level and separate them with delimiters, or do we
+ encode the fully qualified name, delimiters and all? The answer for
+ IMAP is the former: encode each hierarchy level separately, and
+ insert delimiters between. This makes it particularly important not
+ to use as a hierarchy delimiter a character that might cause
+ confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
+
+ To repeat: a server should use "/", "\", or "." as its hierarchy
+ delimiter. The use of any other character is likely to cause
+ problems and is STRONGLY DISCOURAGED.
+
+3.4.11. ALERT Response Codes
+
+ The protocol spec is very clear on the matter of what to do with
+ ALERT response codes, and yet there are many clients that violate it
+ so it needs to be said anyway: "The human-readable text contains a
+ special alert that must be presented to the user in a fashion that
+ calls the user's attention to the message." That should be clear
+ enough, but I'll repeat it here: Clients must present ALERT text
+ clearly to the user.
+
+
+
+
+
+
+Leiba Informational [Page 20]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+3.4.12. Deleting Mailboxes
+
+ The protocol does not guarantee that a client may delete a mailbox
+ that is not empty, though on some servers it is permissible and is,
+ in fact, much faster than the alternative or deleting all the
+ messages from the client. If the client chooses to try to take
+ advantage of this possibility it must be prepared to use the other
+ method in the even that the more convenient one fails. Further, a
+ client should not try to delete the mailbox that it has selected, but
+ should first close that mailbox; some servers do not permit the
+ deletion of the selected mailbox.
+
+ That said, a server should permit the deletion of a non-empty
+ mailbox; there's little reason to pass this work on to the client.
+ Moreover, forbidding this prevents the deletion of a mailbox that for
+ some reason can not be opened or expunged, leading to possible
+ denial-of-service problems.
+
+ Example:
+
+ [User tells the client to delete mailbox BANANA, which is
+ currently selected...]
+ C: 008 CLOSE
+ S: 008 OK done
+ C: 009 DELETE BANANA
+ S: 009 NO Delete failed; mailbox is not empty.
+ C: 010 SELECT BANANA
+ S: * ... untagged SELECT responses
+ S: 010 OK done
+ C: 011 STORE 1:* +FLAGS.SILENT \DELETED
+ S: 011 OK done
+ C: 012 CLOSE
+ S: 012 OK done
+ C: 013 DELETE BANANA
+ S: 013 OK done
+
+3.5. A Word About Testing
+
+ Since the whole point of IMAP is interoperability, and since
+ interoperability can not be tested in a vacuum, the final
+ recommendation of this treatise is, "Test against EVERYTHING." Test
+ your client against every server you can get an account on. Test
+ your server with every client you can get your hands on. Many
+ clients make limited test versions available on the Web for the
+ downloading. Many server owners will give serious client developers
+ guest accounts for testing. Contact them and ask. NEVER assume that
+ because your client works with one or two servers, or because your
+ server does fine with one or two clients, you will interoperate well
+
+
+
+Leiba Informational [Page 21]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+ in general.
+
+ In particular, in addition to everything else, be sure to test
+ against the reference implementations: the PINE client, the
+ University of Washington server, and the Cyrus server.
+
+ See the following URLs on the web for more information here:
+
+ IMAP Products and Sources: http://www.imap.org/products.html
+ IMC MailConnect: http://www.imc.org/imc-mailconnect
+
+4. Security Considerations
+
+ This document describes behaviour of clients and servers that use the
+ IMAP4 protocol, and as such, has the same security considerations as
+ described in [RFC-2060].
+
+5. 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-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
+ 2180, July 1997.
+
+ [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode
+ and ISO 10646", RFC 2044, October 1996.
+
+ [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe
+ Transformation Format of Unicode", RFC 2152, May 1997.
+
+ [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in
+ Progress.
+
+6. Author's Address
+
+ Barry Leiba
+ IBM T.J. Watson Research Center
+ 30 Saw Mill River Road
+ Hawthorne, NY 10532
+
+ Phone: 1-914-784-7941
+ EMail: leiba@watson.ibm.com
+
+
+
+
+
+Leiba Informational [Page 22]
+
+RFC 2683 IMAP4 Implementation Recommendations September 1999
+
+
+7. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Leiba Informational [Page 23]
+
diff --git a/RFC/rfc821.txt b/RFC/rfc821.txt new file mode 100644 index 00000000..d877b72c --- /dev/null +++ b/RFC/rfc821.txt @@ -0,0 +1,4050 @@ + + + + RFC 821 + + + + + + SIMPLE MAIL TRANSFER PROTOCOL + + + + Jonathan B. Postel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 1982 + + + + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, California 90291 + + (213) 822-1511 + + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + TABLE OF CONTENTS + + 1. INTRODUCTION .................................................. 1 + + 2. THE SMTP MODEL ................................................ 2 + + 3. THE SMTP PROCEDURE ............................................ 4 + + 3.1. Mail ..................................................... 4 + 3.2. Forwarding ............................................... 7 + 3.3. Verifying and Expanding .................................. 8 + 3.4. Sending and Mailing ..................................... 11 + 3.5. Opening and Closing ..................................... 13 + 3.6. Relaying ................................................ 14 + 3.7. Domains ................................................. 17 + 3.8. Changing Roles .......................................... 18 + + 4. THE SMTP SPECIFICATIONS ...................................... 19 + + 4.1. SMTP Commands ........................................... 19 + 4.1.1. Command Semantics ..................................... 19 + 4.1.2. Command Syntax ........................................ 27 + 4.2. SMTP Replies ............................................ 34 + 4.2.1. Reply Codes by Function Group ......................... 35 + 4.2.2. Reply Codes in Numeric Order .......................... 36 + 4.3. Sequencing of Commands and Replies ...................... 37 + 4.4. State Diagrams .......................................... 39 + 4.5. Details ................................................. 41 + 4.5.1. Minimum Implementation ................................ 41 + 4.5.2. Transparency .......................................... 41 + 4.5.3. Sizes ................................................. 42 + + APPENDIX A: TCP ................................................. 44 + APPENDIX B: NCP ................................................. 45 + APPENDIX C: NITS ................................................ 46 + APPENDIX D: X.25 ................................................ 47 + APPENDIX E: Theory of Reply Codes ............................... 48 + APPENDIX F: Scenarios ........................................... 51 + + GLOSSARY ......................................................... 64 + + REFERENCES ....................................................... 67 + + + + +Network Working Group J. Postel +Request for Comments: DRAFT ISI +Replaces: RFC 788, 780, 772 August 1982 + + SIMPLE MAIL TRANSFER PROTOCOL + + +1. INTRODUCTION + + The objective of Simple Mail Transfer Protocol (SMTP) is to transfer + mail reliably and efficiently. + + SMTP is independent of the particular transmission subsystem and + requires only a reliable ordered data stream channel. Appendices A, + B, C, and D describe the use of SMTP with various transport services. + A Glossary provides the definitions of terms as used in this + document. + + An important feature of SMTP is its capability to relay mail across + transport service environments. A transport service provides an + interprocess communication environment (IPCE). An IPCE may cover one + network, several networks, or a subset of a network. It is important + to realize that transport systems (or IPCEs) are not one-to-one with + networks. A process can communicate directly with another process + through any mutually known IPCE. Mail is an application or use of + interprocess communication. Mail can be communicated between + processes in different IPCEs by relaying through a process connected + to two (or more) IPCEs. More specifically, mail can be relayed + between hosts on different transport systems by a host on both + transport systems. + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 1] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +2. THE SMTP MODEL + + The SMTP design is based on the following model of communication: as + the result of a user mail request, the sender-SMTP establishes a + two-way transmission channel to a receiver-SMTP. The receiver-SMTP + may be either the ultimate destination or an intermediate. SMTP + commands are generated by the sender-SMTP and sent to the + receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the + sender-SMTP in response to the commands. + + Once the transmission channel is established, the SMTP-sender sends a + MAIL command indicating the sender of the mail. If the SMTP-receiver + can accept mail it responds with an OK reply. The SMTP-sender then + sends a RCPT command identifying a recipient of the mail. If the + SMTP-receiver can accept mail for that recipient it responds with an + OK reply; if not, it responds with a reply rejecting that recipient + (but not the whole mail transaction). The SMTP-sender and + SMTP-receiver may negotiate several recipients. When the recipients + have been negotiated the SMTP-sender sends the mail data, terminating + with a special sequence. If the SMTP-receiver successfully processes + the mail data it responds with an OK reply. The dialog is purposely + lock-step, one-at-a-time. + + ------------------------------------------------------------- + + + +----------+ +----------+ + +------+ | | | | + | User |<-->| | SMTP | | + +------+ | Sender- |Commands/Replies| Receiver-| + +------+ | SMTP |<-------------->| SMTP | +------+ + | File |<-->| | and Mail | |<-->| File | + |System| | | | | |System| + +------+ +----------+ +----------+ +------+ + + + Sender-SMTP Receiver-SMTP + + Model for SMTP Use + + Figure 1 + + ------------------------------------------------------------- + + The SMTP provides mechanisms for the transmission of mail; directly + from the sending user's host to the receiving user's host when the + + + +[Page 2] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + two host are connected to the same transport service, or via one or + more relay SMTP-servers when the source and destination hosts are not + connected to the same transport service. + + To be able to provide the relay capability the SMTP-server must be + supplied with the name of the ultimate destination host as well as + the destination mailbox name. + + The argument to the MAIL command is a reverse-path, which specifies + who the mail is from. The argument to the RCPT command is a + forward-path, which specifies who the mail is to. The forward-path + is a source route, while the reverse-path is a return route (which + may be used to return a message to the sender when an error occurs + with a relayed message). + + When the same message is sent to multiple recipients the SMTP + encourages the transmission of only one copy of the data for all the + recipients at the same destination host. + + The mail commands and replies have a rigid syntax. Replies also have + a numeric code. In the following, examples appear which use actual + commands and replies. The complete lists of commands and replies + appears in Section 4 on specifications. + + Commands and replies are not case sensitive. That is, a command or + reply word may be upper case, lower case, or any mixture of upper and + lower case. Note that this is not true of mailbox user names. For + some hosts the user name is case sensitive, and SMTP implementations + must take case to preserve the case of user names as they appear in + mailbox arguments. Host names are not case sensitive. + + Commands and replies are composed of characters from the ASCII + character set [1]. When the transport service provides an 8-bit byte + (octet) transmission channel, each 7-bit character is transmitted + right justified in an octet with the high order bit cleared to zero. + + When specifying the general form of a command or reply, an argument + (or special symbol) will be denoted by a meta-linguistic variable (or + constant), for example, "<string>" or "<reverse-path>". Here the + angle brackets indicate these are meta-linguistic variables. + However, some arguments use the angle brackets literally. For + example, an actual reverse-path is enclosed in angle brackets, i.e., + "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the + angle brackets are actually transmitted in the command or reply). + + + + + +Postel [Page 3] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +3. THE SMTP PROCEDURES + + This section presents the procedures used in SMTP in several parts. + First comes the basic mail procedure defined as a mail transaction. + Following this are descriptions of forwarding mail, verifying mailbox + names and expanding mailing lists, sending to terminals instead of or + in combination with mailboxes, and the opening and closing exchanges. + At the end of this section are comments on relaying, a note on mail + domains, and a discussion of changing roles. Throughout this section + are examples of partial command and reply sequences, several complete + scenarios are presented in Appendix F. + + 3.1. MAIL + + There are three steps to SMTP mail transactions. The transaction + is started with a MAIL command which gives the sender + identification. A series of one or more RCPT commands follows + giving the receiver information. Then a DATA command gives the + mail data. And finally, the end of mail data indicator confirms + the transaction. + + The first step in the procedure is the MAIL command. The + <reverse-path> contains the source mailbox. + + MAIL <SP> FROM:<reverse-path> <CRLF> + + This command tells the SMTP-receiver that a new mail + transaction is starting and to reset all its state tables and + buffers, including any recipients or mail data. It gives the + reverse-path which can be used to report errors. If accepted, + the receiver-SMTP returns a 250 OK reply. + + The <reverse-path> can contain more than just a mailbox. The + <reverse-path> is a reverse source routing list of hosts and + source mailbox. The first host in the <reverse-path> should be + the host sending this command. + + The second step in the procedure is the RCPT command. + + RCPT <SP> TO:<forward-path> <CRLF> + + This command gives a forward-path identifying one recipient. + If accepted, the receiver-SMTP returns a 250 OK reply, and + stores the forward-path. If the recipient is unknown the + receiver-SMTP returns a 550 Failure reply. This second step of + the procedure can be repeated any number of times. + + + +[Page 4] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + The <forward-path> can contain more than just a mailbox. The + <forward-path> is a source routing list of hosts and the + destination mailbox. The first host in the <forward-path> + should be the host receiving this command. + + The third step in the procedure is the DATA command. + + DATA <CRLF> + + If accepted, the receiver-SMTP returns a 354 Intermediate reply + and considers all succeeding lines to be the message text. + When the end of text is received and stored the SMTP-receiver + sends a 250 OK reply. + + Since the mail data is sent on the transmission channel the end + of the mail data must be indicated so that the command and + reply dialog can be resumed. SMTP indicates the end of the + mail data by sending a line containing only a period. A + transparency procedure is used to prevent this from interfering + with the user's text (see Section 4.5.2). + + Please note that the mail data includes the memo header + items such as Date, Subject, To, Cc, From [2]. + + The end of mail data indicator also confirms the mail + transaction and tells the receiver-SMTP to now process the + stored recipients and mail data. If accepted, the + receiver-SMTP returns a 250 OK reply. The DATA command should + fail only if the mail transaction was incomplete (for example, + no recipients), or if resources are not available. + + The above procedure is an example of a mail transaction. These + commands must be used only in the order discussed above. + Example 1 (below) illustrates the use of these commands in a mail + transaction. + + + + + + + + + + + + + + +Postel [Page 5] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of the SMTP Procedure + + This SMTP example shows mail sent by Smith at host Alpha.ARPA, + to Jones, Green, and Brown at host Beta.ARPA. Here we assume + that host Alpha contacts host Beta directly. + + S: MAIL FROM:<Smith@Alpha.ARPA> + R: 250 OK + + S: RCPT TO:<Jones@Beta.ARPA> + R: 250 OK + + S: RCPT TO:<Green@Beta.ARPA> + R: 550 No such user here + + S: RCPT TO:<Brown@Beta.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: <CRLF>.<CRLF> + R: 250 OK + + The mail has now been accepted for Jones and Brown. Green did + not have a mailbox at host Beta. + + Example 1 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + +[Page 6] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.2. FORWARDING + + There are some cases where the destination information in the + <forward-path> is incorrect, but the receiver-SMTP knows the + correct destination. In such cases, one of the following replies + should be used to allow the sender to contact the correct + destination. + + 251 User not local; will forward to <forward-path> + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use in the future. Note that either the + host or user or both may be different. The receiver takes + responsibility for delivering the message. + + 551 User not local; please try <forward-path> + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use. Note that either the host or user or + both may be different. The receiver refuses to accept mail + for this user, and the sender must either redirect the mail + according to the information provided or return an error + response to the originating user. + + Example 2 illustrates the use of these responses. + + ------------------------------------------------------------- + + Example of Forwarding + + Either + + S: RCPT TO:<Postel@USC-ISI.ARPA> + R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA> + + Or + + S: RCPT TO:<Paul@USC-ISIB.ARPA> + R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA> + + Example 2 + + ------------------------------------------------------------- + + + + +Postel [Page 7] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.3. VERIFYING AND EXPANDING + + SMTP provides as additional features, commands to verify a user + name or expand a mailing list. This is done with the VRFY and + EXPN commands, which have character string arguments. For the + VRFY command, the string is a user name, and the response may + include the full name of the user and must include the mailbox of + the user. For the EXPN command, the string identifies a mailing + list, and the multiline response may include the full name of the + users and must give the mailboxes on the mailing list. + + "User name" is a fuzzy term and used purposely. If a host + implements the VRFY or EXPN commands then at least local mailboxes + must be recognized as "user names". If a host chooses to + recognize other strings as "user names" that is allowed. + + In some hosts the distinction between a mailing list and an alias + for a single mailbox is a bit fuzzy, since a common data structure + may hold both types of entries, and it is possible to have mailing + lists of one mailbox. If a request is made to verify a mailing + list a positive response can be given if on receipt of a message + so addressed it will be delivered to everyone on the list, + otherwise an error should be reported (e.g., "550 That is a + mailing list, not a user"). If a request is made to expand a user + name a positive response can be formed by returning a list + containing one name, or an error can be reported (e.g., "550 That + is a user name, not a mailing list"). + + In the case of a multiline reply (normal for EXPN) exactly one + mailbox is to be specified on each line of the reply. In the case + of an ambiguous request, for example, "VRFY Smith", where there + are two Smith's the response must be "553 User ambiguous". + + The case of verifying a user name is straightforward as shown in + example 3. + + + + + + + + + + + + + + +[Page 8] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of Verifying a User Name + + Either + + S: VRFY Smith + R: 250 Fred Smith <Smith@USC-ISIF.ARPA> + + Or + + S: VRFY Smith + R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA> + + Or + + S: VRFY Jones + R: 550 String does not match anything. + + Or + + S: VRFY Jones + R: 551 User not local; please try <Jones@USC-ISIQ.ARPA> + + Or + + S: VRFY Gourzenkyinplatz + R: 553 User ambiguous. + + Example 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + +Postel [Page 9] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The case of expanding a mailbox list requires a multiline reply as + shown in example 4. + + ------------------------------------------------------------- + + Example of Expanding a Mailing List + + Either + + S: EXPN Example-People + R: 250-Jon Postel <Postel@USC-ISIF.ARPA> + R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> + R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA> + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250-<joe@foo-unix.ARPA> + R: 250 <xyz@bar-unix.ARPA> + + Or + + S: EXPN Executive-Washroom-List + R: 550 Access Denied to You. + + Example 4 + + ------------------------------------------------------------- + + The character string arguments of the VRFY and EXPN commands + cannot be further restricted due to the variety of implementations + of the user name and mailbox list concepts. On some systems it + may be appropriate for the argument of the EXPN command to be a + file name for a file containing a mailing list, but again there is + a variety of file naming conventions in the Internet. + + The VRFY and EXPN commands are not included in the minimum + implementation (Section 4.5.1), and are not required to work + across relays when they are implemented. + + + + + + + + + + + + + +[Page 10] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.4. SENDING AND MAILING + + The main purpose of SMTP is to deliver messages to user's + mailboxes. A very similar service provided by some hosts is to + deliver messages to user's terminals (provided the user is active + on the host). The delivery to the user's mailbox is called + "mailing", the delivery to the user's terminal is called + "sending". Because in many hosts the implementation of sending is + nearly identical to the implementation of mailing these two + functions are combined in SMTP. However the sending commands are + not included in the required minimum implementation + (Section 4.5.1). Users should have the ability to control the + writing of messages on their terminals. Most hosts permit the + users to accept or refuse such messages. + + The following three command are defined to support the sending + options. These are used in the mail transaction instead of the + MAIL command and inform the receiver-SMTP of the special semantics + of this transaction: + + SEND <SP> FROM:<reverse-path> <CRLF> + + The SEND command requires that the mail data be delivered to + the user's terminal. If the user is not active (or not + accepting terminal messages) on the host a 450 reply may + returned to a RCPT command. The mail transaction is + successful if the message is delivered the terminal. + + SOML <SP> FROM:<reverse-path> <CRLF> + + The Send Or MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. If the user is + not active (or not accepting terminal messages) then the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered either + to the terminal or the mailbox. + + SAML <SP> FROM:<reverse-path> <CRLF> + + The Send And MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. In any case the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered the + mailbox. + + + +Postel [Page 11] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The same reply codes that are used for the MAIL commands are used + for these commands. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 12] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.5. OPENING AND CLOSING + + At the time the transmission channel is opened there is an + exchange to ensure that the hosts are communicating with the hosts + they think they are. + + The following two commands are used in transmission channel + opening and closing: + + HELO <SP> <domain> <CRLF> + + QUIT <CRLF> + + In the HELO command the host sending the command identifies + itself; the command may be interpreted as saying "Hello, I am + <domain>". + + ------------------------------------------------------------- + + Example of Connection Opening + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + Example 5 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Example of Connection Closing + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Example 6 + + ------------------------------------------------------------- + + + + + + + + + + +Postel [Page 13] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.6. RELAYING + + The forward-path may be a source route of the form + "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This + form is used to emphasize the distinction between an address and a + route. The mailbox is an absolute address, and the route is + information about how to get there. The two concepts should not + be confused. + + Conceptually the elements of the forward-path are moved to the + reverse-path as the message is relayed from one server-SMTP to + another. The reverse-path is a reverse source route, (i.e., a + source route from the current location of the message to the + originator of the message). When a server-SMTP deletes its + identifier from the forward-path and inserts it into the + reverse-path, it must use the name it is known by in the + environment it is sending into, not the environment the mail came + from, in case the server-SMTP is known by different names in + different environments. + + If when the message arrives at an SMTP the first element of the + forward-path is not the identifier of that SMTP the element is not + deleted from the forward-path and is used to determine the next + SMTP to send the message to. In any case, the SMTP adds its own + identifier to the reverse-path. + + Using source routing the receiver-SMTP receives mail to be relayed + to another server-SMTP The receiver-SMTP may accept or reject the + task of relaying the mail in the same way it accepts or rejects + mail for a local user. The receiver-SMTP transforms the command + arguments by moving its own identifier from the forward-path to + the beginning of the reverse-path. The receiver-SMTP then becomes + a sender-SMTP, establishes a transmission channel to the next SMTP + in the forward-path, and sends it the mail. + + The first host in the reverse-path should be the host sending the + SMTP commands, and the first host in the forward-path should be + the host receiving the SMTP commands. + + Notice that the forward-path and reverse-path appear in the SMTP + commands and replies, but not necessarily in the message. That + is, there is no need for these paths and especially this syntax to + appear in the "To:" , "From:", "CC:", etc. fields of the message + header. + + If a server-SMTP has accepted the task of relaying the mail and + + + +[Page 14] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + later finds that the forward-path is incorrect or that the mail + cannot be delivered for whatever reason, then it must construct an + "undeliverable mail" notification message and send it to the + originator of the undeliverable mail (as indicated by the + reverse-path). + + This notification message must be from the server-SMTP at this + host. Of course, server-SMTPs should not send notification + messages about problems with notification messages. One way to + prevent loops in error reporting is to specify a null reverse-path + in the MAIL command of a notification message. When such a + message is relayed it is permissible to leave the reverse-path + null. A MAIL command with a null reverse-path appears as follows: + + MAIL FROM:<> + + An undeliverable mail notification message is shown in example 7. + This notification is in response to a message originated by JOE at + HOSTW and sent via HOSTX to HOSTY with instructions to relay it on + to HOSTZ. What we see in the example is the transaction between + HOSTY and HOSTX, which is the first step in the return of the + notification message. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 15] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example Undeliverable Mail Notification Message + + S: MAIL FROM:<> + R: 250 ok + S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA> + R: 250 ok + S: DATA + R: 354 send the mail data, end with . + S: Date: 23 Oct 81 11:22:33 + S: From: SMTP@HOSTY.ARPA + S: To: JOE@HOSTW.ARPA + S: Subject: Mail System Problem + S: + S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost. + S: HOSTZ.ARPA said this: + S: "550 No Such User" + S: . + R: 250 ok + + Example 7 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 16] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.7. DOMAINS + + Domains are a recently introduced concept in the ARPA Internet + mail system. The use of domains changes the address space from a + flat global space of simple character string host names to a + hierarchically structured rooted tree of global addresses. The + host name is replaced by a domain and host designator which is a + sequence of domain element strings separated by periods with the + understanding that the domain elements are ordered from the most + specific to the most general. + + For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and + "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers. + + Whenever domain names are used in SMTP only the official names are + used, the use of nicknames or aliases is not allowed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 17] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.8. CHANGING ROLES + + The TURN command may be used to reverse the roles of the two + programs communicating over the transmission channel. + + If program-A is currently the sender-SMTP and it sends the TURN + command and receives an ok reply (250) then program-A becomes the + receiver-SMTP. + + If program-B is currently the receiver-SMTP and it receives the + TURN command and sends an ok reply (250) then program-B becomes + the sender-SMTP. + + To refuse to change roles the receiver sends the 502 reply. + + Please note that this command is optional. It would not normally + be used in situations where the transmission channel is TCP. + However, when the cost of establishing the transmission channel is + high, this command may be quite useful. For example, this command + may be useful in supporting be mail exchange using the public + switched telephone system as a transmission channel, especially if + some hosts poll other hosts for mail exchanges. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 18] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +4. THE SMTP SPECIFICATIONS + + 4.1. SMTP COMMANDS + + 4.1.1. COMMAND SEMANTICS + + The SMTP commands define the mail transfer or the mail system + function requested by the user. SMTP commands are character + strings terminated by <CRLF>. The command codes themselves are + alphabetic characters terminated by <SP> if parameters follow + and <CRLF> otherwise. The syntax of mailboxes must conform to + receiver site conventions. The SMTP commands are discussed + below. The SMTP replies are discussed in the Section 4.2. + + A mail transaction involves several data objects which are + communicated as arguments to different commands. The + reverse-path is the argument of the MAIL command, the + forward-path is the argument of the RCPT command, and the mail + data is the argument of the DATA command. These arguments or + data objects must be transmitted and held pending the + confirmation communicated by the end of mail data indication + which finalizes the transaction. The model for this is that + distinct buffers are provided to hold the types of data + objects, that is, there is a reverse-path buffer, a + forward-path buffer, and a mail data buffer. Specific commands + cause information to be appended to a specific buffer, or cause + one or more buffers to be cleared. + + HELLO (HELO) + + This command is used to identify the sender-SMTP to the + receiver-SMTP. The argument field contains the host name of + the sender-SMTP. + + The receiver-SMTP identifies itself to the sender-SMTP in + the connection greeting reply, and in the response to this + command. + + This command and an OK reply to it confirm that both the + sender-SMTP and the receiver-SMTP are in the initial state, + that is, there is no transaction in progress and all state + tables and buffers are cleared. + + + + + + + +Postel [Page 19] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + MAIL (MAIL) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more mailboxes. The + argument field contains a reverse-path. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). In some types of error + reporting messages (for example, undeliverable mail + notifications) the reverse-path may be null (see Example 7). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RECIPIENT (RCPT) + + This command is used to identify an individual recipient of + the mail data; multiple recipients are specified by multiple + use of this command. + + The forward-path consists of an optional list of hosts and a + required destination mailbox. When the list of hosts is + present, it is a source route and indicates that the mail + must be relayed to the next host on the list. If the + receiver-SMTP does not implement the relay function it may + user the same reply it would for an unknown local user + (550). + + When mail is relayed, the relay host must remove itself from + the beginning forward-path and put itself at the beginning + of the reverse-path. When mail reaches its ultimate + destination (the forward-path contains only a destination + mailbox), the receiver-SMTP inserts it into the destination + mailbox in accordance with its host mail conventions. + + + + + +[Page 20] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + For example, mail received at relay host A with arguments + + FROM:<USERX@HOSTY.ARPA> + TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA> + + will be relayed on to host B with arguments + + FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA> + TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>. + + This command causes its forward-path argument to be appended + to the forward-path buffer. + + DATA (DATA) + + The receiver treats the lines following the command as mail + data from the sender. This command causes the mail data + from this command to be appended to the mail data buffer. + The mail data may contain any of the 128 ASCII character + codes. + + The mail data is terminated by a line containing only a + period, that is the character sequence "<CRLF>.<CRLF>" (see + Section 4.5.2 on Transparency). This is the end of mail + data indication. + + The end of mail data indication requires that the receiver + must now process the stored mail transaction information. + This processing consumes the information in the reverse-path + buffer, the forward-path buffer, and the mail data buffer, + and on the completion of this command these buffers are + cleared. If the processing is successful the receiver must + send an OK reply. If the processing fails completely the + receiver must send a failure reply. + + When the receiver-SMTP accepts a message either for relaying + or for final delivery it inserts at the beginning of the + mail data a time stamp line. The time stamp line indicates + the identity of the host that sent the message, and the + identity of the host that received the message (and is + inserting this time stamp), and the date and time the + message was received. Relayed messages will have multiple + time stamp lines. + + When the receiver-SMTP makes the "final delivery" of a + message it inserts at the beginning of the mail data a + + + +Postel [Page 21] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + return path line. The return path line preserves the + information in the <reverse-path> from the MAIL command. + Here, final delivery means the message leaves the SMTP + world. Normally, this would mean it has been delivered to + the destination user, but in some cases it may be further + processed and transmitted by another mail system. + + It is possible for the mailbox in the return path be + different from the actual sender's mailbox, for example, + if error responses are to be delivered a special error + handling mailbox rather than the message senders. + + The preceding two paragraphs imply that the final mail data + will begin with a return path line, followed by one or more + time stamp lines. These lines will be followed by the mail + data header and body [2]. See Example 8. + + Special mention is needed of the response and further action + required when the processing following the end of mail data + indication is partially successful. This could arise if + after accepting several recipients and the mail data, the + receiver-SMTP finds that the mail data can be successfully + delivered to some of the recipients, but it cannot be to + others (for example, due to mailbox space allocation + problems). In such a situation, the response to the DATA + command must be an OK reply. But, the receiver-SMTP must + compose and send an "undeliverable mail" notification + message to the originator of the message. Either a single + notification which lists all of the recipients that failed + to get the message, or separate notification messages must + be sent for each failed recipient (see Example 7). All + undeliverable mail notification messages are sent using the + MAIL command (even if they result from processing a SEND, + SOML, or SAML command). + + + + + + + + + + + + + + + +[Page 22] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of Return Path and Received Time Stamps + + Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA> + Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST + Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST + Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST + Date: 27 Oct 81 15:01:01 PST + From: JOE@ABC.ARPA + Subject: Improved Mailing System Installed + To: SAM@JKL.ARPA + + This is to inform you that ... + + Example 8 + + ------------------------------------------------------------- + + SEND (SEND) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals. The + argument field contains a reverse-path. This command is + successful if the message is delivered to a terminal. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND OR MAIL (SOML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals or + + + +Postel [Page 23] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), otherwise to the + recipient's mailbox. The argument field contains a + reverse-path. This command is successful if the message is + delivered to a terminal or the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND AND MAIL (SAML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals and + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), and for all + recipients to the recipient's mailbox. The argument field + contains a reverse-path. This command is successful if the + message is delivered to the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + + + +[Page 24] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RESET (RSET) + + This command specifies that the current mail transaction is + to be aborted. Any stored sender, recipients, and mail data + must be discarded, and all buffers and state tables cleared. + The receiver must send an OK reply. + + VERIFY (VRFY) + + This command asks the receiver to confirm that the argument + identifies a user. If it is a user name, the full name of + the user (if known) and the fully specified mailbox are + returned. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + EXPAND (EXPN) + + This command asks the receiver to confirm that the argument + identifies a mailing list, and if so, to return the + membership of that list. The full name of the users (if + known) and the fully specified mailboxes are returned in a + multiline reply. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + HELP (HELP) + + This command causes the receiver to send helpful information + to the sender of the HELP command. The command may take an + argument (e.g., any command name) and return more specific + information as a response. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + + + + + + + +Postel [Page 25] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + NOOP (NOOP) + + This command does not affect any parameters or previously + entered commands. It specifies no action other than that + the receiver send an OK reply. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + QUIT (QUIT) + + This command specifies that the receiver must send an OK + reply, and then close the transmission channel. + + The receiver should not close the transmission channel until + it receives and replies to a QUIT command (even if there was + an error). The sender should not close the transmission + channel until it send a QUIT command and receives the reply + (even if there was an error response to a previous command). + If the connection is closed prematurely the receiver should + act as if a RSET command had been received (canceling any + pending transaction, but not undoing any previously + completed transaction), the sender should act as if the + command or transaction in progress had received a temporary + error (4xx). + + TURN (TURN) + + This command specifies that the receiver must either (1) + send an OK reply and then take on the role of the + sender-SMTP, or (2) send a refusal reply and retain the role + of the receiver-SMTP. + + If program-A is currently the sender-SMTP and it sends the + TURN command and receives an OK reply (250) then program-A + becomes the receiver-SMTP. Program-A is then in the initial + state as if the transmission channel just opened, and it + then sends the 220 service ready greeting. + + If program-B is currently the receiver-SMTP and it receives + the TURN command and sends an OK reply (250) then program-B + becomes the sender-SMTP. Program-B is then in the initial + state as if the transmission channel just opened, and it + then expects to receive the 220 service ready greeting. + + To refuse to change roles the receiver sends the 502 reply. + + + +[Page 26] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + There are restrictions on the order in which these command may + be used. + + The first command in a session must be the HELO command. + The HELO command may be used later in a session as well. If + the HELO command argument is not acceptable a 501 failure + reply must be returned and the receiver-SMTP must stay in + the same state. + + The NOOP, HELP, EXPN, and VRFY commands can be used at any + time during a session. + + The MAIL, SEND, SOML, or SAML commands begin a mail + transaction. Once started a mail transaction consists of + one of the transaction beginning commands, one or more RCPT + commands, and a DATA command, in that order. A mail + transaction may be aborted by the RSET command. There may + be zero or more transactions in a session. + + If the transaction beginning command argument is not + acceptable a 501 failure reply must be returned and the + receiver-SMTP must stay in the same state. If the commands + in a transaction are out of order a 503 failure reply must + be returned and the receiver-SMTP must stay in the same + state. + + The last command in a session must be the QUIT command. The + QUIT command can not be used at any other time in a session. + + 4.1.2. COMMAND SYNTAX + + The commands consist of a command code followed by an argument + field. Command codes are four alphabetic characters. Upper + and lower case alphabetic characters are to be treated + identically. Thus, any of the following may represent the mail + command: + + MAIL Mail mail MaIl mAIl + + This also applies to any symbols representing parameter values, + such as "TO" or "to" for the forward-path. Command codes and + the argument fields are separated by one or more spaces. + However, within the reverse-path and forward-path arguments + case is important. In particular, in some hosts the user + "smith" is different from the user "Smith". + + + + +Postel [Page 27] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The argument field consists of a variable length character + string ending with the character sequence <CRLF>. The receiver + is to take no action until this sequence is received. + + Square brackets denote an optional argument field. If the + option is not taken, the appropriate default is implied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 28] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + The following are the SMTP commands: + + HELO <SP> <domain> <CRLF> + + MAIL <SP> FROM:<reverse-path> <CRLF> + + RCPT <SP> TO:<forward-path> <CRLF> + + DATA <CRLF> + + RSET <CRLF> + + SEND <SP> FROM:<reverse-path> <CRLF> + + SOML <SP> FROM:<reverse-path> <CRLF> + + SAML <SP> FROM:<reverse-path> <CRLF> + + VRFY <SP> <string> <CRLF> + + EXPN <SP> <string> <CRLF> + + HELP [<SP> <string>] <CRLF> + + NOOP <CRLF> + + QUIT <CRLF> + + TURN <CRLF> + + + + + + + + + + + + + + + + + + + + +Postel [Page 29] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The syntax of the above argument fields (using BNF notation + where applicable) is given below. The "..." notation indicates + that a field may be repeated one or more times. + + <reverse-path> ::= <path> + + <forward-path> ::= <path> + + <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">" + + <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l> + + <at-domain> ::= "@" <domain> + + <domain> ::= <element> | <element> "." <domain> + + <element> ::= <name> | "#" <number> | "[" <dotnum> "]" + + <mailbox> ::= <local-part> "@" <domain> + + <local-part> ::= <dot-string> | <quoted-string> + + <name> ::= <a> <ldh-str> <let-dig> + + <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> + + <let-dig> ::= <a> | <d> + + <let-dig-hyp> ::= <a> | <d> | "-" + + <dot-string> ::= <string> | <string> "." <dot-string> + + <string> ::= <char> | <char> <string> + + <quoted-string> ::= """ <qtext> """ + + <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext> + + <char> ::= <c> | "\" <x> + + <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> + + <number> ::= <d> | <d> <number> + + <CRLF> ::= <CR> <LF> + + + + +[Page 30] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + <CR> ::= the carriage return character (ASCII code 13) + + <LF> ::= the line feed character (ASCII code 10) + + <SP> ::= the space character (ASCII code 32) + + <snum> ::= one, two, or three digits representing a decimal + integer value in the range 0 through 255 + + <a> ::= any one of the 52 alphabetic characters A through Z + in upper case and a through z in lower case + + <c> ::= any one of the 128 ASCII characters, but not any + <special> or <SP> + + <d> ::= any one of the ten digits 0 through 9 + + <q> ::= any one of the 128 ASCII characters except <CR>, + <LF>, quote ("), or backslash (\) + + <x> ::= any one of the 128 ASCII characters (no exceptions) + + <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." + | "," | ";" | ":" | "@" """ | the control + characters (ASCII codes 0 through 31 inclusive and + 127) + + Note that the backslash, "\", is a quote character, which is + used to indicate that the next character is to be used + literally (instead of its normal interpretation). For example, + "Joe\,Smith" could be used to indicate a single nine character + user field with comma being the fourth character of the field. + + Hosts are generally known by names which are translated to + addresses in each host. Note that the name elements of domains + are the official names -- no use of nicknames or aliases is + allowed. + + Sometimes a host is not known to the translation function and + communication is blocked. To bypass this barrier two numeric + forms are also allowed for host "names". One form is a decimal + integer prefixed by a pound sign, "#", which indicates the + number is the address of the host. Another form is four small + decimal integers separated by dots and enclosed by brackets, + e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet + Address in four 8-bit fields. + + + +Postel [Page 31] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The time stamp line and the return path line are formally + defined as follows: + + <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF> + + <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF> + + <stamp> ::= <from-domain> <by-domain> <opt-info> ";" + <daytime> + + <from-domain> ::= "FROM" <SP> <domain> <SP> + + <by-domain> ::= "BY" <SP> <domain> <SP> + + <opt-info> ::= [<via>] [<with>] [<id>] [<for>] + + <via> ::= "VIA" <SP> <link> <SP> + + <with> ::= "WITH" <SP> <protocol> <SP> + + <id> ::= "ID" <SP> <string> <SP> + + <for> ::= "FOR" <SP> <path> <SP> + + <link> ::= The standard names for links are registered with + the Network Information Center. + + <protocol> ::= The standard names for protocols are + registered with the Network Information Center. + + <daytime> ::= <SP> <date> <SP> <time> + + <date> ::= <dd> <SP> <mon> <SP> <yy> + + <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone> + + <dd> ::= the one or two decimal integer day of the month in + the range 1 to 31. + + <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + <yy> ::= the two decimal integer year of the century in the + range 00 to 99. + + + + + +[Page 32] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + <hh> ::= the two decimal integer hour of the day in the + range 00 to 24. + + <mm> ::= the two decimal integer minute of the hour in the + range 00 to 59. + + <ss> ::= the two decimal integer second of the minute in the + range 00 to 59. + + <zone> ::= "UT" for Universal Time (the default) or other + time zone designator (as in [2]). + + + + ------------------------------------------------------------- + + Return Path Example + + Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> + + Example 9 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Time Stamp Line Example + + Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT + + Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 + id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT + + Example 10 + + ------------------------------------------------------------- + + + + + + + + + + + + + +Postel [Page 33] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2. SMTP REPLIES + + Replies to SMTP commands are devised to ensure the synchronization + of requests and actions in the process of mail transfer, and to + guarantee that the sender-SMTP always knows the state of the + receiver-SMTP. Every command must generate exactly one reply. + + The details of the command-reply sequence are made explicit in + Section 5.3 on Sequencing and Section 5.4 State Diagrams. + + An SMTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is meant for the human user. It is intended that + the three digits contain enough encoded information that the + sender-SMTP need not examine the text and may either discard it or + pass it on to the user, as appropriate. In particular, the text + may be receiver-dependent and context dependent, so there are + likely to be varying texts for each reply code. A discussion of + the theory of reply codes is given in Appendix E. Formally, a + reply is defined to be the sequence: a three-digit code, <SP>, + one line of text, and <CRLF>, or a multiline reply (as defined in + Appendix E). Only the EXPN and HELP commands are expected to + result in multiline replies in normal circumstances, however + multiline replies are allowed for any command. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 34] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.2.1. REPLY CODES BY FUNCTION GROUPS + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + + 220 <domain> Service ready + 221 <domain> Service closing transmission channel + 421 <domain> Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + + 250 Requested mail action okay, completed + 251 User not local; will forward to <forward-path> + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: error in processing + 551 User not local; please try <forward-path> + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 354 Start mail input; end with <CRLF>.<CRLF> + 554 Transaction failed + + + + + + + + + + + + + +Postel [Page 35] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2.2. NUMERIC ORDER LIST OF REPLY CODES + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 220 <domain> Service ready + 221 <domain> Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to <forward-path> + + 354 Start mail input; end with <CRLF>.<CRLF> + + 421 <domain> Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 551 User not local; please try <forward-path> + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 554 Transaction failed + + + + + + + + + + + + + +[Page 36] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.3. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue, controlled by the sender. As such, + the sender issues a command and the receiver responds with a + reply. The sender must wait for this response before sending + further commands. + + One important reply is the connection greeting. Normally, a + receiver will send a 220 "Service ready" reply when the connection + is completed. The sender should wait for this greeting message + before sending any commands. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + For example, + + 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF> + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + Each command is listed with its possible replies. The prefixes + used before the possible replies are "P" for preliminary (not + used in SMTP), "I" for intermediate, "S" for success, "F" for + failure, and "E" for error. The 421 reply (service not + available, closing transmission channel) may be given to any + command if the SMTP-receiver knows it must shut down. This + listing forms the basis for the State Diagrams in Section 4.4. + + CONNECTION ESTABLISHMENT + S: 220 + F: 421 + HELO + S: 250 + E: 500, 501, 504, 421 + MAIL + S: 250 + F: 552, 451, 452 + E: 500, 501, 421 + + + +Postel [Page 37] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + RCPT + S: 250, 251 + F: 550, 551, 552, 553, 450, 451, 452 + E: 500, 501, 503, 421 + DATA + I: 354 -> data -> S: 250 + F: 552, 554, 451, 452 + F: 451, 554 + E: 500, 501, 503, 421 + RSET + S: 250 + E: 500, 501, 504, 421 + SEND + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SOML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SAML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + VRFY + S: 250, 251 + F: 550, 551, 553 + E: 500, 501, 502, 504, 421 + EXPN + S: 250 + F: 550 + E: 500, 501, 502, 504, 421 + HELP + S: 211, 214 + E: 500, 501, 502, 504, 421 + NOOP + S: 250 + E: 500, 421 + QUIT + S: 221 + E: 500 + TURN + S: 250 + F: 502 + E: 500, 503 + + + + +[Page 38] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.4. STATE DIAGRAMS + + Following are state diagrams for a simple-minded SMTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of SMTP commands. The + command groupings were determined by constructing a model for each + command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" + (S), "failure" (F), and "error" (E). In the state diagrams below + we use the symbol B for "begin", and the symbol W for "wait for + reply". + + First, the diagram that represents most of the SMTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, + NOOP, QUIT, TURN. + + + + + + + + + + + + + + + +Postel [Page 39] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + A more complex diagram models the DATA command: + + + +---+ DATA +---+ 1,2 +---+ + | B |---------->| W |-------------------->| E | + +---+ +---+ ------------>+---+ + 3| |4,5 | + | | | + -------------- ----- | + | | | +---+ + | ---------- -------->| S | + | | | | +---+ + | | ------------ + | | | | + V 1,3| |2 | + +---+ data +---+ --------------->+---+ + | |---------->| W | | F | + +---+ +---+-------------------->+---+ + 4,5 + + + Note that the "data" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 40] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.5. DETAILS + + 4.5.1. MINIMUM IMPLEMENTATION + + In order to make SMTP workable, the following minimum + implementation is required for all receivers: + + COMMANDS -- HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + + 4.5.2. TRANSPARENCY + + Without some provision for data transparency the character + sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent + by the user. In general, users are not aware of such + "forbidden" sequences. To allow all user composed text to be + transmitted transparently the following procedures are used. + + 1. Before sending a line of mail text the sender-SMTP checks + the first character of the line. If it is a period, one + additional period is inserted at the beginning of the line. + + 2. When a line of mail text is received by the receiver-SMTP + it checks the line. If the line is composed of a single + period it is the end of mail. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipient's mailbox + including format effectors and other control characters. If + the transmission channel provides an 8-bit byte (octets) data + stream, the 7-bit ASCII codes are transmitted right justified + in the octets with the high order bits cleared to zero. + + In some systems it may be necessary to transform the data as + it is received and stored. This may be necessary for hosts + that use a different character set than ASCII as their local + character set, or that store data in records rather than + + + + + +Postel [Page 41] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + strings. If such transforms are necessary, they must be + reversible -- especially if such transforms are applied to + mail being relayed. + + 4.5.3. SIZES + + There are several objects that have required minimum maximum + sizes. That is, every implementation must be able to receive + objects of at least these sizes, but must not send objects + larger than these sizes. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + user + + The maximum total length of a user name is 64 characters. + + domain + + The maximum total length of a domain name or number is 64 + characters. + + path + + The maximum total length of a reverse-path or + forward-path is 256 characters (including the punctuation + and element separators). + + command line + + The maximum total length of a command line including the + command word and the <CRLF> is 512 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the <CRLF> is 512 characters. + + + + + +[Page 42] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + text line + + The maximum total length of a text line including the + <CRLF> is 1000 characters (but not counting the leading + dot duplicated for transparency). + + recipients buffer + + The maximum total number of recipients that must be + buffered is 100 recipients. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + Errors due to exceeding these limits may be reported by using + the reply codes, for example: + + 500 Line too long. + + 501 Path too long + + 552 Too many recipients. + + 552 Too much mail data. + + + + + + + + + + + + + + + + + + + +Postel [Page 43] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX A + + TCP Transport service + + The Transmission Control Protocol [3] is used in the ARPA + Internet, and in any network following the US DoD standards for + internetwork protocols. + + Connection Establishment + + The SMTP transmission channel is a TCP connection established + between the sender process port U and the receiver process port + L. This single full duplex connection is used as the + transmission channel. This protocol is assigned the service + port 25 (31 octal), that is L=25. + + Data Transfer + + The TCP connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 44] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX B + + NCP Transport service + + The ARPANET Host-to-Host Protocol [4] (implemented by the Network + Control Program) may be used in the ARPANET. + + Connection Establishment + + The SMTP transmission channel is established via NCP between + the sender process socket U and receiver process socket L. The + Initial Connection Protocol [5] is followed resulting in a pair + of simplex connections. This pair of connections is used as + the transmission channel. This protocol is assigned the + contact socket 25 (31 octal), that is L=25. + + Data Transfer + + The NCP data connections are established in 8-bit byte mode. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 45] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX C + + NITS + + The Network Independent Transport Service [6] may be used. + + Connection Establishment + + The SMTP transmission channel is established via NITS between + the sender process and receiver process. The sender process + executes the CONNECT primitive, and the waiting receiver + process executes the ACCEPT primitive. + + Data Transfer + + The NITS connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 46] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX D + + X.25 Transport service + + It may be possible to use the X.25 service [7] as provided by the + Public Data Networks directly, however, it is suggested that a + reliable end-to-end protocol such as TCP be used on top of X.25 + connections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 47] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX E + + Theory of Reply Codes + + The three digits of the reply each have a special significance. + The first digit denotes whether the response is good, bad or + incomplete. An unsophisticated sender-SMTP will be able to + determine its next action (proceed as planned, redo, retrench, + etc.) by simply examining this first digit. A sender-SMTP that + wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit, reserving the third digit for the finest gradation of + information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The command has been accepted, but the requested action + is being held in abeyance, pending confirmation of the + information in this reply. The sender-SMTP should send + another command specifying whether to continue or abort + the action. + + [Note: SMTP does not have any commands that allow this + type of reply, and so does not have the continue or + abort commands.] + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The sender-SMTP should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should + + + +[Page 48] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + return to the beginning of the command sequence (if any). + It is difficult to assign a meaning to "transient" when + two different sites (receiver- and sender- SMTPs) must + agree on the interpretation. Each reply in this category + might have a different time value, but the sender-SMTP is + encouraged to try again. A rule of thumb to determine if + a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be repeated without + any change in command form or in properties of the sender + or receiver. (E.g., the command is repeated identically + and the receiver does not put up a new implementation.) + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-SMTP is discouraged from repeating + the exact request (in the same sequence). Even some + "permanent" error conditions can be corrected, so the + human user may want to direct the sender-SMTP to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered the account status). + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the + transmission channel. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of + the receiver mail system vis-a-vis the requested + transfer or other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies + + + +Postel [Page 49] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + illustrates this. Each reply text is recommended rather than + mandatory, and may even change according to the command with + which it is associated. On the other hand, the reply codes + must strictly follow the specifications in this section. + Receiver implementations should not invent new codes for + slightly different situations from the ones described here, but + rather adapt codes already defined. + + For example, a command such as NOOP whose successful execution + does not offer the sender-SMTP any new information will return + a 250 reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that is implemented, but that + requests an unimplemented parameter. + + The reply text may be longer than a single line; in these cases + the complete text must be marked so the sender-SMTP knows when it + can stop reading the reply. This requires a special format to + indicate a multiple line reply. + + The format for multiline replies requires that every line, + except the last, begin with the reply code, followed + immediately by a hyphen, "-" (also known as minus), followed by + text. The last line will begin with the reply code, followed + immediately by <SP>, optionally some text, and <CRLF>. + + For example: + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + In many cases the sender-SMTP then simply needs to search for + the reply code followed by <SP> at the beginning of a line, and + ignore all preceding lines. In a few cases, there is important + data for the sender in the reply "text". The sender will know + these cases from the current context. + + + + + + + + + + + + +[Page 50] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX F + + Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. + + A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host USC-ISIF, to + Jones, Green, and Brown at host BBN-UNIX. Here we assume that + host USC-ISIF contacts host BBN-UNIX directly. The mail is + accepted for Jones and Brown. Green does not have a mailbox at + host BBN-UNIX. + + ------------------------------------------------------------- + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + S: MAIL FROM:<Smith@USC-ISIF.ARPA> + R: 250 OK + + S: RCPT TO:<Jones@BBN-UNIX.ARPA> + R: 250 OK + + S: RCPT TO:<Green@BBN-UNIX.ARPA> + R: 550 No such user here + + S: RCPT TO:<Brown@BBN-UNIX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Scenario 1 + + ------------------------------------------------------------- + + + +Postel [Page 51] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Aborted SMTP Transaction Scenario + + ------------------------------------------------------------- + + R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready + S: HELO ISI-VAXA.ARPA + R: 250 MIT-Multics.ARPA + + S: MAIL FROM:<Smith@ISI-VAXA.ARPA> + R: 250 OK + + S: RCPT TO:<Jones@MIT-Multics.ARPA> + R: 250 OK + + S: RCPT TO:<Green@MIT-Multics.ARPA> + R: 550 No such user here + + S: RSET + R: 250 OK + + S: QUIT + R: 221 MIT-Multics.ARPA Service closing transmission channel + + Scenario 2 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + +[Page 52] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Relayed Mail Scenario + + ------------------------------------------------------------- + + Step 1 -- Source Host to Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-AI.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM:<JQP@MIT-AI.ARPA> + R: 250 OK + + S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public <JQP@MIT-AI.ARPA> + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + +Postel [Page 53] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 2 -- Relay Host to Destination Host + + R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIE.ARPA + R: 250 BBN-VAX.ARPA + + S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> + R: 250 OK + + S: RCPT TO:<Jones@BBN-VAX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; + 2 Nov 81 22:40:10 UT + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public <JQP@MIT-AI.ARPA> + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + +[Page 54] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Verifying and Sending Scenario + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> + + S: SEND FROM:<EAK@MIT-MC.ARPA> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 4 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 55] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Sending and Mailing Scenarios + + First the user's name is verified, then an attempt is made to + send to the user's terminal. When that fails, the messages is + mailed to the user's mailbox. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> + + S: SEND FROM:<EAK@MIT-MC.ARPA> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> + R: 450 User not active now + + S: RSET + R: 250 OK + + S: MAIL FROM:<EAK@MIT-MC.ARPA> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 5 + + ------------------------------------------------------------- + + + + + + +[Page 56] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Doing the preceding scenario more efficiently. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> + + S: SOML FROM:<EAK@MIT-MC.ARPA> + R: 250 OK + + S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> + R: 250 User not active now, so will do mail. + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 6 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 57] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Mailing List Scenario + + First each of two mailing lists are expanded in separate sessions + with different hosts. Then the message is sent to everyone that + appeared on either list (but no duplicates) via a relay host. + + ------------------------------------------------------------- + + Step 1 -- Expanding the First List + + R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-AI.ARPA + + S: EXPN Example-People + R: 250-<ABC@MIT-MC.ARPA> + R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> + R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA> + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250-<joe@foo-unix.ARPA> + R: 250 <xyz@bar-unix.ARPA> + + S: QUIT + R: 221 MIT-AI.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 58] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Step 2 -- Expanding the Second List + + R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-MC.ARPA + + S: EXPN Interested-Parties + R: 250-Al Calico <ABC@MIT-MC.ARPA> + R: 250-<XYZ@MIT-AI.ARPA> + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250-<fred@BBN-UNIX.ARPA> + R: 250 <xyz@bar-unix.ARPA> + + S: QUIT + R: 221 MIT-MC.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 59] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 3 -- Mailing to All via a Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM:<Account.Person@SU-SCORE.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> + R: 250 OK + S: RCPT + TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 7 + + ------------------------------------------------------------- + + + + + + + + + + + + +[Page 60] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Forwarding Scenarios + + ------------------------------------------------------------- + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM:<mo@LBL-UNIX.ARPA> + R: 250 OK + + S: RCPT TO:<fred@USC-ISIF.ARPA> + R: 251 User not local; will forward to <Jones@USC-ISI.ARPA> + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Scenario 8 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 61] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Step 1 -- Trying the Mailbox at the First Host + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM:<mo@LBL-UNIX.ARPA> + R: 250 OK + + S: RCPT TO:<fred@USC-ISIF.ARPA> + R: 251 User not local; will forward to <Jones@USC-ISI.ARPA> + + S: RSET + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Step 2 -- Delivering the Mail at the Second Host + + R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISI.ARPA + + S: MAIL FROM:<mo@LBL-UNIX.ARPA> + R: 250 OK + + S: RCPT TO:<Jones@USC-ISI.ARPA> + R: OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISI.ARPA Service closing transmission channel + + Scenario 9 + + ------------------------------------------------------------- + + + + +[Page 62] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Too Many Recipients Scenario + + ------------------------------------------------------------- + + R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BERKELEY.ARPA + + S: MAIL FROM:<Postel@USC-ISIF.ARPA> + R: 250 OK + + S: RCPT TO:<fabry@BERKELEY.ARPA> + R: 250 OK + + S: RCPT TO:<eric@BERKELEY.ARPA> + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM:<Postel@USC-ISIF.ARPA> + R: 250 OK + + S: RCPT TO:<eric@BERKELEY.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with <CRLF>.<CRLF> + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BERKELEY.ARPA Service closing transmission channel + + Scenario 10 + + ------------------------------------------------------------- + + Note that a real implementation must handle many recipients as + specified in Section 4.5.3. + + + +Postel [Page 63] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +GLOSSARY + + ASCII + + American Standard Code for Information Interchange [1]. + + command + + A request for a mail service action sent by the sender-SMTP to the + receiver-SMTP. + + domain + + The hierarchially structured global character string address of a + host computer in the mail system. + + end of mail data indication + + A special sequence of characters that indicates the end of the + mail data. In particular, the five characters carriage return, + line feed, period, carriage return, line feed, in that order. + + host + + A computer in the internetwork environment on which mailboxes or + SMTP processes reside. + + line + + A a sequence of ASCII characters ending with a <CRLF>. + + mail data + + A sequence of ASCII characters of arbitrary length, which conforms + to the standard set in the Standard for the Format of ARPA + Internet Text Messages (RFC 822 [2]). + + mailbox + + A character string (address) which identifies a user to whom mail + is to be sent. Mailbox normally consists of the host and user + specifications. The standard mailbox naming convention is defined + to be "user@domain". Additionally, the "container" in which mail + is stored. + + + + + +[Page 64] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + receiver-SMTP process + + A process which transfers mail in cooperation with a sender-SMTP + process. It waits for a connection to be established via the + transport service. It receives SMTP commands from the + sender-SMTP, sends replies, and performs the specified operations. + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes are + for use by programs and the text is usually intended for human + users. + + sender-SMTP process + + A process which transfers mail in cooperation with a receiver-SMTP + process. A local language may be used in the user interface + command/reply dialogue. The sender-SMTP initiates the transport + service connection. It initiates SMTP commands, receives replies, + and governs the transfer of mail. + + session + + The set of exchanges that occur while the transmission channel is + open. + + transaction + + The set of exchanges required for one message to be transmitted + for one or more recipients. + + transmission channel + + A full-duplex communication path between a sender-SMTP and a + receiver-SMTP for the exchange of commands, replies, and mail + text. + + transport service + + Any reliable stream-oriented data communication services. For + example, NCP, TCP, NITS. + + + + + +Postel [Page 65] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + user + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + word + + A sequence of printing characters. + + <CRLF> + + The characters carriage return and line feed (in that order). + + <SP> + + The space character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 66] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +REFERENCES + + [1] ASCII + + ASCII, "USA Code for Information Interchange", United States of + America Standards Institute, X3.4, 1968. Also in: Feinler, E. + and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for + the Defense Communications Agency by SRI International, Menlo + Park, California, Revised January 1978. + + [2] RFC 822 + + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages," RFC 822, Department of Electrical Engineering, + University of Delaware, August 1982. + + [3] TCP + + Postel, J., ed., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, USC/Information Sciences + Institute, NTIS AD Number A111091, September 1981. Also in: + Feinler, E. and J. Postel, eds., "Internet Protocol Transition + Workbook", SRI International, Menlo Park, California, March 1982. + + [4] NCP + + McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, + January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [5] Initial Connection Protocol + + Postel, J., "Official Initial Connection Protocol", NIC 7101, + 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [6] NITS + + PSS/SG3, "A Network Independent Transport Service", Study Group 3, + The Post Office PSS Users Group, February 1980. Available from + the DCPU, National Physical Laboratory, Teddington, UK. + + + + +Postel [Page 67] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + [7] X.25 + + CCITT, "Recommendation X.25 - Interface Between Data Terminal + Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for + Terminals Operating in the Packet Mode on Public Data Networks," + CCITT Orange Book, Vol. VIII.2, International Telephone and + Telegraph Consultative Committee, Geneva, 1976. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 68] Postel + diff --git a/RFC/rfc822.txt b/RFC/rfc822.txt new file mode 100644 index 00000000..35b09a3c --- /dev/null +++ b/RFC/rfc822.txt @@ -0,0 +1,2901 @@ + + + + + + + RFC # 822 + + Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA INTERNET TEXT MESSAGES + + + + + + + August 13, 1982 + + + + + + + Revised by + + David H. Crocker + + + Dept. of Electrical Engineering + University of Delaware, Newark, DE 19711 + Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + + + TABLE OF CONTENTS + + + PREFACE .................................................... ii + + 1. INTRODUCTION ........................................... 1 + + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 + + 2. NOTATIONAL CONVENTIONS ................................. 3 + + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 + + 4. MESSAGE SPECIFICATION .................................. 17 + + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 + + 5. DATE AND TIME SPECIFICATION ............................ 26 + + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 + + 6. ADDRESS SPECIFICATION .................................. 27 + + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 + + 7. BIBLIOGRAPHY ........................................... 34 + + + APPENDIX + + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + + + August 13, 1982 - i - RFC #822 + + + + + Standard for ARPA Internet Text Messages + + + PREFACE + + + By 1977, the Arpanet employed several informal standards for + the text messages (mail) sent among its host computers. It was + felt necessary to codify these practices and provide for those + features that seemed imminent. The result of that effort was + Request for Comments (RFC) #733, "Standard for the Format of ARPA + Network Text Message", by Crocker, Vittal, Pogran, and Henderson. + The specification attempted to avoid major changes in existing + software, while permitting several new features. + + This document revises the specifications in RFC #733, in + order to serve the needs of the larger and more complex ARPA + Internet. Some of RFC #733's features failed to gain adequate + acceptance. In order to simplify the standard and the software + that follows it, these features have been removed. A different + addressing scheme is used, to handle the case of inter-network + mail; and the concept of re-transmission has been introduced. + + This specification is intended for use in the ARPA Internet. + However, an attempt has been made to free it of any dependence on + that environment, so that it can be applied to other network text + message systems. + + The specification of RFC #733 took place over the course of + one year, using the ARPANET mail environment, itself, to provide + an on-going forum for discussing the capabilities to be included. + More than twenty individuals, from across the country, partici- + pated in the original discussion. The development of this + revised specification has, similarly, utilized network mail-based + group discussion. Both specification efforts greatly benefited + from the comments and ideas of the participants. + + The syntax of the standard, in RFC #733, was originally + specified in the Backus-Naur Form (BNF) meta-language. 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. + + + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1. INTRODUCTION + + 1.1. SCOPE + + This standard specifies a syntax for text messages that are + sent among computer users, within the framework of "electronic + mail". The standard supersedes the one specified in ARPANET + Request for Comments #733, "Standard for the Format of ARPA Net- + work Text Messages". + + In this context, messages are viewed as having an envelope + and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. The contents + compose the object to be delivered to the recipient. This stan- + dard applies only to the format and some of the semantics of mes- + sage contents. It contains no specification of the information + in the envelope. + + However, some message systems may use information from the + contents to create the envelope. It is intended that this stan- + dard facilitate the acquisition of such information by programs. + + Some message systems may store messages in formats that + differ from the one specified in this standard. This specifica- + tion is intended strictly as a definition of what message content + format is to be passed BETWEEN hosts. + + Note: This standard is NOT intended to dictate the internal for- + mats used by sites, the specific message system features + that they are expected to support, or any of the charac- + teristics of user interface programs that create or read + messages. + + A distinction should be made between what the specification + REQUIRES and what it ALLOWS. Messages can be made complex and + rich with formally-structured components of information or can be + kept small and simple, with a minimum of such information. Also, + the standard simplifies the interpretation of differing visual + formats in messages; only the visual aspect of a message is + affected and not the interpretation of information within it. + Implementors may choose to retain such visual distinctions. + + The formal definition is divided into four levels. The bot- + tom level describes the meta-notation used in this document. The + second level describes basic lexical analyzers that feed tokens + to higher-level parsers. Next is an overall specification for + messages; it permits distinguishing individual fields. Finally, + there is definition of the contents of several structured fields. + + + + August 13, 1982 - 1 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1.2. COMMUNICATION FRAMEWORK + + Messages consist of lines of text. No special provisions + are made for encoding drawings, facsimile, speech, or structured + text. No significant consideration has been given to questions + of data compression or to transmission and storage efficiency, + and the standard tends to be free with the number of bits con- + sumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message con- + sists of some information in a rigid format, followed by the main + part of the message, with a format that is not specified in this + document. The syntax of several fields of the rigidly-formated + ("headers") section is defined in this specification; some of + these fields must be included in all messages. + + The syntax that distinguishes between header fields is + specified separately from the internal syntax for particular + fields. This separation is intended to allow simple parsers to + operate on the general structure of messages, without concern for + the detailed structure of individual header fields. Appendix B + is provided to facilitate construction of these parsers. + + In addition to the fields specified in this document, it is + expected that other fields will gain common use. As necessary, + the specifications for these "extension-fields" will be published + through the same mechanism used to publish this document. Users + may also wish to extend the set of fields that they use + privately. Such "user-defined fields" are permitted. + + The framework severely constrains document tone and appear- + ance and is primarily useful for most intra-organization communi- + cations and well-structured inter-organization communication. + It also can be used for some types of inter-process communica- + tion, such as simple file transfer and remote job entry. A more + robust framework might allow for multi-font, multi-color, multi- + dimension encoding of information. A less robust one, as is + present in most single-machine message systems, would more + severely constrain the ability to add fields and the decision to + include specific fields. In contrast with paper-based communica- + tion, it is interesting to note that the RECEIVER of a message + can exercise an extraordinary amount of control over the + message's appearance. The amount of actual control available to + message receivers is contingent upon the capabilities of their + individual message systems. + + + + + + August 13, 1982 - 2 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2. NOTATIONAL CONVENTIONS + + This specification uses an augmented Backus-Naur Form (BNF) + notation. The differences from standard BNF involve naming rules + and indicating repetition and "local" alternatives. + + 2.1. RULE NAMING + + Angle brackets ("<", ">") are not used, in general. The + name of a rule is simply the name itself, rather than "<name>". + Quotation-marks enclose literal text (which may be upper and/or + lower case). Certain basic rules are in uppercase, such as + SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in + rule definitions, and in the rest of this document, whenever + their presence will facilitate discerning the use of rule names. + + 2.2. RULE1 / RULE2: ALTERNATIVES + + Elements separated by slash ("/") are alternatives. There- + fore "foo / bar" will accept foo or bar. + + 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES + + Elements enclosed in parentheses are treated as a single + element. Thus, "(elem (foo / bar) elem)" allows the token + sequences "elem foo elem" and "elem bar elem". + + 2.4. *RULE: REPETITION + + The character "*" preceding an element indicates repetition. + The full form is: + + <l>*<m>element + + indicating at least <l> and at most <m> occurrences of element. + Default values are 0 and infinity so that "*(element)" allows any + number, including zero; "1*element" requires at least one; and + "1*2element" allows one or two. + + 2.5. [RULE]: OPTIONAL + + Square brackets enclose optional elements; "[foo bar]" is + equivalent to "*1(foo bar)". + + 2.6. NRULE: SPECIFIC REPETITION + + "<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. + + + August 13, 1982 - 3 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2.7. #RULE: LISTS + + A construct "#" is defined, similar to "*", as follows: + + <l>#<m>element + + indicating at least <l> and at most <m> elements, each separated + by one or more commas (","). This makes the usual form of lists + very easy; a rule such as '(element *("," element))' can be shown + as "1#element". Wherever this construct is used, null elements + are allowed, but do not contribute to the count of elements + present. That is, "(element),,(element)" is permitted, but + counts as only two elements. Therefore, where at least one ele- + ment is required, at least one non-null element must be present. + Default values are 0 and infinity so that "#(element)" allows any + number, including zero; "1#element" requires at least one; and + "1#2element" allows one or two. + + 2.8. ; COMMENTS + + A semi-colon, set off some distance to the right of rule + text, starts a comment that continues to the end of line. This + is a simple way of including useful notes in parallel with the + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3. LEXICAL ANALYSIS OF MESSAGES + + 3.1. GENERAL DESCRIPTION + + A message consists of header fields and, optionally, a body. + The body is simply a sequence of lines containing ASCII charac- + ters. It is separated from the headers by a null line (i.e., a + line with nothing preceding the CRLF). + + 3.1.1. LONG HEADER FIELDS + + Each header field can be viewed as a single, logical line of + ASCII characters, comprising a field-name and a field-body. + For convenience, the field-body portion of this conceptual + entity can be split into a multiple-line representation; this + is called "folding". The general rule is that wherever there + may be linear-white-space (NOT simply LWSP-chars), a CRLF + immediately followed by AT LEAST one LWSP-char may instead be + inserted. Thus, the single line + + To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" <ddd @ Org>, + JJV@BBN + + and + + To: "Joe & J. Harvey" + <ddd@ Org>, JJV + @BBN + + and + + To: "Joe & + J. Harvey" <ddd @ Org>, JJV @ BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line represen- + tation is called "unfolding". Unfolding is accomplished by + regarding CRLF immediately followed by a LWSP-char as + equivalent to the LWSP-char. + + Note: While the standard permits folding wherever linear- + white-space is permitted, it is recommended that struc- + tured fields, such as those containing addresses, limit + folding to higher-level syntactic breaks. For address + fields, it is recommended that such folding occur + + + August 13, 1982 - 5 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + between addresses, after the separating comma. + + 3.1.2. STRUCTURE OF HEADER FIELDS + + Once a field has been unfolded, it may be viewed as being com- + posed of a field-name followed by a colon (":"), followed by a + field-body, and terminated by a carriage-return/line-feed. + The field-name must be composed of printable ASCII characters + (i.e., characters that have values between 33. and 126., + decimal, except colon). The field-body may be composed of any + ASCII characters, except CR or LF. (While CR and/or LF may be + present in the actual text, they are removed by the action of + unfolding the field.) + + Certain field-bodies of headers may be interpreted according + to an internal syntax that some systems may wish to parse. + These fields are called "structured fields". Examples + include fields containing dates and addresses. Other fields, + such as "Subject" and "Comments", are regarded simply as + strings of text. + + Note: Any field which has a field-body that is defined as + other than simply <text> is to be treated as a struc- + tured field. + + Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, independent + "lexical" analyzers. + + 3.1.3. UNSTRUCTURED FIELD BODIES + + For some fields, such as "Subject" and "Comments", no struc- + turing is assumed, and they are treated simply as <text>s, as + in the message body. Rules of folding apply to these fields, + so that such field bodies which occupy several lines must + therefore have the second and successive lines indented by at + least one LWSP-char. + + 3.1.4. STRUCTURED FIELD BODIES + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed between lexical tokens. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear-white- + space, the existence of another "lexical" analyzer is assumed. + This analyzer does not apply for unstructured field bodies + that are simply strings of text, as described above. The + analyzer provides an interpretation of the unfolded text + + + August 13, 1982 - 6 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + composing the body of the field as a sequence of lexical sym- + bols. + + These symbols are: + + - individual special characters + - quoted-strings + - domain-literals + - comments + - atoms + + The first four of these symbols are self-delimiting. Atoms + are not; they are delimited by the self-delimiting symbols and + by linear-white-space. For the purposes of regenerating + sequences of atoms and quoted-strings, exactly one SPACE is + assumed to exist, and should be used, between them. (Also, in + the "Clarifications" section on "White Space", below, note the + rules about treatment of multiple contiguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Group. Some-Org, + Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + is analyzed into the following lexical symbols and types: + + :sysmail quoted string + @ special + Some-Group atom + . special + Some-Org atom + , special + Muhammed atom + . special + (I am the greatest) comment + Ali atom + @ atom + (the) comment + Vegas atom + . special + WBA atom + + The canonical representations for the data in these addresses + are the following strings: + + ":sysmail"@Some-Group.Some-Org + + and + + Muhammed.Ali@Vegas.WBA + + Note: For purposes of display, and when passing such struc- + tured information to other systems, such as mail proto- + col services, there must be NO linear-white-space + between <word>s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + <word>s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.2. HEADER FIELD DEFINITIONS + + These rules show a field meta-syntax, without regard for the + particular type or internal syntax. Their purpose is to permit + detection of fields; also, they present to higher-level parsers + an image of each field as fitting on one line. + + field = field-name ":" [ field-body ] CRLF + + field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + <the ASCII characters making up the field-body, as + defined in the following sections, and consisting + of combinations of atom, quoted-string, and + specials tokens, or else consisting of texts> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.3. LEXICAL TOKENS + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to higher level parsers. See the + ANSI references, in the Bibliography. + + ; ( Octal, Decimal.) + CHAR = <any ASCII character> ; ( 0-177, 0.-127.) + ALPHA = <any ASCII alphabetic character> + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) + CTL = <any ASCII control ; ( 0- 37, 0.- 31.) + character and DEL> ; ( 177, 127.) + CR = <ASCII CR, carriage return> ; ( 15, 13.) + LF = <ASCII LF, linefeed> ; ( 12, 10.) + SPACE = <ASCII SP, space> ; ( 40, 32.) + HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) + <"> = <ASCII quote mark> ; ( 42, 34.) + CRLF = CR LF + + LWSP-char = SPACE / HTAB ; semantics = SPACE + + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + + delimiters = specials / linear-white-space / comment + + text = <any CHAR, including bare ; => atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1*<any CHAR except specials, SPACE and CTLs> + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = <any CHAR excepting <">, ; => may be folded + "\" & CR, and including + linear-white-space> + + domain-literal = "[" *(dtext / quoted-pair) "]" + + + + + August 13, 1982 - 10 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + dtext = <any CHAR excluding "[", ; => may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = <any CHAR excluding "(", ; => may be folded + ")", "\" & CR, & including + linear-white-space> + + quoted-pair = "\" CHAR ; may quote any char + + phrase = 1*word ; Sequence of words + + word = atom / quoted-string + + + 3.4. CLARIFICATIONS + + 3.4.1. QUOTING + + Some characters are reserved for special interpretation, such + as delimiting lexical tokens. To permit use of these charac- + ters as uninterpreted data, a quoting mechanism is provided. + To quote a character, precede it with a backslash ("\"). + + This mechanism is not fully general. Characters may be quoted + only within a subset of the lexical constructs. In particu- + lar, quoting is limited to use within: + + - quoted-string + - domain-literal + - comment + + Within these constructs, quoting is REQUIRED for CR and "\" + and for the character(s) that delimit the token (e.g., "(" and + ")" for a comment). However, quoting is PERMITTED for any + character. + + Note: In particular, quoting is NOT permitted within atoms. + For example when the local-part of an addr-spec must + contain a special character, a quoted string must be + used. Therefore, a specification such as: + + Full\ Name@Domain + + is not legal and must be specified as: + + "Full Name"@Domain + + + August 13, 1982 - 11 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.2. WHITE SPACE + + Note: In structured field bodies, multiple linear space ASCII + characters (namely HTABs and SPACEs) are treated as + single spaces and may freely surround any symbol. In + all header fields, the only place in which at least one + LWSP-char is REQUIRED is at the beginning of continua- + tion lines in a folded field. + + When passing text to processes that do not interpret text + according to this standard (e.g., mail protocol servers), then + NO linear-white-space characters should occur between a period + (".") or at-sign ("@") and a <word>. Exactly ONE SPACE should + be used in place of arbitrary linear-white-space and comment + sequences. + + Note: Within systems conforming to this standard, wherever a + member of the list of delimiters is allowed, LWSP-chars + may also occur before and/or after it. + + Writers of mail-sending (i.e., header-generating) programs + should realize that there is no network-wide definition of the + effect of ASCII HT (horizontal-tab) characters on the appear- + ance of text at another network host; therefore, the use of + tabs in message headers, though permitted, is discouraged. + + 3.4.3. COMMENTS + + A comment is a set of ASCII characters, which is enclosed in + matching parentheses and which is not within a quoted-string + The comment construct permits message originators to add text + which will be useful for human readers, but which will be + ignored by the formal semantics. Comments should be retained + while the message is subject to interpretation according to + this standard. However, comments must NOT be included in + other cases, such as during protocol exchanges with mail + servers. + + Comments nest, so that if an unquoted left parenthesis occurs + in a comment string, there must also be a matching right + parenthesis. When a comment acts as the delimiter between a + sequence of two lexical symbols, such as two atoms, it is lex- + ically equivalent with a single SPACE, for the purposes of + regenerating the sequence, such as when passing the sequence + onto a mail protocol server. Comments are detected as such + only within field-bodies of structured fields. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See the "Lexical + + + August 13, 1982 - 12 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Analysis of Messages" section on "Folding Long Header Fields" + above, and the section on "Case Independence" below.) Note + that the official semantics therefore do not "see" any + unquoted CRLFs that are in comments, although particular pars- + ing programs may wish to note their presence. For these pro- + grams, it would be reasonable to interpret a "CRLF LWSP-char" + as being a CRLF that is part of the comment; i.e., the CRLF is + kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) still must be + followed by at least one LWSP-char. + + 3.4.4. DELIMITING AND QUOTING CHARACTERS + + The quote character (backslash) and characters that delimit + syntactic units are not, generally, to be taken as data that + are part of the delimited or quoted unit(s). In particular, + the quotation-marks that define a quoted-string, the + parentheses that define a comment and the backslash that + quotes a following character are NOT part of the quoted- + string, comment or quoted character. A quotation-mark that is + to be part of a quoted-string, a parenthesis that is to be + part of a comment and a backslash that is to be part of either + must each be preceded by the quote-character backslash ("\"). + Note that the syntax allows any character to be quoted within + a quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + the ones that are not part of the alternate text group (i.e., + ctext or qtext). + + The one exception to this rule is that a single SPACE is + assumed to exist between contiguous words in a phrase, and + this interpretation is independent of the actual number of + LWSP-chars that the creator places between the words. To + include more than one SPACE, the creator must make the LWSP- + chars be part of a quoted-string. + + Quotation marks that delimit a quoted string and backslashes + that quote the following character should NOT accompany the + quoted-string when the string is passed to processes that do + not interpret data according to this specification (e.g., mail + protocol servers). + + 3.4.5. QUOTED-STRINGS + + Where permitted (i.e., in words in structured fields) quoted- + strings are treated as a single symbol. That is, a quoted- + string is equivalent to an atom, syntactically. If a quoted- + string is to be "folded" onto multiple lines, then the syntax + for folding must be adhered to. (See the "Lexical Analysis of + + + August 13, 1982 - 13 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Messages" section on "Folding Long Header Fields" above, and + the section on "Case Independence" below.) Therefore, the + official semantics do not "see" any bare CRLFs that are in + quoted-strings; however particular parsing programs may wish + to note their presence. For such programs, it would be rea- + sonable to interpret a "CRLF LWSP-char" as being a CRLF which + is part of the quoted-string; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- + lowed by a CR followed by a LF) are also subject to rules of + folding, but the presence of the quoting character (backslash) + explicitly indicates that the CRLF is data to the quoted + string. Stripping off the first following LWSP-char is also + appropriate when parsing quoted CRLFs. + + 3.4.6. BRACKETING CHARACTERS + + There is one type of bracket which must occur in matched pairs + and may have pairs nested within each other: + + o Parentheses ("(" and ")") are used to indicate com- + ments. + + There are three types of brackets which must occur in matched + pairs, and which may NOT be nested: + + o Colon/semi-colon (":" and ";") are used in address + specifications to indicate that the included list of + addresses are to be treated as a group. + + o Angle brackets ("<" and ">") are generally used to + indicate the presence of a one machine-usable refer- + ence (e.g., delimiting mailboxes), possibly including + source-routing to the machine. + + o Square brackets ("[" and "]") are used to indicate the + presence of a domain-literal, which the appropriate + name-domain is to use directly, bypassing normal + name-resolution mechanisms. + + 3.4.7. CASE INDEPENDENCE + + Except as noted, alphabetic strings may be represented in any + combination of upper and lower case. The only syntactic units + + + + + + + + + August 13, 1982 - 14 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + which requires preservation of case information are: + + - text + - qtext + - dtext + - ctext + - quoted-pair + - local-part, except "Postmaster" + + When matching any other syntactic unit, case is to be ignored. + For example, the field-names "From", "FROM", "from", and even + "FroM" are semantically equal and should all be treated ident- + ically. + + When generating these units, any mix of upper and lower case + alphabetic characters may be used. The case shown in this + specification is suggested for message-creating processes. + + Note: The reserved local-part address unit, "Postmaster", is + an exception. When the value "Postmaster" is being + interpreted, it must be accepted in any mixture of + case, including "POSTMASTER", and "postmaster". + + 3.4.8. FOLDING LONG HEADER FIELDS + + Each header field may be represented on exactly one line con- + sisting of the name of the field and its body, and terminated + by a CRLF; this is what the parser sees. For readability, the + field-body portion of long header fields may be "folded" onto + multiple lines of the actual field. "Long" is commonly inter- + preted to mean greater than 65 or 72 characters. The former + length serves as a limit, when the message is to be viewed on + most simple terminals which use simple display software; how- + ever, the limit is not imposed by this standard. + + Note: Some display software often can selectively fold lines, + to suit the display terminal. In such cases, sender- + provided folding can interfere with the display + software. + + 3.4.9. BACKSPACE CHARACTERS + + ASCII BS characters (Backspace, decimal 8) may be included in + texts and quoted-strings to effect overstriking. However, any + use of backspaces which effects an overstrike to the left of + the beginning of the text or quoted-string is prohibited. + + + + + + August 13, 1982 - 15 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS + + During transmission through heterogeneous networks, it may be + necessary to force data to conform to a network's local con- + ventions. For example, it may be required that a CR be fol- + lowed either by LF, making a CRLF, or by <null>, if the CR is + to stand alone). Such transformations are reversed, when the + message exits that network. + + When crossing network boundaries, the message should be + treated as passing through two modules. It will enter the + first module containing whatever network-specific transforma- + tions that were necessary to permit migration through the + "current" network. It then passes through the modules: + + o Transformation Reversal + + The "current" network's idiosyncracies are removed and + the message is returned to the canonical form speci- + fied in this standard. + + o Transformation + + The "next" network's local idiosyncracies are imposed + on the message. + + ------------------ + From ==> | Remove Net-A | + Net-A | idiosyncracies | + ------------------ + || + \/ + Conformance + with standard + || + \/ + ------------------ + | Impose Net-B | ==> To + | idiosyncracies | Net-B + ------------------ + + + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 4. MESSAGE SPECIFICATION + + 4.1. SYNTAX + + Note: Due to an artifact of the notational conventions, the syn- + tax indicates that, when present, some fields, must be in + a particular order. Header fields are NOT required to + occur in any particular order, except that the message + body must occur AFTER the headers. It is recommended + that, if present, headers be sent in the order "Return- + Path", "Received", "Date", "From", "Subject", "Sender", + "To", "cc", etc. + + This specification permits multiple occurrences of most + fields. Except as noted, their interpretation is not + specified here, and their use is discouraged. + + The following syntax for the bodies of various fields should + be thought of as describing each field body as a single long + string (or line). The "Lexical Analysis of Message" section on + "Long Header Fields", above, indicates how such long strings can + be represented on more than one line in the actual transmitted + message. + + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + + trace = return ; path to sender + 1*received ; receipt tags + + return = "Return-path" ":" route-addr ; return address + + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + + + August 13, 1982 - 17 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + ";" date-time ; time received + + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + + dates = orig-date ; Original + [ resent-date ] ; Forwarded + + orig-date = "Date" ":" date-time + + resent-date = "Resent-Date" ":" date-time + + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + + msg-id = "<" addr-spec ">" ; Unique message id + + + + + + + August 13, 1982 - 18 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + extension-field = + <Any field which is defined in a document + published as a formal extension to this + specification; none will have names beginning + with the string "X-"> + + user-defined-field = + <Any field which has not been defined + in this specification or published as an + extension to this specification; names for + such fields must be unique and may be + pre-empted by published extensions> + + 4.2. FORWARDING + + Some systems permit mail recipients to forward a message, + retaining the original headers, by adding some new fields. This + standard supports such a service, through the "Resent-" prefix to + field names. + + Whenever the string "Resent-" begins a field name, the field + has the same semantics as a field whose name does not have the + prefix. However, the message is assumed to have been forwarded + by an original recipient who attached the "Resent-" field. This + new field is treated as being more recent than the equivalent, + original field. For example, the "Resent-From", indicates the + person that forwarded the message, whereas the "From" field indi- + cates the original author. + + Use of such precedence information depends upon partici- + pants' communication needs. For example, this standard does not + dictate when a "Resent-From:" address should receive replies, in + lieu of sending them to the "From:" address. + + Note: In general, the "Resent-" fields should be treated as con- + taining a set of information that is independent of the + set of original fields. Information for one set should + not automatically be taken from the other. The interpre- + tation of multiple "Resent-" fields, of the same type, is + undefined. + + In the remainder of this specification, occurrence of legal + "Resent-" fields are treated identically with the occurrence of + + + + + + + + + August 13, 1982 - 19 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + fields whose names do not contain this prefix. + + 4.3. TRACE FIELDS + + Trace information is used to provide an audit trail of mes- + sage handling. In addition, it indicates a route back to the + sender of the message. + + The list of known "via" and "with" values are registered + with the Network Information Center, SRI International, Menlo + Park, California. + + 4.3.1. RETURN-PATH + + This field is added by the final transport system that + delivers the message to its recipient. The field is intended + to contain definitive information about the address and route + back to the message's originator. + + Note: The "Reply-To" field is added by the originator and + serves to direct replies, whereas the "Return-Path" + field is used to identify a path back to the origina- + tor. + + While the syntax indicates that a route specification is + optional, every attempt should be made to provide that infor- + mation in this field. + + 4.3.2. RECEIVED + + A copy of this field is added by each transport service that + relays the message. The information in the field can be quite + useful for tracing transport problems. + + The names of the sending and receiving hosts and time-of- + receipt may be specified. The "via" parameter may be used, to + indicate what physical mechanism the message was sent over, + such as Arpanet or Phonenet, and the "with" parameter may be + used to indicate the mail-, or connection-, level protocol + that was used, such as the SMTP mail protocol, or X.25 tran- + sport protocol. + + Note: Several "with" parameters may be included, to fully + specify the set of protocols that were used. + + Some transport services queue mail; the internal message iden- + tifier that is assigned to the message may be noted, using the + "id" parameter. When the sending host uses a destination + address specification that the receiving host reinterprets, by + + + August 13, 1982 - 20 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + expansion or transformation, the receiving host may wish to + record the original specification, using the "for" parameter. + For example, when a copy of mail is sent to the member of a + distribution list, this parameter may be used to record the + original address that was used to specify the list. + + 4.4. ORIGINATOR FIELDS + + The standard allows only a subset of the combinations possi- + ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, + and Resent-Reply-To fields. The limitation is intentional. + + 4.4.1. FROM / RESENT-FROM + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single, authenticated machine + address, indicating the AGENT (person, system or process) + entering the message. If this is not done, the "Sender" field + MUST be present. If the "From" field IS defaulted this way, + the "Sender" field is optional and is redundant with the + "From" field. In all cases, addresses in the "From" field + must be machine-usable (addr-specs) and may not contain named + lists (groups). + + 4.4.2. SENDER / RESENT-SENDER + + This field contains the authenticated identity of the AGENT + (person, system or process) that sends the message. It is + intended for use when the sender is not the author of the mes- + sage, or to indicate who among a group of authors actually + sent the message. If the contents of the "Sender" field would + be completely redundant with the "From" field, then the + "Sender" field need not be present and its use is discouraged + (though still legal). In particular, the "Sender" field MUST + be present if it is NOT the same as the "From" Field. + + The Sender mailbox specification includes a word sequence + which must correspond to a specific agent (i.e., a human user + or a computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person, system, or process) responsible for + sending the mail and not simply include the name of a mailbox + from which the mail was sent. For example in the case of a + shared login name, the name, by itself, would not be adequate. + The local-part address unit, which refers to this agent, is + expected to be a computer system term, and not (for example) a + generalized person reference which can be used outside the + network text message context. + + + August 13, 1982 - 21 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Since the critical function served by the "Sender" field is + identification of the agent responsible for sending mail and + since computer programs cannot be held accountable for their + behavior, it is strongly recommended that when a computer pro- + gram generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field mail- + box specification. + + 4.4.3. REPLY-TO / RESENT-REPLY-TO + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based mail- + boxes and therefore wish(es) to indicate an alternate machine + address. In the second case, an author may wish additional + persons to be made aware of, or responsible for, replies. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the "Reply- + To" field of all messages submitted to the teleconference; + then participants can "reply" to conference submissions to + guarantee the correct distribution of any submission of their + own. + + Note: The "Return-Path" field is added by the mail transport + service, at the time of final deliver. It is intended + to identify a path back to the orginator of the mes- + sage. The "Reply-To" field is added by the message + originator and is intended to direct replies. + + 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO + + For systems which automatically generate address lists for + replies to messages, the following recommendations are made: + + o The "Sender" field mailbox should be sent notices of + any problems in transport or delivery of the original + messages. If there is no "Sender" field, then the + "From" field mailbox should be used. + + o The "Sender" field mailbox should NEVER be used + automatically, in a recipient's reply message. + + o If the "Reply-To" field exists, then the reply should + go to the addresses indicated in that field and not to + the address(es) indicated in the "From" field. + + + + + August 13, 1982 - 22 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + o If there is a "From" field, but no "Reply-To" field, + the reply should be sent to the address(es) indicated + in the "From" field. + + Sometimes, a recipient may actually wish to communicate with + the person that initiated the message transfer. In such + cases, it is reasonable to use the "Sender" address. + + This recommendation is intended only for automated use of + originator-fields and is not intended to suggest that replies + may not also be sent to other recipients of messages. It is + up to the respective mail-handling programs to decide what + additional facilities will be provided. + + Examples are provided in Appendix A. + + 4.5. RECEIVER FIELDS + + 4.5.1. TO / RESENT-TO + + This field contains the identity of the primary recipients of + the message. + + 4.5.2. CC / RESENT-CC + + This field contains the identity of the secondary (informa- + tional) recipients of the message. + + 4.5.3. BCC / RESENT-BCC + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary reci- + pients. Some systems may choose to include the text of the + "Bcc" field only in the author(s)'s copy, while others may + also include it in the text sent to all those indicated in the + "Bcc" list. + + 4.6. REFERENCE FIELDS + + 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID + + This field contains a unique identifier (the local-part + address unit) which refers to THIS version of THIS message. + The uniqueness of the message identifier is guaranteed by the + host which generates it. This identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one instantiation of a + particular message; subsequent revisions to the message should + + + August 13, 1982 - 23 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + each receive new message identifiers. + + 4.6.2. IN-REPLY-TO + + The contents of this field identify previous correspon- + dence which this message answers. Note that if message iden- + tifiers are used in this field, they must use the msg-id + specification format. + + 4.6.3. REFERENCES + + The contents of this field identify other correspondence + which this message references. Note that if message identif- + iers are used, they must use the msg-id specification format. + + 4.6.4. KEYWORDS + + This field contains keywords or phrases, separated by + commas. + + 4.7. OTHER FIELDS + + 4.7.1. SUBJECT + + This is intended to provide a summary, or indicate the + nature, of the message. + + 4.7.2. COMMENTS + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + 4.7.3. ENCRYPTED + + Sometimes, data encryption is used to increase the + privacy of message contents. If the body of a message has + been encrypted, to keep its contents private, the "Encrypted" + field can be used to note the fact and to indicate the nature + of the encryption. The first <word> parameter indicates the + software used to encrypt the body, and the second, optional + <word> is intended to aid the recipient in selecting the + proper decryption key. This code word may be viewed as an + index to a table of keys held by the recipient. + + Note: Unfortunately, headers must contain envelope, as well + as contents, information. Consequently, it is neces- + sary that they remain unencrypted, so that mail tran- + sport services may access them. Since names, + addresses, and "Subject" field contents may contain + + + August 13, 1982 - 24 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + sensitive information, this requirement limits total + message privacy. + + Names of encryption software are registered with the Net- + work Information Center, SRI International, Menlo Park, Cali- + fornia. + + 4.7.4. EXTENSION-FIELD + + A limited number of common fields have been defined in + this document. As network mail requirements dictate, addi- + tional fields may be standardized. To provide user-defined + fields with a measure of safety, in name selection, such + extension-fields will never have names that begin with the + string "X-". + + Names of Extension-fields are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 4.7.5. USER-DEFINED-FIELD + + Individual users of network mail are free to define and + use additional header fields. Such fields must have names + which are not already used in the current specification or in + any definitions of extension-fields, and the overall syntax of + these user-defined-fields must conform to this specification's + rules for delimiting and folding fields. Due to the + extension-field publishing process, the name of a user- + defined-field may be pre-empted + + Note: The prefatory string "X-" will never be used in the + names of Extension-fields. This provides user-defined + fields with a protected set of names. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 25 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 5. DATE AND TIME SPECIFICATION + + 5.1. SYNTAX + + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + + time = hour zone ; ANSI and Military + + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours+min. (HHMM) + + 5.2. SEMANTICS + + If included, day-of-week must be the day implied by the date + specification. + + Time zone may be indicated in several ways. "UT" is Univer- + sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- + mitted as a reference to Universal Time. The military standard + uses a single character for each zone. "Z" is Universal Time. + "A" indicates one hour earlier, and "M" indicates 12 hours ear- + lier; "N" is one hour later, and "Y" is 12 hours later. The + letter "J" is not used. The other remaining two forms are taken + from ANSI standard X3.51-1975. One allows explicit indication of + the amount of offset from UT; the other uses common 3-character + strings for indicating time zones in North America. + + + August 13, 1982 - 26 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 6. ADDRESS SPECIFICATION + + 6.1. SYNTAX + + address = mailbox ; one addressee + / group ; named list + + group = phrase ":" [#mailbox] ";" + + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + + route-addr = "<" [route] addr-spec ">" + + route = 1#("@" domain) ":" ; path-relative + + addr-spec = local-part "@" domain ; global address + + local-part = word *("." word) ; uninterpreted + ; case-preserved + + domain = sub-domain *("." sub-domain) + + sub-domain = domain-ref / domain-literal + + domain-ref = atom ; symbolic reference + + 6.2. SEMANTICS + + A mailbox receives mail. It is a conceptual entity which + does not necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + A mailbox specification comprises a person, system or pro- + cess name reference, a domain-dependent string, and a name-domain + reference. The name reference is optional and is usually used to + indicate the human name of a recipient. The name-domain refer- + ence specifies a sequence of sub-domains. The domain-dependent + string is uninterpreted, except by the final sub-domain; the rest + of the mail service merely transmits it as a literal string. + + 6.2.1. DOMAINS + + A name-domain is a set of registered (mail) names. A name- + domain specification resolves to a subordinate name-domain + specification or to a terminal domain-dependent string. + Hence, domain specification is extensible, permitting any + number of registration levels. + + + August 13, 1982 - 27 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Name-domains model a global, logical, hierarchical addressing + scheme. The model is logical, in that an address specifica- + tion is related to name registration and is not necessarily + tied to transmission path. The model's hierarchy is a + directed graph, called an in-tree, such that there is a single + path from the root of the tree to any node in the hierarchy. + If more than one path actually exists, they are considered to + be different addresses. + + The root node is common to all addresses; consequently, it is + not referenced. Its children constitute "top-level" name- + domains. Usually, a service has access to its own full domain + specification and to the names of all top-level name-domains. + + The "top" of the domain addressing hierarchy -- a child of the + root -- is indicated by the right-most field, in a domain + specification. Its child is specified to the left, its child + to the left, and so on. + + Some groups provide formal registration services; these con- + stitute name-domains that are independent logically of + specific machines. In addition, networks and machines impli- + citly compose name-domains, since their membership usually is + registered in name tables. + + In the case of formal registration, an organization implements + a (distributed) data base which provides an address-to-route + mapping service for addresses of the form: + + person@registry.organization + + Note that "organization" is a logical entity, separate from + any particular communication network. + + A mechanism for accessing "organization" is universally avail- + able. That mechanism, in turn, seeks an instantiation of the + registry; its location is not indicated in the address specif- + ication. It is assumed that the system which operates under + the name "organization" knows how to find a subordinate regis- + try. The registry will then use the "person" string to deter- + mine where to send the mail specification. + + The latter, network-oriented case permits simple, direct, + attachment-related address specification, such as: + + user@host.network + + Once the network is accessed, it is expected that a message + will go directly to the host and that the host will resolve + + + August 13, 1982 - 28 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + the user name, placing the message in the user's mailbox. + + 6.2.2. ABBREVIATED DOMAIN SPECIFICATION + + Since any number of levels is possible within the domain + hierarchy, specification of a fully qualified address can + become inconvenient. This standard permits abbreviated domain + specification, in a special case: + + For the address of the sender, call the left-most + sub-domain Level N. In a header address, if all of + the sub-domains above (i.e., to the right of) Level N + are the same as those of the sender, then they do not + have to appear in the specification. Otherwise, the + address must be fully qualified. + + This feature is subject to approval by local sub- + domains. Individual sub-domains may require their + member systems, which originate mail, to provide full + domain specification only. When permitted, abbrevia- + tions may be present only while the message stays + within the sub-domain of the sender. + + Use of this mechanism requires the sender's sub-domain + to reserve the names of all top-level domains, so that + full specifications can be distinguished from abbrevi- + ated specifications. + + For example, if a sender's address is: + + sender@registry-A.registry-1.organization-X + + and one recipient's address is: + + recipient@registry-B.registry-1.organization-X + + and another's is: + + recipient@registry-C.registry-2.organization-X + + then ".registry-1.organization-X" need not be specified in the + the message, but "registry-C.registry-2" DOES have to be + specified. That is, the first two addresses may be abbrevi- + ated, but the third address must be fully specified. + + When a message crosses a domain boundary, all addresses must + be specified in the full format, ending with the top-level + name-domain in the right-most field. It is the responsibility + of mail forwarding services to ensure that addresses conform + + + August 13, 1982 - 29 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + with this requirement. In the case of abbreviated addresses, + the relaying service must make the necessary expansions. It + should be noted that it often is difficult for such a service + to locate all occurrences of address abbreviations. For exam- + ple, it will not be possible to find such abbreviations within + the body of the message. The "Return-Path" field can aid + recipients in recovering from these errors. + + Note: When passing any portion of an addr-spec onto a process + which does not interpret data according to this stan- + dard (e.g., mail protocol servers). There must be NO + LWSP-chars preceding or following the at-sign or any + delimiting period ("."), such as shown in the above + examples, and only ONE SPACE between contiguous + <word>s. + + 6.2.3. DOMAIN TERMS + + A domain-ref must be THE official name of a registry, network, + or host. It is a symbolic reference, within a name sub- + domain. At times, it is necessary to bypass standard mechan- + isms for resolving such references, using more primitive + information, such as a network host address rather than its + associated host name. + + To permit such references, this standard provides the domain- + literal construct. Its contents must conform with the needs + of the sub-domain in which it is interpreted. + + Domain-literals which refer to domains within the ARPA Inter- + net specify 32-bit Internet addresses, in four 8-bit fields + noted in decimal, as described in Request for Comments #820, + "Assigned Numbers." For example: + + [10.0.3.19] + + Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It + is permitted only as a means of bypassing temporary + system limitations, such as name tables which are not + complete. + + The names of "top-level" domains, and the names of domains + under in the ARPA Internet, are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 6.2.4. DOMAIN-DEPENDENT LOCAL STRING + + The local-part of an addr-spec in a mailbox specification + (i.e., the host's name for the mailbox) is understood to be + + + August 13, 1982 - 30 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + whatever the receiving mail protocol server allows. For exam- + ple, some systems do not understand mailbox references of the + form "P. D. Q. Bach", but others do. + + This specification treats periods (".") as lexical separators. + Hence, their presence in local-parts which are not quoted- + strings, is detected. However, such occurrences carry NO + semantics. That is, if a local-part has periods within it, an + address parser will divide the local-part into several tokens, + but the sequence of tokens will be treated as one uninter- + preted unit. The sequence will be re-assembled, when the + address is passed outside of the system such as to a mail pro- + tocol service. + + For example, the address: + + First.Last@Registry.Org + + is legal and does not require the local-part to be surrounded + with quotation-marks. (However, "First Last" DOES require + quoting.) The local-part of the address, when passed outside + of the mail system, within the Registry.Org domain, is + "First.Last", again without quotation marks. + + 6.2.5. BALANCING LOCAL-PART AND DOMAIN + + In some cases, the boundary between local-part and domain can + be flexible. The local-part may be a simple string, which is + used for the final determination of the recipient's mailbox. + All other levels of reference are, therefore, part of the + domain. + + For some systems, in the case of abbreviated reference to the + local and subordinate sub-domains, it may be possible to + specify only one reference within the domain part and place + the other, subordinate name-domain references within the + local-part. This would appear as: + + mailbox.sub1.sub2@this-domain + + Such a specification would be acceptable to address parsers + which conform to RFC #733, but do not support this newer + Internet standard. While contrary to the intent of this stan- + dard, the form is legal. + + Also, some sub-domains have a specification syntax which does + not conform to this standard. For example: + + sub-net.mailbox@sub-domain.domain + + + August 13, 1982 - 31 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + uses a different parsing sequence for local-part than for + domain. + + Note: As a rule, the domain specification should contain + fields which are encoded according to the syntax of + this standard and which contain generally-standardized + information. The local-part specification should con- + tain only that portion of the address which deviates + from the form or intention of the domain field. + + 6.2.6. MULTIPLE MAILBOXES + + An individual may have several mailboxes and wish to receive + mail at whatever mailbox is convenient for the sender to + access. This standard does not provide a means of specifying + "any member of" a list of mailboxes. + + A set of individuals may wish to receive mail as a single unit + (i.e., a distribution list). The <group> construct permits + specification of such a list. Recipient mailboxes are speci- + fied within the bracketed part (":" - ";"). A copy of the + transmitted message is to be sent to each mailbox listed. + This standard does not permit recursive specification of + groups within groups. + + While a list must be named, it is not required that the con- + tents of the list be included. In this case, the <address> + serves only as an indication of group distribution and would + appear in the form: + + name:; + + Some mail services may provide a group-list distribution + facility, accepting a single mailbox reference, expanding it + to the full distribution list, and relaying the mail to the + list's members. This standard provides no additional syntax + for indicating such a service. Using the <group> address + alternative, while listing one mailbox in it, can mean either + that the mailbox reference will be expanded to a list or that + there is a group with one member. + + 6.2.7. EXPLICIT PATH SPECIFICATION + + At times, a message originator may wish to indicate the + transmission path that a message should follow. This is + called source routing. The normal addressing scheme, used in + an addr-spec, is carefully separated from such information; + the <route> portion of a route-addr is provided for such occa- + sions. It specifies the sequence of hosts and/or transmission + + + August 13, 1982 - 32 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + services that are to be traversed. Both domain-refs and + domain-literals may be used. + + Note: The use of source routing is discouraged. Unless the + sender has special need of path restriction, the choice + of transmission route should be left to the mail tran- + sport service. + + 6.3. RESERVED ADDRESS + + It often is necessary to send mail to a site, without know- + ing any of its valid addresses. For example, there may be mail + system dysfunctions, or a user may wish to find out a person's + correct address, at that site. + + This standard specifies a single, reserved mailbox address + (local-part) which is to be valid at each site. Mail sent to + that address is to be routed to a person responsible for the + site's mail system or to a person with responsibility for general + site operation. The name of the reserved local-part address is: + + Postmaster + + so that "Postmaster@domain" is required to be valid. + + Note: This reserved local-part must be matched without sensi- + tivity to alphabetic case, so that "POSTMASTER", "postmas- + ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 7. BIBLIOGRAPHY + + + ANSI. "USA Standard Code for Information Interchange," X3.4. + American National Standards Institute: New York (1968). Also + in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- + book", NIC 7104. + + ANSI. "Representations of Universal Time, Local Time Differen- + tials, and United States Time Zone References for Information + Interchange," X3.51-1975. American National Standards Insti- + tute: New York (1975). + + Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. + 1979). + + Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- + ford and Appleton Laboratory: Didcot, England. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + "Standardizing Network Mail Headers," ARPANET Request for + Comments No. 561, Network Information Center No. 18516; SRI + International: Menlo Park (September 1973). + + Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. + "Grapevine: An Exercise in Distributed Computing," Communica- + tions of the ACM 25, 4 (April 1982), 260-274. + + Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. + "Standard for the Format of ARPA Network Text Message," + ARPANET Request for Comments No. 733, Network Information + Center No. 41952. SRI International: Menlo Park (November + 1977). + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- + work Information Center No. 7104 (NTIS AD A003890). SRI + International: Menlo Park (April 1976). + + Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. + (1969). + + Levin, R. and Schroeder, M. "Transport of Electronic Messages + through a Network," TeleInformatics 79, pp. 29-33. North + Holland (1979). Also as Xerox Palo Alto Research Center + Technical Report CSL-79-4. + + Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116. SRI International: Menlo Park (1975). + + + August 13, 1982 - 34 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + NBS. "Specification of Message Format for Computer Based Message + Systems, Recommended Federal Information Processing Standard." + National Bureau of Standards: Gaithersburg, Maryland + (October 1981). + + NIC. Internet Protocol Transition Workbook. Network Information + Center, SRI-International, Menlo Park, California (March + 1982). + + Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized + Agent for Locating Named Objects in a Distributed Environ- + ment," OPD-T8103. Xerox Office Products Division: Palo Alto, + CA. (October 1981). + + Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, + No. 820. SRI International: Menlo Park (August 1982). + + Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request + for Comments, No. 821. SRI International: Menlo Park (August + 1982). + + Shoch, J.F. "Internetwork naming, addressing and routing," in + Proc. 17th IEEE Computer Society International Conference, pp. + 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. + + Su, Z. and Postel, J. "The Domain Naming Convention for Internet + User Applications," ARPANET Request for Comments, No. 819. + SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + APPENDIX + + + A. EXAMPLES + + A.1. ADDRESSES + + A.1.1. Alfred Neuman <Neuman@BBN-TENEXA> + + A.1.2. Neuman@BBN-TENEXA + + These two "Alfred Neuman" examples have identical seman- + tics, as far as the operation of the local host's mail sending + (distribution) program (also sometimes called its "mailer") + and the remote host's mail protocol server are concerned. In + the first example, the "Alfred Neuman" is ignored by the + mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- + pient. The second example contains no superfluous informa- + tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- + pient. + + Note: When the message crosses name-domain boundaries, then + these specifications must be changed, so as to indicate + the remainder of the hierarchy, starting with the top + level. + + A.1.3. "George, Ted" <Shared@Group.Arpanet> + + This form might be used to indicate that a single mailbox + is shared by several users. The quoted string is ignored by + the originating host's mailer, because "Shared@Group.Arpanet" + completely specifies the destination mailbox. + + A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US + + The "(the Stilt)" is a comment, which is NOT included in + the destination mailbox address handed to the originating + system's mailer. The local-part of the address is the string + "Wilt.Chamberlain", with NO space between the first and second + words. + + A.1.5. Address Lists + + Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>, + Childs@WGBH.Boston, Galloping Gourmet@ + ANT.Down-Under (Australian National Television), + Cheapie@Discount-Liquors;, + Cruisers: Port@Portugal, Jones@SEA;, + Another@Somewhere.SomeOrg + + + August 13, 1982 - 36 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + This group list example points out the use of comments and the + mixing of addresses and groups. + + A.2. ORIGINATOR ITEMS + + A.2.1. Author-sent + + George Jones logs into his host as "Jones". He sends + mail himself. + + From: Jones@Group.Org + + or + + From: George Jones <Jones@Group.Org> + + A.2.2. Secretary-sent + + George Jones logs in as Jones on his host. His secre- + tary, who logs in as Secy sends mail for him. Replies to the + mail should go to George. + + From: George Jones <Jones@Group> + Sender: Secy@Other-Group + + A.2.3. Secretary-sent, for user of shared directory + + George Jones' secretary sends mail for George. Replies + should go to George. + + From: George Jones<Shared@Group.Org> + Sender: Secy@Other-Group + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples. + + A.2.4. Committee activity, with one author + + George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones <Jones@Host.Net> + Sender: Jones@Host + Reply-To: The Committee: Jones@Host.Net, + Smith@Other.Org, + Doe@Somewhere-Else; + + Note that if George had not included himself in the + + + August 13, 1982 - 37 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + enumeration of The Committee, he would not have gotten an + implicit reply; the presence of the "Reply-to" field SUPER- + SEDES the sending of a reply to the person named in the "From" + field. + + A.2.5. Secretary acting as full agent of author + + George Jones asks his secretary (Secy@Host) to send a + message for him in his capacity as Group. He wants his secre- + tary to handle all replies. + + From: George Jones <Group@Host> + Sender: Secy@Host + Reply-To: Secy@Host + + A.2.6. Agent for user without online mailbox + + A friend of George's, Sarah, is visiting. George's + secretary sends some mail to a friend of Sarah in computer- + land. Replies should go to George, whose mailbox is Jones at + Registry. + + From: Sarah Friendly <Secy@Registry> + Sender: Secy-Name <Secy@Registry> + Reply-To: Jones@Registry. + + A.2.7. Agent for member of a committee + + George's secretary sends out a message which was authored + jointly by all the members of a committee. Note that the name + of the committee cannot be specified, since <group> names are + not permitted in the From field. + + From: Jones@Host, + Smith@Other-Host, + Doe@Somewhere-Else + Sender: Secy@SHost + + + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + A.3. COMPLETE HEADERS + + A.3.1. Minimum required + + Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT + From: Jones@Registry.Org or From: Jones@Registry.Org + Bcc: To: Smith@Registry.Org + + Note that the "Bcc" field may be empty, while the "To" field + is required to have at least one address. + + A.3.2. Using some of the additional fields + + Date: 26 Aug 76 1430 EDT + From: George Jones<Group@Host> + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: <some.string@SHOST> + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis <KDavis@This-Host.This-net> + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones <Group@Some-Reg.An-Org>, + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood <Balsa@Tree.Root>, + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "<Jones>standard.dist.3"@Tops-20-Host>; + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: <some.string@DBM.Group>, George's message + X-Special-action: This is a sample of user-defined field- + names. There could also be a field-name + "Special-action", but its name might later be + preempted + Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + + + August 13, 1982 - 39 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + B. SIMPLE FIELD PARSING + + Some mail-reading software systems may wish to perform only + minimal processing, ignoring the internal syntax of structured + field-bodies and treating them the same as unstructured-field- + bodies. Such software will need only to distinguish: + + o Header fields from the message body, + + o Beginnings of fields from lines which continue fields, + + o Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will + suffice for this purpose. It describes a limited view of mes- + sages and is a subset of the syntactic rules provided in the main + part of this specification. One small exception is that the con- + tents of field-bodies consist only of text: + + B.1. SYNTAX + + + message = *field *(CRLF *text) + + field = field-name ":" [field-body] CRLF + + field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> + + field-body = *text [CRLF LWSP-char field-body] + + + B.2. SEMANTICS + + Headers occur before the message body and are terminated by + a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or + HTAB character, while a line beginning a field starts with a + printable character which is not a colon. + + A field-name consists of one or more printable characters + (excluding colon, space, and control-characters). A field-name + MUST be contained on one line. Upper and lower case are not dis- + tinguished when comparing field-names. + + + + + + + + August 13, 1982 - 40 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C. DIFFERENCES FROM RFC #733 + + The following summarizes the differences between this stan- + dard and the one specified in Arpanet Request for Comments #733, + "Standard for the Format of ARPA Network Text Messages". The + differences are listed in the order of their occurrence in the + current specification. + + C.1. FIELD DEFINITIONS + + C.1.1. FIELD NAMES + + These now must be a sequence of printable characters. They + may not contain any LWSP-chars. + + C.2. LEXICAL TOKENS + + C.2.1. SPECIALS + + The characters period ("."), left-square bracket ("["), and + right-square bracket ("]") have been added. For presentation + purposes, and when passing a specification to a system that + does not conform to this standard, periods are to be contigu- + ous with their surrounding lexical tokens. No linear-white- + space is permitted between them. The presence of one LWSP- + char between other tokens is still directed. + + C.2.2. ATOM + + Atoms may not contain SPACE. + + C.2.3. SPECIAL TEXT + + ctext and qtext have had backslash ("\") added to the list of + prohibited characters. + + C.2.4. DOMAINS + + The lexical tokens <domain-literal> and <dtext> have been + added. + + C.3. MESSAGE SPECIFICATION + + C.3.1. TRACE + + The "Return-path:" and "Received:" fields have been specified. + + + + + + August 13, 1982 - 41 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.3.2. FROM + + The "From" field must contain machine-usable addresses (addr- + spec). Multiple addresses may be specified, but named-lists + (groups) may not. + + C.3.3. RESENT + + The meta-construct of prefacing field names with the string + "Resent-" has been added, to indicate that a message has been + forwarded by an intermediate recipient. + + C.3.4. DESTINATION + + A message must contain at least one destination address field. + "To" and "CC" are required to contain at least one address. + + C.3.5. IN-REPLY-TO + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.6. REFERENCE + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.7. ENCRYPTED + + A field has been specified that permits senders to indicate + that the body of a message has been encrypted. + + C.3.8. EXTENSION-FIELD + + Extension fields are prohibited from beginning with the char- + acters "X-". + + C.4. DATE AND TIME SPECIFICATION + + C.4.1. SIMPLIFICATION + + Fewer optional forms are permitted and the list of three- + letter time zones has been shortened. + + C.5. ADDRESS SPECIFICATION + + + + + + + August 13, 1982 - 42 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.5.1. ADDRESS + + The use of quoted-string, and the ":"-atom-":" construct, have + been removed. An address now is either a single mailbox + reference or is a named list of addresses. The latter indi- + cates a group distribution. + + C.5.2. GROUPS + + Group lists are now required to to have a name. Group lists + may not be nested. + + C.5.3. MAILBOX + + A mailbox specification may indicate a person's name, as + before. Such a named list no longer may specify multiple + mailboxes and may not be nested. + + C.5.4. ROUTE ADDRESSING + + Addresses now are taken to be absolute, global specifications, + independent of transmission paths. The <route> construct has + been provided, to permit explicit specification of transmis- + sion path. RFC #733's use of multiple at-signs ("@") was + intended as a general syntax for indicating routing and/or + hierarchical addressing. The current standard separates these + specifications and only one at-sign is permitted. + + C.5.5. AT-SIGN + + The string " at " no longer is used as an address delimiter. + Only at-sign ("@") serves the function. + + C.5.6. DOMAINS + + Hierarchical, logical name-domains have been added. + + C.6. RESERVED ADDRESS + + The local-part "Postmaster" has been reserved, so that users can + be guaranteed at least one valid address at a site. + + + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + D. ALPHABETICAL LISTING OF SYNTAX RULES + + address = mailbox ; one addressee + / group ; named list + addr-spec = local-part "@" domain ; global address + ALPHA = <any ASCII alphabetic character> + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1*<any CHAR except specials, SPACE and CTLs> + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = <any ASCII character> ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = <ASCII CR, carriage return> ; ( 15, 13.) + CRLF = CR LF + ctext = <any CHAR excluding "(", ; => may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = <any ASCII control ; ( 0- 37, 0.- 31.) + character and DEL> ; ( 177, 127.) + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + dates = orig-date ; Original + [ resent-date ] ; Forwarded + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + delimiters = specials / linear-white-space / comment + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = <any CHAR excluding "[", ; => may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + <Any field which is defined in a document + published as a formal extension to this + specification; none will have names beginning + with the string "X-"> + + + August 13, 1982 - 44 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + field = field-name ":" [ field-body ] CRLF + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + field-body = field-body-contents + [CRLF LWSP-char field-body] + field-body-contents = + <the ASCII characters making up the field-body, as + defined in the following sections, and consisting + of combinations of atom, quoted-string, and + specials tokens, or else consisting of texts> + field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) + LF = <ASCII LF, linefeed> ; ( 12, 10.) + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + local-part = word *("." word) ; uninterpreted + ; case-preserved + LWSP-char = SPACE / HTAB ; semantics = SPACE + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + msg-id = "<" addr-spec ">" ; Unique message id + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + orig-date = "Date" ":" date-time + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + phrase = 1*word ; Sequence of words + + + + + August 13, 1982 - 45 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + qtext = <any CHAR excepting <">, ; => may be folded + "\" & CR, and including + linear-white-space> + quoted-pair = "\" CHAR ; may quote any char + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + ";" date-time ; time received + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + resent-date = "Resent-Date" ":" date-time + return = "Return-path" ":" route-addr ; return address + route = 1#("@" domain) ":" ; path-relative + route-addr = "<" [route] addr-spec ">" + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + SPACE = <ASCII SP, space> ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = <any CHAR, including bare ; => atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + time = hour zone ; ANSI and Military + trace = return ; path to sender + 1*received ; receipt tags + user-defined-field = + <Any field which has not been defined + in this specification or published as an + extension to this specification; names for + such fields must be unique and may be + pre-empted by published extensions> + word = atom / quoted-string + + + + + August 13, 1982 - 46 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + <"> = <ASCII quote mark> ; ( 42, 34.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + diff --git a/RFC/rfc937.txt b/RFC/rfc937.txt new file mode 100644 index 00000000..ae154ea8 --- /dev/null +++ b/RFC/rfc937.txt @@ -0,0 +1,1392 @@ + + +Network Working Group M. Butler +Request for Comments: 937 J. Postel + D. Chase + J. Goldberger + J. K. Reynolds +Obsoletes: RFC 918 ISI + February 1985 + + + POST OFFICE PROTOCOL - VERSION 2 + + +Status of this Memo + + This RFC suggests a simple method for workstations to dynamically + access mail from a mailbox server. This RFC specifies a proposed + protocol for the ARPA-Internet community, and requests discussion and + suggestions for improvement. This memo is a revision of RFC 918. + Distribution of this memo is unlimited. + +Introduction + + The intent of the Post Office Protocol Version 2 (POP2) is to allow a + user's workstation to access mail from a mailbox server. It is + expected that mail will be posted from the workstation to the mailbox + server via the Simple Mail Transfer Protocol (SMTP). For further + information see RFC-821 [1] and RFC-822 [2]. + + This protocol assumes a reliable data stream such as provided by TCP + or any similar protocol. When TCP is used, the POP2 server listens + on port 109 [4]. + +System Model and Philosophy + + While we view the workstation as an Internet host in the sense that + it implements IP, we do not expect the workstation to contain the + user's mailbox. We expect the mailbox to be on a server machine. + + We believe it is important for the mailbox to be on an "always up" + machine and that a workstation may be frequently powered down, or + otherwise unavailable as an SMTP server. + + POP2 is designed for an environment of workstations and servers on a + low-delay, high-throughput, local networks (such as Ethernets). POP2 + may be useful in other environments as well, but if the environment + is substantially different, a different division of labor between the + client and server may be appropriate, and a different protocol + required. + + Suppose the user's real name is John Smith, the user's machine is + called FIDO, and that the mailbox server is called DOG-HOUSE. Then + + + +Butler, et. al. [Page 1] + + + +RFC 937 February 1985 +Post Office Protocol + + + we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA + (not JSmith@FIDO.ARPA). + + That is, the destination of the mail is the mailbox on the server + machine. The POP2 protocol and the workstation are merely a + mechanism for viewing the messages in the mailbox. + + The user is not tied to any particular workstation for accessing his + mail. The workstation does not appear as any part of the mailbox + address. + + This is a very simple protocol. This is not a user interface. We + expect that there is a program in the workstation that is friendly to + the user. This protocol is not "user friendly". One basic rule of + this protocol is "if anything goes wrong close the connection". + Another basic rule is to have few options. + + POP2 does not parse messages in any way. It does not analyze message + headers (Date:, From:, To:, Cc:, or Subject:). POP2 simply transmits + whole messages from a mailbox server to a client workstation. + +The Protocol + + The POP2 protocol is a sequence of commands and replies. The design + draws from many previous protocols of the ARPA-Internet community. + + The server must be listening for a connection. When a connection + is opened the server sends a greeting message and waits for + commands. When commands are received the server acts on them and + responds with replies. + + The client opens a connection, waits for the greeting, then sends + the HELO command with the user name and password arguments to + establish authorization to access mailboxes. The server returns + the number of messages in the default mailbox. + + The client may read the default mailbox associated with the user + name or may select another mailbox by using the FOLD command. The + server returns the number of messages in the mailbox selected. + + The client begins a message reading transaction with a READ + command. The read command may optionally indicate which message + number to read, the default is the current message (incremented + when a message is read and set to one when a new folder is + selected). The server returns the number of characters in the + message. + + + + +Butler, et. al. [Page 2] + + + +RFC 937 February 1985 +Post Office Protocol + + + The client asks for the content of the message to be sent with the + RETR command. The server sends the message data. + + When all the data has been received the client sends an + acknowledgment command. This is one of ACKS, ACKD, and NACK. + + ACKS means "I've received the message successfully and please + keep it in the mailbox". + + ACKD means "I've received the message successfully and please + delete it from the mailbox". + + NACK means "I did not receive the message and please keep it in + the mailbox". + + In the case of ACKS or ACKD the server increments the current + message indicator. In the case of NACK the current message + indicator stays the same. + + In all cases the server returns the number of characters in the + (now) current message. + + The client terminates the session with the QUIT command. The + server returns an ok. + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 3] + + + +RFC 937 February 1985 +Post Office Protocol + + + The Normal Scenario + + Client Server + ------ ------ + Wait for Connection + Open Connection --> + <-- + POP2 Server Ready + Wait for Command + HELO Fred Secret --> + <-- #13 messages for you + Wait for Command + READ 13 --> + <-- =537 characters in that message + Wait for Command + RETR --> + <-- (send the message data) + Wait for Command + ACKS --> + <-- =0 no more messages + Wait for Command + QUIT --> + <-- + OK + Close connection --> <-- Close connection + Wait for Connection (go back to start) + +Conventions + + Arguments + + These arguments have system specific definitions. + + user - A login account name. + + password - The password for the login account. + + mailbox - A mailbox name (also called a mail folder). + + + + + + + + + + + + + + +Butler, et. al. [Page 4] + + + +RFC 937 February 1985 +Post Office Protocol + + + Default Mailboxes + + TOPS-20 + + MAIL.TXT.1 - from login directory + + UNIX + + both + /usr/spool/mail/user + and + /usr/user/Mail/inbox/* + + where "user" is the user value supplied in the HELO command. + + End of Line + + End of Line is Carriage Return (CR) followed by Line Feed (LF). + This sequence is indicated by "CRLF" in this document. This end + of line convention must be used for commands and replies. + + Message Length + + The reply to the READ command or an acknowledgment command (ACKS, + ACKD, NACK) is the length (a character count) of the next message + to be transmitted. This includes all the characters in the data + transmitted. CRLF counts as two characters. A length of zero + means the message does not exist or is empty. A request to + transmit a message of zero length will result in the server + closing the connection. The message is transmitted in the + standard internet format described in RFC-822 [2] and NVT-ASCII. + This may be different from the storage format and may make + computing the message length from the stored message non-trivial. + + Message Numbers + + The reply to the HELO and FOLD commands is a count of the number + of messages in a the selected mailbox. The READ command has a + message number as an optional argument. These numbers are + decimal, start at one, and computed with respect to the current + mailbox. That is, the first message in a mailbox is message + number 1. + + Numbers + + All numbers in this memo and protocol are decimal. + + + + +Butler, et. al. [Page 5] + + + +RFC 937 February 1985 +Post Office Protocol + + + Quoting + + In a few cases, there may be a need to have a special character in + an argument (user, password, or mailbox) that is not allowed by + the syntax. For example, a space in a password. To allow for + this, a quoting convention is defined. Unfortunately, such + quoting conventions "use up" another otherwise uninteresting + character. In this protocol the back slash "\" is used as the + quote character. To include a space in an argument the two + character sequence "back-slash, space" is transmitted. To include + a back-slash in an argument the two character sequence + "back-slash, back-slash" is transmitted. This quoting convention + is used in the command arguments only, it is not used in the mail + data transmitted in response to a RETR command. + + Reply Strings + + The first character is required to be as specified (i.e., + "+", "-", "=", "#"). The optional strings that follow can be + whatever the implementer thinks is appropriate. + +Definitions of Commands and Replies + + Summary of Commands and Replies + + Commands Replies + -------- ------- + HELO user password + OK + FOLD mailbox - Error + READ [n] #xxx + RETR =yyy + ACKS + ACKD + NACK + QUIT + + + + + + + + + + + + + + + +Butler, et. al. [Page 6] + + + +RFC 937 February 1985 +Post Office Protocol + + + Commands + + HELO user password + + The Hello command identifies the user to the server and carries + the password authenticating this user. This information is + used by the server to control access to the mailboxes. The + Hello command is the "HELO" keyword, followed by the user + argument, followed by the password argument, followed by CRLF. + + Possible responses: + + "#nnn" + + where nnn is the number of messages in the default + mailbox," + + "- error report" and Close the connection. + + FOLD mailbox + + The Folder command selects another mailbox or mail folder. The + server must check that the user is permitted read access to + this mailbox. If the mailbox is empty or does not exist, the + number of messages reported is zero. The Folder command is the + "FOLD" keyword, followed by the mailbox argument, followed by + CRLF. + + Possible responses: + + "#nnn" + + where nnn is the number of messages in this mailbox. + + READ [nnn] + + The Read command begins a message reading transaction. If the + Read command is given without an argument the current message + is implied (the current message indicator is incremented by + the ACKS or ACKD commands). If an argument is used with the + Read command it is the message number to be read, and this + command sets the current message indicator to that value. The + server returns the count of characters in the message to be + transmitted. If there is no message to be read, the count of + zero is returned. If the message was previously deleted with + the ACKD command, the count of zero is returned. The Read + command is followed by the RETR command, the READ command, the + FOLD command, or the QUIT command. Do not attempt to RETR a + + +Butler, et. al. [Page 7] + + + +RFC 937 February 1985 +Post Office Protocol + + + message of zero characters. The Read command is the "READ" + keyword, optionally followed by the message number argument, + followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in this message. + + RETR + + The Retrieve command confirms that the client is ready to + receive the mail data. It must be followed by an + acknowledgment command. The server will close the connection + if asked to transmit a message of zero characters (i.e., + transmit a non-existent message). The message is transmitted + according to the Internet mail format standard RFC-822 [2] in + NVT-ASCII. The Retrieve command is the "RETR" keyword, + followed by CRLF. + + Possible responses: + + the message data + + Close the connection + + ACKS + + The Acknowledge and Save command confirms that the client has + received and accepted the message. The ACKS command ends the + message reading transaction. The message is kept in the + mailbox. The current message indicator is incremented. The + server returns the count of characters in the now current + message to be transmitted. If there is no message to be read + or the message is marked deleted, the count of zero is + returned. The Acknowledge and Save command is the "ACKS" + keyword, followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in the next + message. + + + + + +Butler, et. al. [Page 8] + + + +RFC 937 February 1985 +Post Office Protocol + + + ACKD + + The Acknowledge and Delete command confirms that the client has + received and accepted the message. The ACKD command ends the + message reading transaction. If the user is authorized to have + write access to the mailbox, the message is deleted from the + mailbox. Actually, the message is only marked for deletion. + The actual change is made when the mailbox is released at the + end of the session or when the client selects another mailbox + with the FOLD command. The messages are not renumbered until + the mailbox is released. If the user does not have write + access to the mailbox no change is made to the mailbox. The + response is the same whether or not the message was actually + deleted. The current message indicator is incremented. The + server returns the count of characters in the now current + message to be transmitted. If there is no message to be read + or the message is marked deleted, the count of zero is + returned. The Acknowledge and Delete command is the "ACKD" + keyword, followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in the next + message. + + NACK + + The Negative Acknowledge command reports that the client did + not receive the message. The NACK command ends the message + reading transaction. The message is kept in the mailbox. The + current message indicator remains the same. The server returns + the count of characters in the current message. Since the + count to be returned is for the message just transmitted it the + message must exist and not be marked deleted, and the count + must be positive (non-zero). The Negative Acknowledge command + is the "NACK" keyword, followed by CRLF. + + Possible responses: + + "=ccc" + + where ccc is the number of characters in this message. + + + + + + +Butler, et. al. [Page 9] + + + +RFC 937 February 1985 +Post Office Protocol + + + QUIT + + The Quit command indicates the client is done with the session. + The server sends an OK response and then closes the connection. + The Quit command is the "QUIT" keyword, followed by CRLF. + + Possible responses: + + "+ OK" and Close the connection + + Replies + + Greeting + + The greeting is sent by the server as soon as the connection is + established. The greeting is a plus sign, followed by the + protocol name ("POP2"), followed by the server host name, + optionally followed by text, and ending with a CRLF. + + + + + The success or plus sign response indicates successful + completion of the operation specified in the command. The + success response is a plus sign, optionally followed by text, + and ending with a CRLF. + + - + + The failure or minus sign response indicates the failure of the + operation specified in the command. The failure response is a + minus sign, optionally followed by text, and ending with a + CRLF. + + = + + The length or equal sign response tells the length in + characters of the message referenced by the command. The + length response is a equal sign, followed by a number, + optionally followed by text, and ending with a CRLF. + + # + + The count or number sign response tells the number of messages + in a folder or mailbox referenced by the command. The count + response is a number sign, followed by a number, optionally + followed by text, and ending with a CRLF. + + + + +Butler, et. al. [Page 10] + + + +RFC 937 February 1985 +Post Office Protocol + + + Timeouts + + In any protocol of this type there have to be timeouts. Neither + side wants to get stuck waiting forever for the other side + (particularly is the other side has gone crazy or crashed). + + The client expects a reply to a command fairly quickly and so + should have a short timeout for this. This timeout is called T1. + + For some servers, it may take some processing to compute the + number of messages in a mailbox, or the length of a message, or + to reformat a stored message for transmission, so this time out + has to allow for such processing time. Also care must be taken + not to timeout waiting for the completion of a RETR reply while + a long message is in fact being transfered. + + The server expects the session to progress with some but not + excessive delay between commands and so should have a long timeout + waiting for the next command. This time out is T2. + + One model of use of this protocol is that any number of + different types of clients can be built with different ways of + interacting with the human user and the server, but still + expecting the client to open the connection to the server, + present a sequence of commands, and close the connection, + without waiting for intervention by the human user. With such + client implementations, it is reasonable for the server to have + a fairly small value for timeout T2. + + On the other hand, one could easily have the client be very + human user directed with the user making decisions between + commands. This would cause arbitrary delays between client + commands to the server, and require the value of timeout T2 to + be quite large. + +Implementation Discussion + + Comments on a Server on TOPS-20 + + On TOPS-20, a mailbox is a single file. New messages are appended + to the file. There is a separator line between messages. + + The tricky part of implementing a POP2 server on TOPS-20 is to + provide for deleting messages. This only has to be done for the + mailboxes (files) for which the user has write access. The + problem is to avoid both (1) preventing other users from accessing + or updating the mailbox for long periods, and (2) accidentally + deleting a message the user has not seen. + + +Butler, et. al. [Page 11] + + + +RFC 937 February 1985 +Post Office Protocol + + + One suggestion is as follows: + + When a mailbox is first selected, if the user has write access, + rename the mailbox file to some temporary name. Thus new + messages will be placed in a new instance of the mailbox file. + Conduct all POP2 operation on the temporary mailbox file + (including deleting messages). When the POP2 session is over + or another mailbox is selected, prepend any messages left + undeleted in the temporary file to the new instance of the + mailbox file. + + Sizes + + The maximum length of a command line is 512 characters (including + the command word and the CRLF). + + The maximum length of a reply line is 512 characters (including + the success indicator (+, -, =, #) and the CRLF). + + The maximum length of a text line is 1000 characters (including + CRLF). + + ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2 + Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix. + +Extensions Not Supported + + POP2 does not examine the internal data of messages. In particular, + the server does not parse message headers. + + The server doesn't have any state information (i.e., it doesn't know + from one session to the next what has happened). For example, the + server doesn't know which messages were received since the last time + the user used POP2, so it can't send just the "new" messages. + + + + + + + + + + + + + + + + +Butler, et. al. [Page 12] + + + +RFC 937 February 1985 +Post Office Protocol + + +Examples + + Example 1: + + Client Server + ------ ------ + Wait for connection + Open connection --> + <-- + POP2 USC-ISIF.ARPA Server + HELO POSTEL SECRET --> + <-- #2 messages in your mailbox + READ --> + <-- =537 characters in message 1 + RETR --> + <-- [data of message 1] + ACKD --> + <-- =234 characters in message 2 + RETR --> + <-- [data of message 2] + ACKD --> + <-- =0 no more messages + QUIT --> + <-- + OK, bye, bye + Close connection --> <-- Close connection + Go back to start + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 13] + + + +RFC 937 February 1985 +Post Office Protocol + + + Example 2: + + Client Server + ------ ------ + Wait for connection + Open connection --> + <-- + POP2 ISI-VAXA.ARPA server here + HELO smith secret --> + <-- #35 messages + FOLD /usr/spool/mail/smith --> + <-- #27 messages + READ 27 --> + <-- =10123 characters in that message + RETR --> + <-- [data of message 27] + ACKS --> + <-- =0 no more messages + QUIT --> + <-- + bye, call again sometime. + Close connection --> <-- Close connection + Go back to start + + Example 3: + + Client Server + ------ ------ + Wait for connection + Open connection --> + <-- + POP2 ISI-VAXA.ARPA server here + HELO Jones secret --> + <-- #0 messages + READ --> + <-- Close connection + Close connection --> + Go back to start + + + + + + + + + + + + + + + +Butler, et. al. [Page 14] + + + +RFC 937 February 1985 +Post Office Protocol + + +Formal Syntax + + <digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 + + <letter> = A | B | C | ... | Z + a | b | c | ... | z + + <punct> = ! | " | # | $ | % | & | ' | ( | ) | * | + + | , | - | / | : | < | = | > | ? | @ | + [ | ] | ^ | _ | ` | { | | | } | ~ + + <quote> = \ + + <any> = any one of the 128 ASCII codes + + <CR> = carriage return, code 10 + + <LF> = line feed, code 13 + + <SP> = space, code 32 + + <CRLF> = <CR> <LF> + + <print> = <letter> | <digit> | <punct> | <quote> <any> + + <char> = <print> | <SP> + + <word> = <print> | <print> <word> + + <string> = <char> | <char> <string> + + <ld> = <letter> | <digit> + + <ldh> = <letter> | <digit> | - + + <ldhs> = <ldh> | <ldh> <ldhs> + + <name> = <letter> [ [ <ldhs> ] <ld> ] + + <host> = <name> | <name> . <host> + + <user> = <word> + + <password> = <word> + + <mailbox> = <string> + + <number> = <digit> | <digit> <number> + + +Butler, et. al. [Page 15] + + + +RFC 937 February 1985 +Post Office Protocol + + + <helo> = HELO <SP> <user> <SP> <password> <CRLF> + + <fold> = FOLD <SP> <mailbox> <CRLF> + + <read> = READ [<SP> <number>] <CRLF> + + <retr> = RETR <CRLF> + + <acks> = ACKS <CRLF> + + <ackd> = ACKD <CRLF> + + <nack> = NACK <CRLF> + + <quit> = QUIT <CRLF> + + <ok> = + [<SP> <string>] <CRLF> + + <err> = - [<SP> <string>] <CRLF> + + <count> = # <number> [<SP> <string>] <CRLF> + + <greet> = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF> + + <length> = = <number> [<SP> <string>] <CRLF> + + <command> = <helo> | <fold> | <read> | <retr> | + <acks> | <ackd> | <nack> | <quit> + + <reply> = <ok> | <err> | <count> | <length> | <greet> + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 16] + + + +RFC 937 February 1985 +Post Office Protocol + + +Client State Diagram + + + | ^ + BYE + | Open | ----- + | Greet | Close + V ----- | + +-------+ QUIT +-------+ + | CALL |-------------->| EXIT | + +-------+ +-------+ + | ^ + | Greet | + | ----- | + | HELO | + +---->+ | | + #NNN ^ | | #NNN | + ---- | V V ---- | + FOLD | +-------+ QUIT | + +<---| NMBR |--------------------->+ + +-------+ ^ + ^ | | + | | #NNN | + | | ---- | + =CCC | | READ | + ---- | | | + FOLD | | =CCC | + | V ---- | + =CCC +--->+-------+ QUIT | + ---- ^ | SIZE |--------------------->+ + READ +<---+-------+ + ^ | + | | =CCC + data | | ---- + ---- | | RETR + ack | | + | V + +-------+ + | XFER | + +-------+ + + + + + + + + + + + +Butler, et. al. [Page 17] + + + +RFC 937 February 1985 +Post Office Protocol + + +Server State Diagram + + + +<----------------------+ Close + | | ----- + Listen | | Close + V | + +-------+ +-------+ + | LSTN | | DONE | + +-------+ +-------+ + | ^ + | Open | + | ----- | + | Greet | + | | + | QUIT | + V ----- | + +-------+ + BYE | + | AUTH |--------------------->+ + +-------+ ^ + | | + | HELO | + | ---- | + | #NNN | + | | + | QUIT | + V ----- | + FOLD +--->+-------+ + BYE | + ---- ^ | MBOX |--------------------->+ + #NNN +<---+-------+ ^ + ^ | | + | | READ | + FOLD | | ---- | + ---- | | =CCC | + #NNN | | QUIT | + | V ----- | + READ +--->+-------+ + BYE | + ---- ^ | ITEM |--------------------->+ + =CCC +<---+-------+ + ^ | + | | RETR + ack | | ---- + ---- | | data + =CCC | | + | V + +-------+ + | NEXT | + +-------+ + + +Butler, et. al. [Page 18] + + + +RFC 937 February 1985 +Post Office Protocol + + +Combined Flow Diagram + + + +----+ + |CALL|<------------------------------------------------------------+ + |LSTN| ^ + +----+ | + | Greet | + | | + | +----------------------------------------------------->+ | + | ^ QUIT | | + V | V | + +----+ +----+ +----+ | + |CALL| HELO |NMBR| |EXIT| | + |AUTH|------->|AUTH| |AUTH| | + +----+ +----+ +----+ | + | #NNN + Bye | | + | | | + | +------------------------------------>+ | | + | ^ QUIT | | | + V | V | | + +--->+----+ +----+ +----+ | | + FOLD ^ |NMBR| READ |SIZE| |EXIT| | | + ---- | |MBOX|------->|MBOX| |MBOX| | | + #NNN +<---+----+ +----+ +----+ | | + ^ | =CCC + Bye | | | + | | | | | + FOLD +<--------+ | +------------------->+ | | | + ---- ^ | ^ QUIT | | | | + #NNN | V | V | | | + +--->+-----+ +----+ +----+ | | | + READ ^ |SIZE | RETR |XFER| |EXIT| | | | + ---- | | ITEM|------->|ITEM| |ITEM| | | | + =CCC +<---+-----+ +----+ +----+ | | | + ^ | data | | | | + | | | | | | + =CCC | V + Bye | | | | + +----+ +----+ | | | | + |SIZE| Ack |XFER| | | | | + |NEXT|<-------|NEXT| | | | | + +----+ +----+ | | | | + | | | | + | | | | + V V V | + +-------+ | + | EXIT |-->+ + | DONE | + +-------+ + + +Butler, et. al. [Page 19] + + + +RFC 937 February 1985 +Post Office Protocol + + +Client Decision Table + + + | STATE | + -------+----------------------------------| + INPUT | CALL | NMBR | SIZE | XFER | EXIT | + -------+----------------------------------| + Greet | 2 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + #NNN | 1 | 3 | 1 | 1 | 6 | + -------+----------------------------------| + =CCC | 1 | 1 | 4 | 1 | 6 | + -------+----------------------------------| + data | 1 | 1 | 1 | 5 | 6 | + -------+----------------------------------| + + Bye | 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + Close | 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + other | 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + Timeout| 1 | 1 | 1 | 1 | 6 | + -------+----------------------------------| + + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 20] + + + +RFC 937 February 1985 +Post Office Protocol + + + Actions: + + 1. This is garbage. Send "QUIT", and go to EXIT state. + + 2. (a) If the greeting is right then send "HELO" + and go to NMBR state, + (b) Else send "QUIT" and go to EXIT state. + + 3. (a) If user wants this folder and NNN > 0 + then send "READ" and go to SIZE state, + (b) If user wants a this folder and NNN = 0 + then send "QUIT" and go to EXIT state, + (c) If user wants a different folder + then send "FOLD" and go to NMBR state. + + 4. (a) If user wants this message and CCC > 0 + then send "RETR" and go to XFER state, + (b) If user wants a this message and CCC = 0 + then send "QUIT" and go to EXIT state, + (c) If user wants a different message + then send "READ" and go to SIZE state. + + 5. (a) If user wants this message kept + then send "ACKS" and go to SIZE state, + (b) If user wants a this message deleted + then send "ACKD" and go to SIZE state, + (c) If user wants a this message again + then send "NACK" and go to SIZE state. + + 6. Close the connection. + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 21] + + + +RFC 937 February 1985 +Post Office Protocol + + +Server Decision Table + + + | STATE + -------+----------------------------------------- + INPUT | LSTN | AUTH | MBOX | ITEM | NEXT | DONE | + -------+-----------------------------------------| + Open | 2 | 1 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + HELO | 1 | 3 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + FOLD | 1 | 1 | 5 | 5 | 1 | 1 | + -------+-----------------------------------------| + READ | 1 | 1 | 6 | 6 | 1 | 1 | + -------+-----------------------------------------| + RETR | 1 | 1 | 1 | 7 | 1 | 1 | + -------+-----------------------------------------| + ACKS | 1 | 1 | 1 | 1 | 8 | 1 | + -------+-----------------------------------------| + ACKD | 1 | 1 | 1 | 1 | 8 | 1 | + -------+-----------------------------------------| + NACK | 1 | 1 | 1 | 1 | 8 | 1 | + -------+-----------------------------------------| + QUIT | 1 | 4 | 4 | 4 | 1 | 1 | + -------+-----------------------------------------| + Close | 1 | 1 | 1 | 1 | 1 | 9 | + -------+-----------------------------------------| + other | 1 | 1 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + Timeout| | 1 | 1 | 1 | 1 | 1 | + -------+-----------------------------------------| + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 22] + + + +RFC 937 February 1985 +Post Office Protocol + + + Actions: + + 1. This is garbage. Send "- error", and Close the connection. + + 2. Send the greeting. Go to AUTH state. + + 3. (a) If authorized user then send "#NNN" and go tp MBOX state, + (b) Else send "- error" and Close the connection. + + 4. Send "+ Bye" and go to DONE state. + + 5. Send "+NNN" and go to MBOX state. + + 6. Send "=CCC" and go to ITEM state. + + 7. If message exists then send the data and got to NEXT state, + Else Close the connection. + + 8. Do what ACKS/ACKD/NACK require and go to ITEM state. + + 9. Close the connection. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 23] + + + +RFC 937 February 1985 +Post Office Protocol + + +Acknowledgment + + We would like to acknowledge the helpful comments that we received on + the first version of POP described in RFC 918, and the draft of POP2 + distributed to interested parties. + +References + + [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, + USC/Information Sciences Institute, August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA-Internet Text + Messages", RFC 822, University of Delaware, August 1982. + + [3] Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information + Sciences Institute, October 1984. + + [4] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923, + USC/Information Sciences Institute, October 1984. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Butler, et. al. [Page 24] + diff --git a/RFC/rfc977.txt b/RFC/rfc977.txt new file mode 100644 index 00000000..0f965c48 --- /dev/null +++ b/RFC/rfc977.txt @@ -0,0 +1,1539 @@ +
+
+Network Working Group Brian Kantor (U.C. San Diego)
+Request for Comments: 977 Phil Lapsley (U.C. Berkeley)
+ February 1986
+
+ Network News Transfer Protocol
+
+ A Proposed Standard for the Stream-Based
+ Transmission of News
+
+Status of This Memo
+
+ NNTP specifies a protocol for the distribution, inquiry, retrieval,
+ and posting of news articles using a reliable stream-based
+ transmission of news among the ARPA-Internet community. NNTP is
+ designed so that news articles are stored in a central database
+ allowing a subscriber to select only those items he wishes to read.
+ Indexing, cross-referencing, and expiration of aged messages are also
+ provided. This RFC suggests a proposed protocol for the ARPA-Internet
+ community, and requests discussion and suggestions for improvements.
+ Distribution of this memo is unlimited.
+
+1. Introduction
+
+ For many years, the ARPA-Internet community has supported the
+ distribution of bulletins, information, and data in a timely fashion
+ to thousands of participants. We collectively refer to such items of
+ information as "news". Such news provides for the rapid
+ dissemination of items of interest such as software bug fixes, new
+ product reviews, technical tips, and programming pointers, as well as
+ rapid-fire discussions of matters of concern to the working computer
+ professional. News is very popular among its readers.
+
+ There are popularly two methods of distributing such news: the
+ Internet method of direct mailing, and the USENET news system.
+
+1.1. Internet Mailing Lists
+
+ The Internet community distributes news by the use of mailing lists.
+ These are lists of subscriber's mailbox addresses and remailing
+ sublists of all intended recipients. These mailing lists operate by
+ remailing a copy of the information to be distributed to each
+ subscriber on the mailing list. Such remailing is inefficient when a
+ mailing list grows beyond a dozen or so people, since sending a
+ separate copy to each of the subscribers occupies large quantities of
+ network bandwidth, CPU resources, and significant amounts of disk
+ storage at the destination host. There is also a significant problem
+ in maintenance of the list itself: as subscribers move from one job
+ to another; as new subscribers join and old ones leave; and as hosts
+ come in and out of service.
+
+
+
+
+Kantor & Lapsley [Page 1]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+1.2. The USENET News System
+
+ Clearly, a worthwhile reduction of the amount of these resources used
+ can be achieved if articles are stored in a central database on the
+ receiving host instead of in each subscriber's mailbox. The USENET
+ news system provides a method of doing just this. There is a central
+ repository of the news articles in one place (customarily a spool
+ directory of some sort), and a set of programs that allow a
+ subscriber to select those items he wishes to read. Indexing,
+ cross-referencing, and expiration of aged messages are also provided.
+
+1.3. Central Storage of News
+
+ For clusters of hosts connected together by fast local area networks
+ (such as Ethernet), it makes even more sense to consolidate news
+ distribution onto one (or a very few) hosts, and to allow access to
+ these news articles using a server and client model. Subscribers may
+ then request only the articles they wish to see, without having to
+ wastefully duplicate the storage of a copy of each item on each host.
+
+1.4. A Central News Server
+
+ A way to achieve these economies is to have a central computer system
+ that can provide news service to the other systems on the local area
+ network. Such a server would manage the collection of news articles
+ and index files, with each person who desires to read news bulletins
+ doing so over the LAN. For a large cluster of computer systems, the
+ savings in total disk space is clearly worthwhile. Also, this allows
+ workstations with limited disk storage space to participate in the
+ news without incoming items consuming oppressive amounts of the
+ workstation's disk storage.
+
+ We have heard rumors of somewhat successful attempts to provide
+ centralized news service using IBIS and other shared or distributed
+ file systems. While it is possible that such a distributed file
+ system implementation might work well with a group of similar
+ computers running nearly identical operating systems, such a scheme
+ is not general enough to offer service to a wide range of client
+ systems, especially when many diverse operating systems may be in use
+ among a group of clients. There are few (if any) shared or networked
+ file systems that can offer the generality of service that stream
+ connections using Internet TCP provide, particularly when a wide
+ range of host hardware and operating systems are considered.
+
+ NNTP specifies a protocol for the distribution, inquiry, retrieval,
+ and posting of news articles using a reliable stream (such as TCP)
+ server-client model. NNTP is designed so that news articles need only
+
+
+Kantor & Lapsley [Page 2]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ be stored on one (presumably central) host, and subscribers on other
+ hosts attached to the LAN may read news articles using stream
+ connections to the news host.
+
+ NNTP is modelled upon the news article specifications in RFC 850,
+ which describes the USENET news system. However, NNTP makes few
+ demands upon the structure, content, or storage of news articles, and
+ thus we believe it easily can be adapted to other non-USENET news
+ systems.
+
+ Typically, the NNTP server runs as a background process on one host,
+ and would accept connections from other hosts on the LAN. This works
+ well when there are a number of small computer systems (such as
+ workstations, with only one or at most a few users each), and a large
+ central server.
+
+1.5. Intermediate News Servers
+
+ For clusters of machines with many users (as might be the case in a
+ university or large industrial environment), an intermediate server
+ might be used. This intermediate or "slave" server runs on each
+ computer system, and is responsible for mediating news reading
+ requests and performing local caching of recently-retrieved news
+ articles.
+
+ Typically, a client attempting to obtain news service would first
+ attempt to connect to the news service port on the local machine. If
+ this attempt were unsuccessful, indicating a failed server, an
+ installation might choose to either deny news access, or to permit
+ connection to the central "master" news server.
+
+ For workstations or other small systems, direct connection to the
+ master server would probably be the normal manner of operation.
+
+ This specification does not cover the operation of slave NNTP
+ servers. We merely suggest that slave servers are a logical addition
+ to NNTP server usage which would enhance operation on large local
+ area networks.
+
+1.6. News Distribution
+
+ NNTP has commands which provide a straightforward method of
+ exchanging articles between cooperating hosts. Hosts which are well
+ connected on a local area or other fast network and who wish to
+ actually obtain copies of news articles for local storage might well
+ find NNTP to be a more efficient way to distribute news than more
+ traditional transfer methods (such as UUCP).
+
+
+Kantor & Lapsley [Page 3]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ In the traditional method of distributing news articles, news is
+ propagated from host to host by flooding - that is, each host will
+ send all its new news articles on to each host that it feeds. These
+ hosts will then in turn send these new articles on to other hosts
+ that they feed. Clearly, sending articles that a host already has
+ obtained a copy of from another feed (many hosts that receive news
+ are redundantly fed) again is a waste of time and communications
+ resources, but for transport mechanisms that are single-transaction
+ based rather than interactive (such as UUCP in the UNIX-world <1>),
+ distribution time is diminished by sending all articles and having
+ the receiving host simply discard the duplicates. This is an
+ especially true when communications sessions are limited to once a
+ day.
+
+ Using NNTP, hosts exchanging news articles have an interactive
+ mechanism for deciding which articles are to be transmitted. A host
+ desiring new news, or which has new news to send, will typically
+ contact one or more of its neighbors using NNTP. First it will
+ inquire if any new news groups have been created on the serving host
+ by means of the NEWGROUPS command. If so, and those are appropriate
+ or desired (as established by local site-dependent rules), those new
+ newsgroups can be created.
+
+ The client host will then inquire as to which new articles have
+ arrived in all or some of the newsgroups that it desires to receive,
+ using the NEWNEWS command. It will receive a list of new articles
+ from the server, and can request transmission of those articles that
+ it desires and does not already have.
+
+ Finally, the client can advise the server of those new articles which
+ the client has recently received. The server will indicate those
+ articles that it has already obtained copies of, and which articles
+ should be sent to add to its collection.
+
+ In this manner, only those articles which are not duplicates and
+ which are desired are transferred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 4]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+2. The NNTP Specification
+
+2.1. Overview
+
+ The news server specified by this document uses a stream connection
+ (such as TCP) and SMTP-like commands and responses. It is designed
+ to accept connections from hosts, and to provide a simple interface
+ to the news database.
+
+ This server is only an interface between programs and the news
+ databases. It does not perform any user interaction or presentation-
+ level functions. These "user-friendly" functions are better left to
+ the client programs, which have a better understanding of the
+ environment in which they are operating.
+
+ When used via Internet TCP, the contact port assigned for this
+ service is 119.
+
+2.2. Character Codes
+
+ Commands and replies are composed of characters from the ASCII
+ character set. When the transport service provides an 8-bit byte
+ (octet) transmission channel, each 7-bit character is transmitted
+ right justified in an octet with the high order bit cleared to zero.
+
+2.3. Commands
+
+ Commands consist of a command word, which in some cases may be
+ followed by a parameter. Commands with parameters must separate the
+ parameters from each other and from the command by one or more space
+ or tab characters. Command lines must be complete with all required
+ parameters, and may not contain more than one command.
+
+ Commands and command parameters are not case sensitive. That is, a
+ command or parameter word may be upper case, lower case, or any
+ mixture of upper and lower case.
+
+ Each command line must be terminated by a CR-LF (Carriage Return -
+ Line Feed) pair.
+
+ Command lines shall not exceed 512 characters in length, counting all
+ characters including spaces, separators, punctuation, and the
+ trailing CR-LF (thus there are 510 characters maximum allowed for the
+ command and its parameters). There is no provision for continuation
+ command lines.
+
+
+
+
+Kantor & Lapsley [Page 5]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+2.4. Responses
+
+ Responses are of two kinds, textual and status.
+
+2.4.1. Text Responses
+
+ Text is sent only after a numeric status response line has been sent
+ that indicates that text will follow. Text is sent as a series of
+ successive lines of textual matter, each terminated with CR-LF pair.
+ A single line containing only a period (.) is sent to indicate the
+ end of the text (i.e., the server will send a CR-LF pair at the end
+ of the last line of text, a period, and another CR-LF pair).
+
+ If the text contained a period as the first character of the text
+ line in the original, that first period is doubled. Therefore, the
+ client must examine the first character of each line received, and
+ for those beginning with a period, determine either that this is the
+ end of the text or whether to collapse the doubled period to a single
+ one.
+
+ The intention is that text messages will usually be displayed on the
+ user's terminal whereas command/status responses will be interpreted
+ by the client program before any possible display is done.
+
+2.4.2. Status Responses
+
+ These are status reports from the server and indicate the response to
+ the last command received from the client.
+
+ Status response lines begin with a 3 digit numeric code which is
+ sufficient to distinguish all responses. Some of these may herald
+ the subsequent transmission of text.
+
+ The first digit of the response broadly indicates the success,
+ failure, or progress of the previous command.
+
+ 1xx - Informative message
+ 2xx - Command ok
+ 3xx - Command ok so far, send the rest of it.
+ 4xx - Command was correct, but couldn't be performed for
+ some reason.
+ 5xx - Command unimplemented, or incorrect, or a serious
+ program error occurred.
+
+
+
+
+
+
+Kantor & Lapsley [Page 6]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ The next digit in the code indicates the function response category.
+
+ x0x - Connection, setup, and miscellaneous messages
+ x1x - Newsgroup selection
+ x2x - Article selection
+ x3x - Distribution functions
+ x4x - Posting
+ x8x - Nonstandard (private implementation) extensions
+ x9x - Debugging output
+
+ The exact response codes that should be expected from each command
+ are detailed in the description of that command. In addition, below
+ is listed a general set of response codes that may be received at any
+ time.
+
+ Certain status responses contain parameters such as numbers and
+ names. The number and type of such parameters is fixed for each
+ response code to simplify interpretation of the response.
+
+ Parameters are separated from the numeric response code and from each
+ other by a single space. All numeric parameters are decimal, and may
+ have leading zeros. All string parameters begin after the separating
+ space, and end before the following separating space or the CR-LF
+ pair at the end of the line. (String parameters may not, therefore,
+ contain spaces.) All text, if any, in the response which is not a
+ parameter of the response must follow and be separated from the last
+ parameter by a space. Also, note that the text following a response
+ number may vary in different implementations of the server. The
+ 3-digit numeric code should be used to determine what response was
+ sent.
+
+ Response codes not specified in this standard may be used for any
+ installation-specific additional commands also not specified. These
+ should be chosen to fit the pattern of x8x specified above. (Note
+ that debugging is provided for explicitly in the x9x response codes.)
+ The use of unspecified response codes for standard commands is
+ prohibited.
+
+ We have provided a response pattern x9x for debugging. Since much
+ debugging output may be classed as "informative messages", we would
+ expect, therefore, that responses 190 through 199 would be used for
+ various debugging outputs. There is no requirement in this
+ specification for debugging output, but if such is provided over the
+ connected stream, it must use these response codes. If appropriate
+ to a specific implementation, other x9x codes may be used for
+ debugging. (An example might be to use e.g., 290 to acknowledge a
+ remote debugging request.)
+
+
+Kantor & Lapsley [Page 7]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+2.4.3. General Responses
+
+ The following is a list of general response codes that may be sent by
+ the NNTP server. These are not specific to any one command, but may
+ be returned as the result of a connection, a failure, or some unusual
+ condition.
+
+ In general, 1xx codes may be ignored or displayed as desired; code
+ 200 or 201 is sent upon initial connection to the NNTP server
+ depending upon posting permission; code 400 will be sent when the
+ NNTP server discontinues service (by operator request, for example);
+ and 5xx codes indicate that the command could not be performed for
+ some unusual reason.
+
+ 100 help text
+ 190
+ through
+ 199 debug output
+
+ 200 server ready - posting allowed
+ 201 server ready - no posting allowed
+
+ 400 service discontinued
+
+ 500 command not recognized
+ 501 command syntax error
+ 502 access restriction or permission denied
+ 503 program fault - command not performed
+
+3. Command and Response Details
+
+ On the following pages are descriptions of each command recognized by
+ the NNTP server and the responses which will be returned by those
+ commands.
+
+ Each command is shown in upper case for clarity, although case is
+ ignored in the interpretation of commands by the NNTP server. Any
+ parameters are shown in lower case. A parameter shown in [square
+ brackets] is optional. For example, [GMT] indicates that the
+ triglyph GMT may present or omitted.
+
+ Every command described in this section must be implemented by all
+ NNTP servers.
+
+
+
+
+
+
+Kantor & Lapsley [Page 8]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ There is no prohibition against additional commands being added;
+ however, it is recommended that any such unspecified command begin
+ with the letter "X" to avoid conflict with later revisions of this
+ specification.
+
+ Implementors are reminded that such additional commands may not
+ redefine specified status response codes. Using additional
+ unspecified responses for standard commands is also prohibited.
+
+3.1. The ARTICLE, BODY, HEAD, and STAT commands
+
+ There are two forms to the ARTICLE command (and the related BODY,
+ HEAD, and STAT commands), each using a different method of specifying
+ which article is to be retrieved. When the ARTICLE command is
+ followed by a message-id in angle brackets ("<" and ">"), the first
+ form of the command is used; when a numeric parameter or no parameter
+ is supplied, the second form is invoked.
+
+ The text of the article is returned as a textual response, as
+ described earlier in this document.
+
+ The HEAD and BODY commands are identical to the ARTICLE command
+ except that they respectively return only the header lines or text
+ body of the article.
+
+ The STAT command is similar to the ARTICLE command except that no
+ text is returned. When selecting by message number within a group,
+ the STAT command serves to set the current article pointer without
+ sending text. The returned acknowledgement response will contain the
+ message-id, which may be of some value. Using the STAT command to
+ select by message-id is valid but of questionable value, since a
+ selection by message-id does NOT alter the "current article pointer".
+
+3.1.1. ARTICLE (selection by message-id)
+
+ ARTICLE <message-id>
+
+ Display the header, a blank line, then the body (text) of the
+ specified article. Message-id is the message id of an article as
+ shown in that article's header. It is anticipated that the client
+ will obtain the message-id from a list provided by the NEWNEWS
+ command, from references contained within another article, or from
+ the message-id provided in the response to some other commands.
+
+ Please note that the internally-maintained "current article pointer"
+ is NOT ALTERED by this command. This is both to facilitate the
+ presentation of articles that may be referenced within an article
+
+
+Kantor & Lapsley [Page 9]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ being read, and because of the semantic difficulties of determining
+ the proper sequence and membership of an article which may have been
+ posted to more than one newsgroup.
+
+3.1.2. ARTICLE (selection by number)
+
+ ARTICLE [nnn]
+
+ Displays the header, a blank line, then the body (text) of the
+ current or specified article. The optional parameter nnn is the
+
+ numeric id of an article in the current newsgroup and must be chosen
+ from the range of articles provided when the newsgroup was selected.
+ If it is omitted, the current article is assumed.
+
+ The internally-maintained "current article pointer" is set by this
+ command if a valid article number is specified.
+
+ [the following applies to both forms of the article command.] A
+ response indicating the current article number, a message-id string,
+ and that text is to follow will be returned.
+
+ The message-id string returned is an identification string contained
+ within angle brackets ("<" and ">"), which is derived from the header
+ of the article itself. The Message-ID header line (required by
+ RFC850) from the article must be used to supply this information. If
+ the message-id header line is missing from the article, a single
+ digit "0" (zero) should be supplied within the angle brackets.
+
+ Since the message-id field is unique with each article, it may be
+ used by a news reading program to skip duplicate displays of articles
+ that have been posted more than once, or to more than one newsgroup.
+
+3.1.3. Responses
+
+ 220 n <a> article retrieved - head and body follow
+ (n = article number, <a> = message-id)
+ 221 n <a> article retrieved - head follows
+ 222 n <a> article retrieved - body follows
+ 223 n <a> article retrieved - request text separately
+ 412 no newsgroup has been selected
+ 420 no current article has been selected
+ 423 no such article number in this group
+ 430 no such article found
+
+
+
+
+
+Kantor & Lapsley [Page 10]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.2. The GROUP command
+
+3.2.1. GROUP
+
+ GROUP ggg
+
+ The required parameter ggg is the name of the newsgroup to be
+ selected (e.g. "net.news"). A list of valid newsgroups may be
+ obtained from the LIST command.
+
+ The successful selection response will return the article numbers of
+ the first and last articles in the group, and an estimate of the
+ number of articles on file in the group. It is not necessary that
+ the estimate be correct, although that is helpful; it must only be
+ equal to or larger than the actual number of articles on file. (Some
+ implementations will actually count the number of articles on file.
+ Others will just subtract first article number from last to get an
+ estimate.)
+
+ When a valid group is selected by means of this command, the
+ internally maintained "current article pointer" is set to the first
+ article in the group. If an invalid group is specified, the
+ previously selected group and article remain selected. If an empty
+ newsgroup is selected, the "current article pointer" is in an
+ indeterminate state and should not be used.
+
+ Note that the name of the newsgroup is not case-dependent. It must
+ otherwise match a newsgroup obtained from the LIST command or an
+ error will result.
+
+3.2.2. Responses
+
+ 211 n f l s group selected
+ (n = estimated number of articles in group,
+ f = first article number in the group,
+ l = last article number in the group,
+ s = name of the group.)
+ 411 no such news group
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 11]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.3. The HELP command
+
+3.3.1. HELP
+
+ HELP
+
+ Provides a short summary of commands that are understood by this
+ implementation of the server. The help text will be presented as a
+ textual response, terminated by a single period on a line by itself.
+
+ 3.3.2. Responses
+
+ 100 help text follows
+
+3.4. The IHAVE command
+
+3.4.1. IHAVE
+
+ IHAVE <messageid>
+
+ The IHAVE command informs the server that the client has an article
+ whose id is <messageid>. If the server desires a copy of that
+ article, it will return a response instructing the client to send the
+ entire article. If the server does not want the article (if, for
+ example, the server already has a copy of it), a response indicating
+ that the article is not wanted will be returned.
+
+ If transmission of the article is requested, the client should send
+ the entire article, including header and body, in the manner
+ specified for text transmission from the server. A response code
+ indicating success or failure of the transferral of the article will
+ be returned.
+
+ This function differs from the POST command in that it is intended
+ for use in transferring already-posted articles between hosts.
+ Normally it will not be used when the client is a personal
+ newsreading program. In particular, this function will invoke the
+ server's news posting program with the appropriate settings (flags,
+ options, etc) to indicate that the forthcoming article is being
+ forwarded from another host.
+
+ The server may, however, elect not to post or forward the article if
+ after further examination of the article it deems it inappropriate to
+ do so. The 436 or 437 error codes may be returned as appropriate to
+ the situation.
+
+ Reasons for such subsequent rejection of an article may include such
+
+
+Kantor & Lapsley [Page 12]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ problems as inappropriate newsgroups or distributions, disk space
+ limitations, article lengths, garbled headers, and the like. These
+ are typically restrictions enforced by the server host's news
+ software and not necessarily the NNTP server itself.
+
+3.4.2. Responses
+
+ 235 article transferred ok
+ 335 send article to be transferred. End with <CR-LF>.<CR-LF>
+ 435 article not wanted - do not send it
+ 436 transfer failed - try again later
+ 437 article rejected - do not try again
+
+ An implementation note:
+
+ Because some host news posting software may not be able to decide
+ immediately that an article is inappropriate for posting or
+ forwarding, it is acceptable to acknowledge the successful transfer
+ of the article and to later silently discard it. Thus it is
+ permitted to return the 235 acknowledgement code and later discard
+ the received article. This is not a fully satisfactory solution to
+ the problem. Perhaps some implementations will wish to send mail to
+ the author of the article in certain of these cases.
+
+3.5. The LAST command
+
+3.5.1. LAST
+
+ LAST
+
+ The internally maintained "current article pointer" is set to the
+ previous article in the current newsgroup. If already positioned at
+ the first article of the newsgroup, an error message is returned and
+ the current article remains selected.
+
+ The internally-maintained "current article pointer" is set by this
+ command.
+
+ A response indicating the current article number, and a message-id
+ string will be returned. No text is sent in response to this
+ command.
+
+3.5.2. Responses
+
+ 223 n a article retrieved - request text separately
+ (n = article number, a = unique article id)
+
+
+
+Kantor & Lapsley [Page 13]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ 412 no newsgroup selected
+ 420 no current article has been selected
+ 422 no previous article in this group
+
+3.6. The LIST command
+
+3.6.1. LIST
+
+ LIST
+
+ Returns a list of valid newsgroups and associated information. Each
+ newsgroup is sent as a line of text in the following format:
+
+ group last first p
+
+ where <group> is the name of the newsgroup, <last> is the number of
+ the last known article currently in that newsgroup, <first> is the
+ number of the first article currently in the newsgroup, and <p> is
+ either 'y' or 'n' indicating whether posting to this newsgroup is
+ allowed ('y') or prohibited ('n').
+
+ The <first> and <last> fields will always be numeric. They may have
+ leading zeros. If the <last> field evaluates to less than the
+ <first> field, there are no articles currently on file in the
+ newsgroup.
+
+ Note that posting may still be prohibited to a client even though the
+ LIST command indicates that posting is permitted to a particular
+ newsgroup. See the POST command for an explanation of client
+ prohibitions. The posting flag exists for each newsgroup because
+ some newsgroups are moderated or are digests, and therefore cannot be
+ posted to; that is, articles posted to them must be mailed to a
+ moderator who will post them for the submitter. This is independent
+ of the posting permission granted to a client by the NNTP server.
+
+ Please note that an empty list (i.e., the text body returned by this
+ command consists only of the terminating period) is a possible valid
+ response, and indicates that there are currently no valid newsgroups.
+
+3.6.2. Responses
+
+ 215 list of newsgroups follows
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 14]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.7. The NEWGROUPS command
+
+3.7.1. NEWGROUPS
+
+ NEWGROUPS date time [GMT] [<distributions>]
+
+ A list of newsgroups created since <date and time> will be listed in
+ the same format as the LIST command.
+
+ The date is sent as 6 digits in the format YYMMDD, where YY is the
+ last two digits of the year, MM is the two digits of the month (with
+ leading zero, if appropriate), and DD is the day of the month (with
+ leading zero, if appropriate). The closest century is assumed as
+ part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
+ 1999, 00 is 2000).
+
+ Time must also be specified. It must be as 6 digits HHMMSS with HH
+ being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
+ 00-59. The time is assumed to be in the server's timezone unless the
+ token "GMT" appears, in which case both time and date are evaluated
+ at the 0 meridian.
+
+ The optional parameter "distributions" is a list of distribution
+ groups, enclosed in angle brackets. If specified, the distribution
+ portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
+ examined for a match with the distribution categories listed, and
+ only those new newsgroups which match will be listed. If more than
+ one distribution group is to be listed, they must be separated by
+ commas within the angle brackets.
+
+ Please note that an empty list (i.e., the text body returned by this
+ command consists only of the terminating period) is a possible valid
+ response, and indicates that there are currently no new newsgroups.
+
+3.7.2. Responses
+
+ 231 list of new newsgroups follows
+
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 15]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.8. The NEWNEWS command
+
+3.8.1. NEWNEWS
+
+ NEWNEWS newsgroups date time [GMT] [<distribution>]
+
+ A list of message-ids of articles posted or received to the specified
+ newsgroup since "date" will be listed. The format of the listing will
+ be one message-id per line, as though text were being sent. A single
+ line consisting solely of one period followed by CR-LF will terminate
+ the list.
+
+ Date and time are in the same format as the NEWGROUPS command.
+
+ A newsgroup name containing a "*" (an asterisk) may be specified to
+ broaden the article search to some or all newsgroups. The asterisk
+ will be extended to match any part of a newsgroup name (e.g.,
+ net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
+ if only an asterisk is given as the newsgroup name, all newsgroups
+ will be searched for new news.
+
+ (Please note that the asterisk "*" expansion is a general
+ replacement; in particular, the specification of e.g., net.*.unix
+ should be correctly expanded to embrace names such as net.wombat.unix
+ and net.whocares.unix.)
+
+ Conversely, if no asterisk appears in a given newsgroup name, only
+ the specified newsgroup will be searched for new articles. Newsgroup
+ names must be chosen from those returned in the listing of available
+ groups. Multiple newsgroup names (including a "*") may be specified
+ in this command, separated by a comma. No comma shall appear after
+ the last newsgroup in the list. [Implementors are cautioned to keep
+ the 512 character command length limit in mind.]
+
+ The exclamation point ("!") may be used to negate a match. This can
+ be used to selectively omit certain newsgroups from an otherwise
+ larger list. For example, a newsgroups specification of
+ "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
+ all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
+ matched. If used, the exclamation point must appear as the first
+ character of the given newsgroup name or pattern.
+
+ The optional parameter "distributions" is a list of distribution
+ groups, enclosed in angle brackets. If specified, the distribution
+ portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
+ be examined for a match with the distribution categories listed, and
+ only those articles which have at least one newsgroup belonging to
+
+
+Kantor & Lapsley [Page 16]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ the list of distributions will be listed. If more than one
+ distribution group is to be supplied, they must be separated by
+ commas within the angle brackets.
+
+ The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
+ news is discussed in an earlier part of this document.
+
+ Please note that an empty list (i.e., the text body returned by this
+ command consists only of the terminating period) is a possible valid
+ response, and indicates that there is currently no new news.
+
+3.8.2. Responses
+
+ 230 list of new articles by message-id follows
+
+3.9. The NEXT command
+
+3.9.1. NEXT
+
+ NEXT
+
+ The internally maintained "current article pointer" is advanced to
+ the next article in the current newsgroup. If no more articles
+ remain in the current group, an error message is returned and the
+ current article remains selected.
+
+ The internally-maintained "current article pointer" is set by this
+ command.
+
+ A response indicating the current article number, and the message-id
+ string will be returned. No text is sent in response to this
+ command.
+
+3.9.2. Responses
+
+ 223 n a article retrieved - request text separately
+ (n = article number, a = unique article id)
+ 412 no newsgroup selected
+ 420 no current article has been selected
+ 421 no next article in this group
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 17]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+3.10. The POST command
+
+3.10.1. POST
+
+ POST
+
+ If posting is allowed, response code 340 is returned to indicate that
+ the article to be posted should be sent. Response code 440 indicates
+ that posting is prohibited for some installation-dependent reason.
+
+ If posting is permitted, the article should be presented in the
+ format specified by RFC850, and should include all required header
+ lines. After the article's header and body have been completely sent
+ by the client to the server, a further response code will be returned
+ to indicate success or failure of the posting attempt.
+
+ The text forming the header and body of the message to be posted
+ should be sent by the client using the conventions for text received
+ from the news server: A single period (".") on a line indicates the
+ end of the text, with lines starting with a period in the original
+ text having that period doubled during transmission.
+
+ No attempt shall be made by the server to filter characters, fold or
+ limit lines, or otherwise process incoming text. It is our intent
+ that the server just pass the incoming message to be posted to the
+ server installation's news posting software, which is separate from
+ this specification. See RFC850 for more details.
+
+ Since most installations will want the client news program to allow
+ the user to prepare his message using some sort of text editor, and
+ transmit it to the server for posting only after it is composed, the
+ client program should take note of the herald message that greeted it
+ when the connection was first established. This message indicates
+ whether postings from that client are permitted or not, and can be
+ used to caution the user that his access is read-only if that is the
+ case. This will prevent the user from wasting a good deal of time
+ composing a message only to find posting of the message was denied.
+ The method and determination of which clients and hosts may post is
+ installation dependent and is not covered by this specification.
+
+3.10.2. Responses
+
+ 240 article posted ok
+ 340 send article to be posted. End with <CR-LF>.<CR-LF>
+ 440 posting not allowed
+ 441 posting failed
+
+
+
+Kantor & Lapsley [Page 18]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ (for reference, one of the following codes will be sent upon initial
+ connection; the client program should determine whether posting is
+ generally permitted from these:) 200 server ready - posting allowed
+ 201 server ready - no posting allowed
+
+3.11. The QUIT command
+
+3.11.1. QUIT
+
+ QUIT
+
+ The server process acknowledges the QUIT command and then closes the
+ connection to the client. This is the preferred method for a client
+ to indicate that it has finished all its transactions with the NNTP
+ server.
+
+ If a client simply disconnects (or the connection times out, or some
+ other fault occurs), the server should gracefully cease its attempts
+ to service the client.
+
+3.11.2. Responses
+
+ 205 closing connection - goodbye!
+
+3.12. The SLAVE command
+
+3.12.1. SLAVE
+
+ SLAVE
+
+ Indicates to the server that this client connection is to a slave
+ server, rather than a user.
+
+ This command is intended for use in separating connections to single
+ users from those to subsidiary ("slave") servers. It may be used to
+ indicate that priority should therefore be given to requests from
+ this client, as it is presumably serving more than one person. It
+ might also be used to determine which connections to close when
+ system load levels are exceeded, perhaps giving preference to slave
+ servers. The actual use this command is put to is entirely
+ implementation dependent, and may vary from one host to another. In
+ NNTP servers which do not give priority to slave servers, this
+ command must nonetheless be recognized and acknowledged.
+
+3.12.2. Responses
+
+ 202 slave status noted
+
+
+Kantor & Lapsley [Page 19]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+4. Sample Conversations
+
+ These are samples of the conversations that might be expected with
+ the news server in hypothetical sessions. The notation C: indicates
+ commands sent to the news server from the client program; S: indicate
+ responses received from the server by the client.
+
+4.1. Example 1 - relative access with NEXT
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 200 wombatvax news server ready - posting ok
+
+ (client asks for a current newsgroup list)
+ C: LIST
+ S: 215 list of newsgroups follows
+ S: net.wombats 00543 00501 y
+ S: net.unix-wizards 10125 10011 y
+ (more information here)
+ S: net.idiots 00100 00001 n
+ S: .
+
+ (client selects a newsgroup)
+ C: GROUP net.unix-wizards
+ S: 211 104 10011 10125 net.unix-wizards group selected
+ (there are 104 articles on file, from 10011 to 10125)
+
+ (client selects an article to read)
+ C: STAT 10110
+ S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
+ only (article 10110 selected, its message-id is
+ <23445@sdcsvax.ARPA>)
+
+ (client examines the header)
+ C: HEAD
+ S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head
+ follows (text of the header appears here)
+ S: .
+
+ (client wants to see the text body of the article)
+ C: BODY
+ S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body
+ follows (body text here)
+ S: .
+
+ (client selects next article in group)
+
+
+Kantor & Lapsley [Page 20]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ C: NEXT
+ S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics
+ only (article 10113 was next in group)
+
+ (client finishes session)
+ C: QUIT
+ S: 205 goodbye.
+
+4.2. Example 2 - absolute article access with ARTICLE
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 201 UCB-VAX netnews server ready -- no posting allowed
+
+ C: GROUP msgs
+ S: 211 103 402 504 msgs Your new group is msgs
+ (there are 103 articles, from 402 to 504)
+
+ C: ARTICLE 401
+ S: 423 No such article in this newsgroup
+
+ C: ARTICLE 402
+ S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
+ S: (article header and body follow)
+ S: .
+
+ C: HEAD 403
+ S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows
+ S: (article header follows)
+ S: .
+
+ C: QUIT
+ S: 205 UCB-VAX news server closing connection. Goodbye.
+
+4.3. Example 3 - NEWGROUPS command
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 200 Imaginary Institute News Server ready (posting ok)
+
+ (client asks for new newsgroups since April 3, 1985)
+ C: NEWGROUPS 850403 020000
+
+ S: 231 New newsgroups since 03/04/85 02:00:00 follow
+
+
+
+Kantor & Lapsley [Page 21]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ S: net.music.gdead
+ S: net.games.sources
+ S: .
+
+ C: GROUP net.music.gdead
+ S: 211 0 1 1 net.music.gdead Newsgroup selected
+ (there are no articles in that newsgroup, and
+ the first and last article numbers should be ignored)
+
+ C: QUIT
+ S: 205 Imaginary Institute news server ceasing service. Bye!
+
+4.4. Example 4 - posting a news article
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 200 BANZAIVAX news server ready, posting allowed.
+
+ C: POST
+ S: 340 Continue posting; Period on a line by itself to end
+ C: (transmits news article in RFC850 format)
+ C: .
+ S: 240 Article posted successfully.
+
+ C: QUIT
+ S: 205 BANZAIVAX closing connection. Goodbye.
+
+4.5. Example 5 - interruption due to operator request
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 201 genericvax news server ready, no posting allowed.
+
+ (assume normal conversation for some time, and
+ that a newsgroup has been selected)
+
+ C: NEXT
+ S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
+
+ C: HEAD
+ C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
+
+ S: (sends head of article, but halfway through is
+ interrupted by an operator request. The following
+ then occurs, without client intervention.)
+
+
+Kantor & Lapsley [Page 22]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ S: (ends current line with a CR-LF pair)
+ S: .
+ S: 400 Connection closed by operator. Goodbye.
+ S: (closes connection)
+
+4.6. Example 6 - Using the news server to distribute news between
+ systems.
+
+ S: (listens at TCP port 119)
+
+ C: (requests connection on TCP port 119)
+ S: 201 Foobar NNTP server ready (no posting)
+
+ (client asks for new newsgroups since 2 am, May 15, 1985)
+ C: NEWGROUPS 850515 020000
+ S: 235 New newsgroups since 850515 follow
+ S: net.fluff
+ S: net.lint
+ S: .
+
+ (client asks for new news articles since 2 am, May 15, 1985)
+ C: NEWNEWS * 850515 020000
+ S: 230 New news since 850515 020000 follows
+ S: <1772@foo.UUCP>
+ S: <87623@baz.UUCP>
+ S: <17872@GOLD.CSNET>
+ S: .
+
+ (client asks for article <1772@foo.UUCP>)
+ C: ARTICLE <1772@foo.UUCP>
+ S: 220 <1772@foo.UUCP> All of article follows
+ S: (sends entire message)
+ S: .
+
+ (client asks for article <87623@baz.UUCP>
+ C: ARTICLE <87623@baz.UUCP>
+ S: 220 <87623@baz.UUCP> All of article follows
+ S: (sends entire message)
+ S: .
+
+ (client asks for article <17872@GOLD.CSNET>
+ C: ARTICLE <17872@GOLD.CSNET>
+ S: 220 <17872@GOLD.CSNET> All of article follows
+ S: (sends entire message)
+ S: .
+
+
+
+
+Kantor & Lapsley [Page 23]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ (client offers an article it has received recently)
+ C: IHAVE <4105@ucbvax.ARPA>
+ S: 435 Already seen that one, where you been?
+
+ (client offers another article)
+ C: IHAVE <4106@ucbvax.ARPA>
+ S: 335 News to me! <CRLF.CRLF> to end.
+ C: (sends article)
+ C: .
+ S: 235 Article transferred successfully. Thanks.
+
+ (or)
+
+ S: 436 Transfer failed.
+
+ (client is all through with the session)
+ C: QUIT
+ S: 205 Foobar NNTP server bids you farewell.
+
+4.7. Summary of commands and responses.
+
+ The following are the commands recognized and responses returned by
+ the NNTP server.
+
+4.7.1. Commands
+
+ ARTICLE
+ BODY
+ GROUP
+ HEAD
+ HELP
+ IHAVE
+ LAST
+ LIST
+ NEWGROUPS
+ NEWNEWS
+ NEXT
+ POST
+ QUIT
+ SLAVE
+ STAT
+
+4.7.2. Responses
+
+ 100 help text follows
+ 199 debug output
+
+
+
+Kantor & Lapsley [Page 24]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ 200 server ready - posting allowed
+ 201 server ready - no posting allowed
+ 202 slave status noted
+ 205 closing connection - goodbye!
+ 211 n f l s group selected
+ 215 list of newsgroups follows
+ 220 n <a> article retrieved - head and body follow 221 n <a> article
+ retrieved - head follows
+ 222 n <a> article retrieved - body follows
+ 223 n <a> article retrieved - request text separately 230 list of new
+ articles by message-id follows
+ 231 list of new newsgroups follows
+ 235 article transferred ok
+ 240 article posted ok
+
+ 335 send article to be transferred. End with <CR-LF>.<CR-LF>
+ 340 send article to be posted. End with <CR-LF>.<CR-LF>
+
+ 400 service discontinued
+ 411 no such news group
+ 412 no newsgroup has been selected
+ 420 no current article has been selected
+ 421 no next article in this group
+ 422 no previous article in this group
+ 423 no such article number in this group
+ 430 no such article found
+ 435 article not wanted - do not send it
+ 436 transfer failed - try again later
+ 437 article rejected - do not try again.
+ 440 posting not allowed
+ 441 posting failed
+
+ 500 command not recognized
+ 501 command syntax error
+ 502 access restriction or permission denied
+ 503 program fault - command not performed
+
+4.8. A Brief Word about the USENET News System
+
+ In the UNIX world, which traditionally has been linked by 1200 baud
+ dial-up telephone lines, the USENET News system has evolved to handle
+ central storage, indexing, retrieval, and distribution of news. With
+ the exception of its underlying transport mechanism (UUCP), USENET
+ News is an efficient means of providing news and bulletin service to
+ subscribers on UNIX and other hosts worldwide. The USENET News
+
+
+
+
+Kantor & Lapsley [Page 25]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+ system is discussed in detail in RFC 850. It runs on most versions
+ of UNIX and on many other operating systems, and is customarily
+ distributed without charge.
+
+ USENET uses a spooling area on the UNIX host to store news articles,
+ one per file. Each article consists of a series of heading text,
+ which contain the sender's identification and organizational
+ affiliation, timestamps, electronic mail reply paths, subject,
+ newsgroup (subject category), and the like. A complete news article
+ is reproduced in its entirety below. Please consult RFC 850 for more
+ details.
+
+ Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
+ sdcsvax.UUCP
+ Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
+ Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
+ !honman
+ From: honman@unitek.uucp (Man Wong)
+ Newsgroups: net.unix-wizards
+ Subject: foreground -> background ?
+ Message-ID: <167@unitek.uucp>
+ Date: 25 Sep 85 23:51:52 GMT
+ Date-Received: 29 Sep 85 09:54:48 GMT
+ Reply-To: honman@unitek.UUCP (Hon-Man Wong)
+ Distribution: net.all
+ Organization: Unitek Technologies Corporation
+ Lines: 12
+
+ I have a process (C program) which generates a child and waits for
+ it to return. What I would like to do is to be able to run the
+ child process interactively for a while before kicking itself into
+ the background so I can return to the parent process (while the
+ child process is RUNNING in the background). Can it be done? And
+ if it can, how?
+
+ Please reply by E-mail. Thanks in advance.
+
+ Hon-Man Wong
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 26]
+
+
+
+RFC 977 February 1986
+Network News Transfer Protocol
+
+
+5. References
+
+ [1] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", RFC-822, Department of Electrical Engineering,
+ University of Delaware, August, 1982.
+
+ [2] Horton, M., "Standard for Interchange of USENET Messages",
+ RFC-850, USENET Project, June, 1983.
+
+ [3] Postel, J., "Transmission Control Protocol- DARPA Internet
+ Program Protocol Specification", RFC-793, USC/Information
+ Sciences Institute, September, 1981.
+
+ [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
+ USC/Information Sciences Institute, August, 1982.
+
+6. Acknowledgements
+
+ The authors wish to express their heartfelt thanks to those many
+ people who contributed to this specification, and especially to Erik
+ Fair and Chuq von Rospach, without whose inspiration this whole thing
+ would not have been necessary.
+
+7. Notes
+
+ <1> UNIX is a trademark of Bell Laboratories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kantor & Lapsley [Page 27]
+
|