From d78b61e3efaea197a6e5b2b72bf2981a9ed69461 Mon Sep 17 00:00:00 2001 From: Rob Funk Date: Tue, 8 Jun 2004 03:59:01 +0000 Subject: Add files from ESR's dev directory that weren't under version control svn path=/trunk/; revision=3881 --- RFC/draft-klensin-cram-03.txt | 261 ++ RFC/draft-newman-tls-imappop-05.txt | 618 ++++ RFC/lan-mail-protocols | 1330 ++++++++ RFC/rfc1081.txt | 899 ++++++ RFC/rfc1123.txt | 5782 +++++++++++++++++++++++++++++++++++ RFC/rfc1176.txt | 1683 ++++++++++ RFC/rfc1203.txt | 2747 +++++++++++++++++ RFC/rfc1225.txt | 899 ++++++ RFC/rfc1460.txt | 955 ++++++ RFC/rfc1521.txt | 4539 +++++++++++++++++++++++++++ RFC/rfc1725.txt | 1011 ++++++ RFC/rfc1730.txt | 4318 ++++++++++++++++++++++++++ RFC/rfc1731.txt | 339 ++ RFC/rfc1732.txt | 283 ++ RFC/rfc1734.txt | 283 ++ RFC/rfc1870.txt | 507 +++ RFC/rfc1891.txt | 1739 +++++++++++ RFC/rfc1892.txt | 227 ++ RFC/rfc1893.txt | 843 +++++ RFC/rfc1894.txt | 2187 +++++++++++++ RFC/rfc1938.txt | 1011 ++++++ RFC/rfc1939.txt | 1291 ++++++++ RFC/rfc1985.txt | 395 +++ RFC/rfc2033.txt | 395 +++ RFC/rfc2060.txt | 4595 ++++++++++++++++++++++++++++ RFC/rfc2061.txt | 171 ++ RFC/rfc2062.txt | 451 +++ RFC/rfc2177.txt | 227 ++ RFC/rfc2195.txt | 283 ++ RFC/rfc2449.txt | 1067 +++++++ RFC/rfc2554.txt | 619 ++++ RFC/rfc2645.txt | 507 +++ RFC/rfc2683.txt | 1291 ++++++++ RFC/rfc821.txt | 4050 ++++++++++++++++++++++++ RFC/rfc822.txt | 2901 ++++++++++++++++++ RFC/rfc937.txt | 1392 +++++++++ RFC/rfc977.txt | 1539 ++++++++++ 37 files changed, 53635 insertions(+) create mode 100644 RFC/draft-klensin-cram-03.txt create mode 100644 RFC/draft-newman-tls-imappop-05.txt create mode 100644 RFC/lan-mail-protocols create mode 100644 RFC/rfc1081.txt create mode 100644 RFC/rfc1123.txt create mode 100644 RFC/rfc1176.txt create mode 100644 RFC/rfc1203.txt create mode 100644 RFC/rfc1225.txt create mode 100644 RFC/rfc1460.txt create mode 100644 RFC/rfc1521.txt create mode 100644 RFC/rfc1725.txt create mode 100644 RFC/rfc1730.txt create mode 100644 RFC/rfc1731.txt create mode 100644 RFC/rfc1732.txt create mode 100644 RFC/rfc1734.txt create mode 100644 RFC/rfc1870.txt create mode 100644 RFC/rfc1891.txt create mode 100644 RFC/rfc1892.txt create mode 100644 RFC/rfc1893.txt create mode 100644 RFC/rfc1894.txt create mode 100644 RFC/rfc1938.txt create mode 100644 RFC/rfc1939.txt create mode 100644 RFC/rfc1985.txt create mode 100644 RFC/rfc2033.txt create mode 100644 RFC/rfc2060.txt create mode 100644 RFC/rfc2061.txt create mode 100644 RFC/rfc2062.txt create mode 100644 RFC/rfc2177.txt create mode 100644 RFC/rfc2195.txt create mode 100644 RFC/rfc2449.txt create mode 100644 RFC/rfc2554.txt create mode 100644 RFC/rfc2645.txt create mode 100644 RFC/rfc2683.txt create mode 100644 RFC/rfc821.txt create mode 100644 RFC/rfc822.txt create mode 100644 RFC/rfc937.txt create mode 100644 RFC/rfc977.txt (limited to 'RFC') 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 + + 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 + + ... + 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" + + 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" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + C: a003 AUTHENTICATE "PLAIN" {21+} + C: timtanstaaftanstaaf + S: a003 OK CRAM-MD5 password initialized + + Note: In this example, 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: + 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: + 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: + 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: + ... + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + 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: + S: + +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 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 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 + 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 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 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:". + 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 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: + + 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:". + + 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 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 + EXISTS the number of messages in the mailbox + 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 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 + 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 + 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 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 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 + 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 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 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 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: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 + 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 + 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 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 + 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 + 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 + Richard Acuff + Bill Yeager + Christopher Lane + Bjorn Victor + + Additional input was also received from: + + Andrew Sweer + Tom Gruber + Kevin Brock + Mark Crispin + +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: + 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: + 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: + 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: + ... + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + 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: + S: + +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: + 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: + 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: + 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: + + + + 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: + ... + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + + + + +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 := + + x-token := + + subtype := token ; case-insensitive + + parameter := attribute "=" value + + attribute := token ; case-insensitive + + value := token / quoted-string + + token := 1* + + 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 / 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 + To: Ned Freed + 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 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 + To: Ned Freed + 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: + 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: + 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: + 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: + 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: + 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: + Content-Type: multipart/alternative; boundary=42 + Content-ID: + + --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: + + --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: + + --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: + + 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 + To: Ned Freed + 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 richtext. + as defined in RFC 1341 + Isn't it + cool? + + --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 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 := + + 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 / " / "@" + / "," / ";" / ":" / "\" / <"> + / "/" / "[" / "]" / "?" / "=" + ; 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 := + + + + + + + + + + + + + +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: + 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: + 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: + + + + 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: + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + +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 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 + + EXISTS The number of messages in the mailbox + + RECENT The number of messages added to the mailbox since + the previous time this mailbox was read + + OK [UIDVALIDITY ] + 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 + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + 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. + + 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 Messages that contain the specified string in the + envelope structure's BCC field. + + BEFORE Messages whose internal date is earlier than the + specified date. + + BODY Messages that contain the specified string in the + body of the message. + + CC 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 Messages that contain the specified string in the + envelope structure's FROM field. + + HEADER + 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 Messages with the specified keyword set. + + LARGER 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 + 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 Messages whose internal date is within the + specified date. + + OR + Messages that match either search key. + + RECENT Messages that have the \Recent flag set. + + SEEN Messages that have the \Seen flag set. + + SENTBEFORE + Messages whose [RFC-822] Date: header is earlier + than the specified date. + + SENTON Messages whose [RFC-822] Date: header is within the + specified date. + + SENTSINCE + Messages whose [RFC-822] Date: header is within or + later than the specified date. + + SINCE Messages whose internal date is within or later + than the specified date. + + SMALLER Messages with an RFC822.SIZE smaller than the + specified number of octets. + + SUBJECT + Messages that contain the specified string in the + envelope structure's SUBJECT field. + + TEXT Messages that contain the specified string in the + header or body of the message. + + TO Messages that contain the specified string in the + envelope structure's TO field. + + UID + 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 + 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[
] + 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[
] + 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 + 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 + 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: + 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 + 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 + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS + 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 + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS + 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 + 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 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 + "") + 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 + S: Subject: IMAP4 WG mtg summary and minutes + S: To: imap@cac.washington.edu + S: cc: minutes@CNRI.Reston.VA.US, John Klensin + S: Message-Id: + 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 ::= + + 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 ::= + + CHAR8 ::= + + 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 ::= + + create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + + CRLF ::= CR LF + + CTL ::= + + 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 ::= + + 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 ::= / + "\" 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*] + + 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 ::= + + 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* + + text ::= 1*TEXT_CHAR + + text_mime2 ::= "=?" "?" "?" + "?=" + ;; Syntax defined in [MIME-2] + + TEXT_CHAR ::= + + 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 + + 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 (store command data item) ............... 34 + +FLAGS.SILENT (store command data item) ........ 34 + -FLAGS (store command data item) ............... 34 + -FLAGS.SILENT (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 (search key) .................................. 27 + BEFORE (search key) ................................. 27 + BODY (fetch item) .......................................... 29 + BODY (fetch result) ........................................ 46 + BODY (search key) ................................. 27 + BODY.PEEK[
] (fetch item) .......................... 30 + BODYSTRUCTURE (fetch item) ................................. 31 + BODYSTRUCTURE (fetch result) ............................... 47 + BODY[
] (fetch item) ............................... 29 + BODY[section] (fetch result) ............................... 46 + BYE (response) ............................................. 41 + CAPABILITY (command) ....................................... 10 + CAPABILITY (response) ...................................... 42 + CC (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 (store command data item) ................ 34 + FLAGS.SILENT (store command data item) ......... 34 + FROM (search key) ................................. 27 + FULL (fetch item) .......................................... 31 + HEADER (search key) .................. 27 + INTERNALDATE (fetch item) .................................. 31 + INTERNALDATE (fetch result) ................................ 50 + KEYWORD (search key) ................................ 27 + LARGER (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) .............................. 28 + OK (response) .............................................. 40 + OLD (search key) ........................................... 28 + ON (search key) ..................................... 28 + OR (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 (fetch item) ............. 31 + RFC822.HEADER.LINES.NOT (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 (search key) ............................. 28 + SENTON (search key) ................................. 28 + SENTSINCE (search key) .............................. 28 + SINCE (search key) .................................. 28 + SMALLER (search key) ................................... 28 + STORE (command) ............................................ 33 + STORE (response) ........................................... 69 + SUBJECT (search key) .............................. 28 + SUBSCRIBE (command) ........................................ 19 + SUBSCRIBE MAILBOX (command) ................................ 66 + TEXT (search key) ................................. 28 + TO (search key) ................................... 28 + TRYCREATE (response code) .................................. 39 + UID (command) .............................................. 35 + UID (fetch item) ........................................... 32 + UID (fetch result) ......................................... 51 + UID (search key) ............................. 28 + UIDVALIDITY (response code) ................................ 40 + UNANSWERED (search key) .................................... 29 + UNDELETED (search key) ..................................... 29 + UNDRAFT (search key) ....................................... 29 + UNFLAGGED (search key) ..................................... 29 + UNKEYWORD (search key) .............................. 29 + UNSEEN (response code) ..................................... 40 + UNSEEN (search key) ........................................ 29 + UNSUBSCRIBE (command) ...................................... 19 + UNSUBSCRIBE MAILBOX (command) .............................. 66 + X (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 ::= + + 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 ::= + + continue_req ::= "+" SPACE base64 CRLF + + CR ::= + + CRLF ::= CR LF + + CTL ::= + + + + +Myers [Page 4] + +RFC 1734 POP3 AUTH December 1994 + + + LF ::= + + SPACE ::= + + TAB ::= + + + +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: + C: + 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: SIZE=500000 + S: 250 Address Ok. + C: RCPT TO: + S: 250 ned@innosoft.com OK; can accomodate 500000 byte message + C: RCPT TO: + S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU + C: RCPT TO: + 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 + . Requests to subscribe to the mailing + list should be addressed to . + 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: RET=HDRS ENVID=QQ314159 +<<< 250 sender ok +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 recipient ok + + + +Moore Standards Track [Page 23] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Eric@Bombs.AF.MIL +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=NEVER +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 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: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: 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: RET=HDRS ENVID=QQ314159 +<<< 250 ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 550 error - no such recipient +>>> RCPT TO: 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: +<<< 250 ok +>>> RCPT TO: +<<< 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: +<<< 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: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: 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: 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 + . Requests to subscribe to the mailing + list should be addressed to . + 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 | ". + + 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 |") (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 . + +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 + Message-Id: <199407072116.RAA14128@CS.UTK.EDU> + Subject: Returned mail: Cannot send message for 5 days + To: + 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 ----- + (unrecoverable error) + + ----- Transcript of session follows ----- + ... 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 + Subject: Returned mail: User unknown + To: + 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 ----- + (unrecoverable error) + (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 + 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: + Message-Id: <199407092338.TAA23293@CS.UTK.EDU> + Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk + id ; + 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- + + 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: + 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: + 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: + + + + 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: + C: + 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: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + +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 [
]<> + 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[
]<> An alternate form of + BODY[
] 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 + 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 + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS + 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 + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS + 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 + 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 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[
]<> + 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 + "") + 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 +S: Subject: IMAP4rev1 WG mtg summary and minutes +S: To: imap@cac.washington.edu +S: cc: minutes@CNRI.Reston.VA.US, John Klensin +S: Message-Id: +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 ::= + +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 ::= + +CHAR8 ::= + +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 ::= + +create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + +CRLF ::= CR LF + +CTL ::= + +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 ::= + +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 + "(" # 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 ::= / + "\" 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*] + +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 ::= + +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* + +text ::= 1*TEXT_CHAR + + + +Crispin Standards Track [Page 73] + +RFC 2060 IMAP4rev1 December 1996 + + +text_mime2 ::= "=?" "?" "?" + "?=" + ;; Syntax defined in [MIME-HDRS] + +TEXT_CHAR ::= + +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 + +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 (store command data item) ............... 45 + +FLAGS.SILENT (store command data item) ........ 46 + -FLAGS (store command data item) ............... 46 + -FLAGS.SILENT (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 (search key) .................................. 38 + BEFORE (search key) ................................. 39 + + + +Crispin Standards Track [Page 79] + +RFC 2060 IMAP4rev1 December 1996 + + + BODY (fetch item) .......................................... 41 + BODY (fetch result) ........................................ 58 + BODY (search key) ................................. 39 + BODY.PEEK[
]<> (fetch item) ............... 44 + BODYSTRUCTURE (fetch item) ................................. 44 + BODYSTRUCTURE (fetch result) ............................... 59 + BODY[
]<> (fetch result) ............. 58 + BODY[
]<> (fetch item) .................... 41 + BYE (response) ............................................. 52 + Body Structure (message attribute) ......................... 11 + CAPABILITY (command) ....................................... 18 + CAPABILITY (response) ...................................... 53 + CC (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 (store command data item) ................ 45 + FLAGS.SILENT (store command data item) ......... 45 + FROM (search key) ................................. 39 + FULL (fetch item) .......................................... 44 + Flags (message attribute) .................................. 9 + HEADER (part specifier) .................................... 41 + HEADER (search key) .................. 39 + HEADER.FIELDS (part specifier) ............... 41 + HEADER.FIELDS.NOT (part specifier) ........... 41 + INTERNALDATE (fetch item) .................................. 44 + INTERNALDATE (fetch result) ................................ 62 + Internal Date (message attribute) .......................... 10 + KEYWORD (search key) ................................ 39 + Keyword (type of flag) ..................................... 10 + + + +Crispin Standards Track [Page 80] + +RFC 2060 IMAP4rev1 December 1996 + + + LARGER (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) .............................. 39 + OK (response) .............................................. 51 + OLD (search key) ........................................... 39 + ON (search key) ..................................... 39 + OPTIONAL (specification requirement term) .................. 5 + OR (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 (search key) ............................. 40 + SENTON (search key) ................................. 40 + + + +Crispin Standards Track [Page 81] + +RFC 2060 IMAP4rev1 December 1996 + + + SENTSINCE (search key) .............................. 40 + SHOULD (specification requirement term) .................... 5 + SHOULD NOT (specification requirement term) ................ 5 + SINCE (search key) .................................. 40 + SMALLER (search key) ................................... 40 + STATUS (command) ........................................... 33 + STATUS (response) .......................................... 55 + STORE (command) ............................................ 45 + SUBJECT (search key) .............................. 40 + SUBSCRIBE (command) ........................................ 29 + Session Flag (class of flag) ............................... 10 + System Flag (type of flag) ................................. 9 + TEXT (part specifier) ...................................... 42 + TEXT (search key) ................................. 40 + TO (search key) ................................... 40 + TRYCREATE (response code) .................................. 51 + UID (command) .............................................. 47 + UID (fetch item) ........................................... 44 + UID (fetch result) ......................................... 63 + UID (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 (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 (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[
], 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: + 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 + Functionally equivalent to BODY.PEEK[HEADER.LINES + ], 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 + Functionally equivalent to + BODY.PEEK[HEADER.LINES.NOT ], + 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, . To subscribe, send a message + containing SUBSCRIBE to . + + + + +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 + 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: 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, + . To subscribe, send a message to + 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: + C: 250 OK + P: RCPT TO: + 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, "" or "". 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., + "" is an instance of (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 + contains the source mailbox. + + MAIL FROM: + + 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 can contain more than just a mailbox. The + is a reverse source routing list of hosts and + source mailbox. The first host in the should be + the host sending this command. + + The second step in the procedure is the RCPT command. + + RCPT TO: + + 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 can contain more than just a mailbox. The + is a source routing list of hosts and the + destination mailbox. The first host in the + should be the host receiving this command. + + The third step in the procedure is the DATA command. + + DATA + + 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: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + 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 + 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 + + 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 + + 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: + R: 251 User not local; will forward to + + Or + + S: RCPT TO: + R: 551 User not local; please try + + 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 + + Or + + S: VRFY Smith + R: 251 User not local; will forward to + + Or + + S: VRFY Jones + R: 550 String does not match anything. + + Or + + S: VRFY Jones + R: 551 User not local; please try + + 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 + R: 250-Fred Fonebone + R: 250-Sam Q. Smith + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + 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 FROM: + + 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 FROM: + + 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 FROM: + + 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 + + QUIT + + In the HELO command the host sending the command identifies + itself; the command may be interpreted as saying "Hello, I am + ". + + ------------------------------------------------------------- + + 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 . The command codes themselves are + alphabetic characters terminated by if parameters follow + and 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: + 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 "." (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 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 . 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 + + MAIL FROM: + + RCPT TO: + + DATA + + RSET + + SEND FROM: + + SOML FROM: + + SAML FROM: + + VRFY + + EXPN + + HELP [ ] + + NOOP + + QUIT + + TURN + + + + + + + + + + + + + + + + + + + + +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. + + ::= + + ::= + + ::= "<" [ ":" ] ">" + + ::= | "," + + ::= "@" + + ::= | "." + + ::= | "#" | "[" "]" + + ::= "@" + + ::= | + + ::= + + ::= | + + ::= | + + ::= | | "-" + + ::= | "." + + ::= | + + ::= """ """ + + ::= "\" | "\" | | + + ::= | "\" + + ::= "." "." "." + + ::= | + + ::= + + + + +[Page 30] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the carriage return character (ASCII code 13) + + ::= the line feed character (ASCII code 10) + + ::= the space character (ASCII code 32) + + ::= one, two, or three digits representing a decimal + integer value in the range 0 through 255 + + ::= any one of the 52 alphabetic characters A through Z + in upper case and a through z in lower case + + ::= any one of the 128 ASCII characters, but not any + or + + ::= any one of the ten digits 0 through 9 + + ::= any one of the 128 ASCII characters except , + , quote ("), or backslash (\) + + ::= any one of the 128 ASCII characters (no exceptions) + + ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." + | "," | ";" | ":" | "@" """ | 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:" + + ::= "Received:" + + ::= ";" + + + ::= "FROM" + + ::= "BY" + + ::= [] [] [] [] + + ::= "VIA" + + ::= "WITH" + + ::= "ID" + + ::= "FOR" + + ::= The standard names for links are registered with + the Network Information Center. + + ::= The standard names for protocols are + registered with the Network Information Center. + + ::=
::= the one or two decimal integer day of the month in + the range 1 to 31. + + ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + ::= 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 + + + + ::= the two decimal integer hour of the day in the + range 00 to 24. + + ::= the two decimal integer minute of the hour in the + range 00 to 59. + + ::= the two decimal integer second of the minute in the + range 00 to 59. + + ::= "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, , + one line of text, and , 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 Service ready + 221 Service closing transmission channel + 421 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 + 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 + 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 . + 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 Service ready + 221 Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to + + 354 Start mail input; end with . + + 421 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 + 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 USC-ISIF.ARPA Service ready + + 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 "." 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 is 512 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the 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 + 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 , optionally some text, and . + + 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 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: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + 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: + 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 . + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + 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: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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 + 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 + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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 + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 450 User not active now + + S: RSET + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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 + + S: SOML FROM: + R: 250 OK + + S: RCPT TO: + R: 250 User not active now, so will do mail. + + S: DATA + R: 354 Start mail input; end with . + 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- + R: 250-Fred Fonebone + R: 250-Xenon Y. Zither + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + 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 + R: 250- + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + 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: + 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 . + 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: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: DATA + R: 354 Start mail input; end with . + 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: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + 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: + R: 250 OK + + S: RCPT TO: + R: OK + + S: DATA + R: 354 Start mail input; end with . + 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: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + 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 . + + 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. + + + + The characters carriage return and line feed (in that order). + + + + 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 "". + 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: + + *element + + indicating at least and at most 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 + + "(element)" is equivalent to "*(element)"; that is, + exactly 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: + + #element + + indicating at least and at most 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" , JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" , + JJV@BBN + + and + + To: "Joe & J. Harvey" + , JJV + @BBN + + and + + To: "Joe & + J. Harvey" , 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 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 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 s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + 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* + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 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 = ; ( 0-177, 0.-127.) + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = ; ( 60- 71, 48.- 57.) + CTL = ; ( 177, 127.) + CR = ; ( 15, 13.) + LF = ; ( 12, 10.) + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) + <"> = ; ( 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 = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1* + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = , ; => 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 = may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = 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 . 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 , 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 = + + + user-defined-field = + + + 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 parameter indicates the + software used to encrypt the body, and the second, optional + 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 + 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 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
+ 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 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 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 + + 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" + + 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 , + 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 + + 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 + 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 + 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 + 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 + 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 + Sender: Secy-Name + 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 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 + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones , + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood , + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "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: , 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* + + 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 and 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 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 = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1* + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = ; ( 15, 13.) + CRLF = CR LF + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = ; ( 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 = ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + + + + 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 = + + field-name = 1* + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = ; ( 11, 9.) + LF = ; ( 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 = , ; => 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 = ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = 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 = + + 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; + <"> = ; ( 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 + + = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 + + = A | B | C | ... | Z + a | b | c | ... | z + + = ! | " | # | $ | % | & | ' | ( | ) | * | + + | , | - | / | : | < | = | > | ? | @ | + [ | ] | ^ | _ | ` | { | | | } | ~ + + = \ + + = any one of the 128 ASCII codes + + = carriage return, code 10 + + = line feed, code 13 + + = space, code 32 + + = + + = | | | + + = | + + = | + + = | + + = | + + = | | - + + = | + + = [ [ ] ] + + = | . + + = + + = + + = + + = | + + +Butler, et. al. [Page 15] + + + +RFC 937 February 1985 +Post Office Protocol + + + = HELO + + = FOLD + + = READ [ ] + + = RETR + + = ACKS + + = ACKD + + = NACK + + = QUIT + + = + [ ] + + = - [ ] + + = # [ ] + + = + POP2 [ ] + + = = [ ] + + = | | | | + | | | + + = | | | | + + + + + + + + + + + + + + + + + + + + +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 + + 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 article retrieved - head and body follow + (n = article number, = message-id) + 221 n article retrieved - head follows + 222 n article retrieved - body follows + 223 n 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 + + The IHAVE command informs the server that the client has an article + whose id is . 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 . + 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 is the name of the newsgroup, is the number of + the last known article currently in that newsgroup, is the + number of the first article currently in the newsgroup, and

is + either 'y' or 'n' indicating whether posting to this newsgroup is + allowed ('y') or prohibited ('n'). + + The and fields will always be numeric. They may have + leading zeros. If the field evaluates to less than the + 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] [] + + A list of newsgroups created since 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] [] + + 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. and + all mod. EXCEPT mod.map. 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 . + 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! 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 article retrieved - head and body follow 221 n article + retrieved - head follows + 222 n article retrieved - body follows + 223 n 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 . + 340 send article to be posted. End with . + + 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] + -- cgit v1.2.3