diff options
Diffstat (limited to 'RFC')
37 files changed, 0 insertions, 53635 deletions
diff --git a/RFC/draft-klensin-cram-03.txt b/RFC/draft-klensin-cram-03.txt deleted file mode 100644 index bfac1d5b..00000000 --- a/RFC/draft-klensin-cram-03.txt +++ /dev/null @@ -1,261 +0,0 @@ -
-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 deleted file mode 100644 index 680556e8..00000000 --- a/RFC/draft-newman-tls-imappop-05.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - - - -Network Working Group C. Newman -Internet Draft: Using TLS with IMAP4, POP3 and ACAP Innosoft -Document: draft-newman-tls-imappop-05.txt November 1998 - - - Using TLS with IMAP4, POP3 and ACAP - - -Status of this memo - - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - To view the entire list of current Internet-Drafts, please check - the "1id-abstracts.txt" listing contained in the Internet-Drafts - Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net - (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au - (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US - West Coast). - -Abstract - - This specification defines extensions to IMAP [IMAP4], POP [POP3] - and ACAP [ACAP] which activate TLS [TLS]. This also defines a - simple PLAIN SASL [SASL] mechanism for use underneath strong TLS - encryption with ACAP or other protocols lacking a clear-text login - command. - -1. Motivation - - The TLS protocol [TLS] (formerly known as SSL) provides a way to - secure a TCP connection from tampering and eavesdropping. - Obviously, the option of using such security is desirable for IMAP - [IMAP4], POP [POP3] and ACAP [ACAP]. Although advanced SASL [SASL] - authentication mechanisms can provide a lightweight version of this - service, TLS is a full service security layer and is complimentary - to simple authentication-only SASL mechanisms or clear-text - password login commands. Furthermore, many sites have a high - investment in authentication infrastructure (e.g., a large database - of a one-way-function applied to user passwords), so a privacy - - - -Newman [Page 1] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - layer which is not tightly bound to user authentication can protect - against network eavesdropping attacks without requiring a new - authentication infrastructure and/or forcing all users to change - their password. - -1.1. Conventions Used in this Document - - The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD - NOT", "MAY", and "OPTIONAL" in this document are to be interpreted - as described in "Key words for use in RFCs to Indicate Requirement - Levels" [KEYWORDS]. - - Formal syntax is defined using ABNF [ABNF]. - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - -2. Basic Interoperability and Security Requirements - - The following requirements apply to all implementations of the - STARTTLS extension for IMAP4, POP3 and ACAP. - -2.1. Cipher Suite Requirements - - Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher - suite is REQUIRED. This is important as it assures that any two - compliant implementations can be configured to interoperate. - - All other cipher suites are OPTIONAL. - -2.2. TLS Operational Mode Security Requirements - - Both clients and servers SHOULD have an operational mode where use - of TLS encryption is required to login. Clients MAY have an - operational mode where TLS is used only when advertised by the - server, but login occurs regardless. For backwards compatibility, - servers SHOULD have an operational mode which permits clients to - login when TLS is not used. - -2.3. Clear-Text Password Requirement - - A server which implements both STARTTLS and a clear-text password - authentication mechanism (including but not limited to the IMAP4 - LOGIN command, POP3 PASS command and the PLAIN mechanism in section - 6) MUST have an operational mode where all clear-text login - commands and mechanisms are disabled unless TLS encryption is - active. - - - - -Newman [Page 2] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - -2.4. Server Identity Check - - During the TLS negotiation, the client MUST check its understanding - of the server hostname against the server's identity as presented - in the server Certificate message, in order to prevent - man-in-the-middle attacks. Matching is performed according to - these rules: - - o The client MUST use the server hostname it used to open the - connection as the value to compare against the server name as - expressed in the server certificate. The client MUST NOT use - any form of the server hostname derived from an insecure remote - source (e.g., insecure DNS reverse lookup). - - o If a subjectAltName extension of type dNSName is present in the - certificate, it SHOULD be used as the source of the server's - identity. - - o Matching is case-insensitive. - - o A "*" wildcard character MAY be used as the left-most name - component in the certificate. For example, *.example.com would - match a.example.com, foo.example.com, etc. but would not match - example.com. - - o If the certificate contains multiple names (e.g. more than one - dNSName field), then a match with any one of the fields is - considered acceptable. - - If the match fails, the client SHOULD either ask for explicit user - confirmation, or terminate the connection and indicate the server's - identity is suspect. - -3. IMAP4 STARTTLS extension - - When the TLS extension is present in IMAP4, "STARTTLS" is listed as - a capability in response to the CAPABILITY command. This extension - adds a single command, "STARTTLS" to the IMAP4 protocol which is - used to begin a TLS negotiation. - -3.1. STARTTLS Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - begin TLS negotiation - NO - security layer already active - - - -Newman [Page 3] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - BAD - command unknown or arguments invalid - - A TLS negotiation begins immediately after the CRLF at the end of - the tagged OK response from the server. Once a client issues a - STARTTLS command, it MUST NOT issue further commands until a - server response is seen and the TLS negotiation is complete. - - The STARTTLS command is only valid in non-authenticated state. - The server remains in non-authenticated state, even if client - credentials are supplied during the TLS negotiation. The SASL - [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS - client credentials are successfully exchanged, but servers - supporting the STARTTLS command are not required to support the - EXTERNAL mechanism. - - Once TLS has been started, the client SHOULD discard cached - information about server capabilities and re-issue the CAPABILITY - command. This is necessary to protect against man-in-the-middle - attacks which alter the capabilities list prior to STARTTLS. The - server MAY advertise different capabilities after STARTTLS. - - The formal syntax for IMAP4 is amended as follows: - - command_any =/ "STARTTLS" - - Example: C: a001 CAPABILITY - S: * CAPABILITY IMAP4rev1 STARTTLS - S: a001 OK CAPABILITY completed - C: a002 STARTTLS - S: a002 OK Begin TLS negotiation now - <TLS negotiation, further commands are under TLS layer> - C: a003 CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL - S: a003 OK CAPABILITY completed - C: a004 LOGIN joe password - S: a004 OK LOGIN completed - -4. POP3 STARTTLS extension - - The POP3 STARTTLS extension adds the STLS command to POP3 servers. - If this is implemented, the POP3 extension mechanism [POP3EXT] MUST - also be implemented to avoid the need for client probing of multiple - commands. The capability name "STLS" indicates this command is - present. - - STLS - - Arguments: none - - - -Newman [Page 4] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - Restrictions: - Only permitted in AUTHORIZATION state. - - Discussion: - A TLS negotiation begins immediately after the CRLF at the - end of the +OK response from the server. A -ERR response - MAY result if a security layer is already active. Once a - client issues a STLS command, it MUST NOT issue further - commands until a server response is seen and the TLS - negotiation is complete. - - The STLS command is only permitted in AUTHORIZATION state - and the server remains in AUTHORIZATION state, even if - client credentials are supplied during the TLS negotiation. - The AUTH command [POP-AUTH] with the EXTERNAL mechanism - [SASL] MAY be used to authenticate once TLS client - credentials are successfully exchanged, but servers - supporting the STLS command are not required to support the - EXTERNAL mechanism. - - Once TLS has been started, the client SHOULD discard cached - information about server capabilities and re-issue the CAPA - command. This is necessary to protect against - man-in-the-middle attacks which alter the capabilities list - prior to STLS. The server MAY advertise different - capabilities after STLS. - - Possible Responses: - +OK -ERR - - Examples: - C: STLS - S: +OK Begin TLS negotiation - <TLS negotiation, further commands are under TLS layer> - ... - C: STLS - S: -ERR Security Layer already active - -5. ACAP STARTTLS extension - - When the TLS extension is present in ACAP, "STARTTLS" is listed as - a capability in the ACAP greeting. No arguments to this capability - are defined at this time. This extension adds a single command, - "STARTTLS" to the ACAP protocol which is used to begin a TLS - negotiation. - - - - - - -Newman [Page 5] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - -5.1. STARTTLS Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - begin TLS negotiation - NO - security layer already active - BAD - command unknown or arguments invalid - - A TLS negotiation begins immediately after the CRLF at the end of - the tagged OK response from the server. Once a client issues a - STARTTLS command, it MUST NOT issue further commands until a - server response is seen and the TLS negotiation is complete. - - The STARTTLS command is only valid in non-authenticated state. - The server remains in non-authenticated state, even if client - credentials are supplied during the TLS negotiation. The SASL - [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS - client credentials are successfully exchanged, but servers - supporting the STARTTLS command are not required to support the - EXTERNAL mechanism. - - After the TLS layer is established, the server MUST re-issue an - untagged ACAP greeting. This is necessary to protect against - man-in-the-middle attacks which alter the capabilities list prior - to STARTTLS. The client SHOULD discard cached capability - information and replace it with the information from the new ACAP - greeting. The server MAY advertise different capabilities after - STARTTLS. - - The formal syntax for ACAP is amended as follows: - - command_any =/ "STARTTLS" - - Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) - C: a002 STARTTLS - S: a002 OK "Begin TLS negotiation now" - <TLS negotiation, further commands are under TLS layer> - S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") - -6. PLAIN SASL mechanism - - Clear-text passwords are simple, interoperate with almost all - existing operating system authentication databases, and are useful - for a smooth transition to a more secure password-based - authentication mechanism. The drawback is that they are - unacceptable for use over an unencrypted network connection. - - - -Newman [Page 6] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - This defines the "PLAIN" SASL mechanism for use with ACAP and other - protocols with no clear-text login command. This MUST NOT be - implemented unless strong TLS encryption or an equivalent strong - encryption layer is also implemented. - - The mechanism consists of a single message from the client to the - server. The client sends the authorization identity (identity to - login as), followed by a US-ASCII NUL character, followed by the - authentication identity (identity whose password will be used), - followed by a US-ASCII NUL character, followed by the clear-text - password. The client may leave the authorization identity empty to - indicate that it is the same as the authentication identity. - - The server will verify the authentication identity and password - with the system authentication database and verify that the - authentication credentials permit the client to login as the - authorization identity. If both steps succeed, the user is logged - in. - - The server MAY also use the password to initialize any new - authentication database, such as one suitable for CRAM-MD5 - [CRAM-MD5]. - - Non-US-ASCII characters are permitted as long as they are - represented in UTF-8 [UTF-8]. Use of non-visible characters or - characters which a user may be unable to enter on some keyboards is - discouraged. - - Clients are encouraged to support pure-binary passwords as they may - be safe from dictionary attacks. However, if the client offers a - character-based interface for password entry it MUST use UTF-8 - encoding for the characters. - - The formal grammar for the client message using Augmented BNF - [ABNF] follows. - - message = [authorize-id] NUL authenticate-id NUL password - authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets - authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets - password = *NZ-OCTET ; MUST accept up to 255 octets - NUL = %x00 - NZ-OCTET = %x01-FF ; all non-NUL octet values - UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / - UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 - UTF8-1 = %x80-BF - UTF8-2 = %xC0-DF UTF8-1 - UTF8-3 = %xE0-EF 2UTF8-1 - UTF8-4 = %xF0-F7 3UTF8-1 - - - -Newman [Page 7] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - UTF8-5 = %xF8-FB 4UTF8-1 - UTF8-6 = %xFC-FD 5UTF8-1 - - Here is an example of how this might be used to initialize a - CRAM-MD5 authentication database for ACAP: - - Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) - C: a001 AUTHENTICATE "CRAM-MD5" - S: + "<1896.697170952@postoffice.reston.mci.net>" - C: "tim b913a602c7eda7a495b4e6e7334d3890" - S: a001 NO (TRANSITION-NEEDED) - "Please change your password, or use TLS to login" - C: a002 STARTTLS - S: a002 OK "Begin TLS negotiation now" - <TLS negotiation, further commands are under TLS layer> - S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") - C: a003 AUTHENTICATE "PLAIN" {21+} - C: <NUL>tim<NUL>tanstaaftanstaaf - S: a003 OK CRAM-MD5 password initialized - - Note: In this example, <NUL> represents a single ASCII NUL octet. - - Here is an example session where a client erroneously attempts to - use PLAIN prior to starting TLS: - - Example: S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS) - C: a001 AUTHENTICATE "PLAIN" {21} - S: a001 NO (ENCRYPT-NEEDED) - "Can't use PLAIN without encryption" - -7. imaps and pop3s ports - - The common practice of using a separate port for a "secure" version - of each protocol has a number of disadvantages in the IMAP [IMAP4], - ACAP [ACAP] and POP [POP3] environment. Rather than using the best - security available, it means that clients have to be explicitly - configured to use the separate secure port or suffer the - performance loss of probing for active ports. Furthermore this is - even more serious as it would require a new URL scheme which could - only be resolved by TLS-enabled clients. - - Separate "imaps" and "pop3s" ports were registered for use with - TLS. Use of these ports is discouraged in favor of the STARTTLS or - STLS command. - - One of the arguments used in favor of the separate port technique - is that it simplifies configuration of firewalls which filter by IP - port. However, a quality server implementation running on the - - - -Newman [Page 8] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - standard port can be configured to require use of the STARTTLS - command or a suitably strong SASL mechanism for non-local - connections. This provides superior functionality as the client - need not be re-configured for use outside the firewall and faster - non-clear-text SASL mechanisms may be acceptable to many sites for - non-local connections. - -8. IANA Considerations - - This document constitutes registration of the "STARTTLS" IMAP4 - capability as required by section 7.2.1 of RFC 2060. - - This document defines the "STLS" POP3 capability as follows: - - CAPA tag: STLS - Arguments: none - Added commands: STLS - Standard commands affected: May enable USER/PASS as a side-effect. - CAPA command should be re-issued after successful completion. - Announced states/Valid states: AUTHORIZATION state only. - Specification reference: this memo - - This document defines the "STARTTLS" ACAP capability as follows: - - Capability name: STARTTLS - Capability keyword: STARTTLS - Capability arguments: none - Published Specification(s): this memo - Person and email address for further information: - see author's address section below - - This document defines the "PLAIN" SASL mechanism as follows: - - SASL mechanism name: PLAIN - Security Considerations: See section 9 of this memo - Published specification: this memo - Person & email address to contact for further information: - see author's address section below - Intended usage: COMMON - Author/Change controller: see author's address section below - -9. Security Considerations - - TLS only provides protection for data sent over a network - connection. Messages transferred over IMAP or POP3 are still - available to server administrators and usually subject to - eavesdropping, tampering and forgery when transmitted through SMTP - or NNTP. TLS is no substitute for an end-to-end message security - - - -Newman [Page 9] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - mechanism using MIME security multiparts [MIME-SEC]. - - An active attacker can remove STARTTLS from the capability list. - In order to detect such an attack, clients SHOULD either warn the - user when session privacy is not active, or be configurable to - refuse to proceed without an acceptable level of security. - - Both client and server MUST verify the level of protection - negotiated by TLS is adequate for local security policy, and - terminate the TCP connection if it is not. An active attacker can - always cause a down-negotiation to the weakest authentication - mechanism or cipher suite available. For this reason, - implementations need to be configurable to refuse weak mechanisms - or cipher suites. - - Any protocol interactions prior to the TLS handshake are performed - in the clear and can be modified by an active attacker. For this - reason, clients SHOULD discard cached information about server - capabilities advertised prior to the start of the TLS handshake. - - Clients are encouraged to clearly distinguish between a level of - encryption known to be vulnerable to a reasonable attack using - modern hardware (such as encryption with a 40-bit key) and one - which is believed to be safe from such an attack. - - When the PLAIN mechanism (or the IMAP4 LOGIN or POP3 PASS command) - is used, the server gains the ability to impersonate the user to - all services with the same password regardless of any encryption - provided by TLS or other network privacy mechanisms. Stronger SASL - authentication mechanisms such as Kerberos address this issue. - - Use of clear-text login mechanisms (e.g., the IMAP4 LOGIN command, - POP3 PASS command or the PLAIN mechanism) without a suitable - encryption layer such as that provided by TLS expose the user's - password to a common network eavesdropping attack. Therefore, the - PLAIN mechanism MUST NOT be implemented unless a suitable - encryption layer, such as that provided by TLS is also implemented. - - Additional security requirements are discussed in section 2. - -10. References - - [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: - ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, - November 1997. - - [ACAP] Newman, Myers, "ACAP -- Application Configuration Access - Protocol", RFC 2244, Innosoft, Netscape, November 1997. - - - -Newman [Page 10] - -Internet Draft Using TLS with IMAP4, POP3 and ACAP November 1998 - - - [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension - for Simple Challenge/Response", RFC 2195, MCI, September 1997. - - [IMAP4] Crispin, M., "Internet Message Access Protocol - Version - 4rev1", RFC 2060, University of Washington, December 1996. - - [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, - Carnegie-Mellon University, December 1994. - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, Harvard University, March 1997. - - [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for - MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted - Information Systems, CyberCash, Innosoft International, October - 1995. - - [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC - 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. - - [POP3EXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism", - Work in progress. - - [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, - Carnegie Mellon, December 1994. - - [SASL] Myers, J., "Simple Authentication and Security Layer - (SASL)", RFC 2222, Netscape Communications, October 1997. - - [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in - progress. - - [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", - RFC 2279, Alis Technologies, January 1998. - -11. Author's Address - - Chris Newman - Innosoft International, Inc. - 1050 Lakes Drive - West Covina, CA 91790 USA - - Email: chris.newman@innosoft.com - - - - - - - - -Newman [Page 11] diff --git a/RFC/lan-mail-protocols b/RFC/lan-mail-protocols deleted file mode 100644 index 13e984ee..00000000 --- a/RFC/lan-mail-protocols +++ /dev/null @@ -1,1330 +0,0 @@ - - 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 deleted file mode 100644 index c21d6e48..00000000 --- a/RFC/rfc1081.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group M. Rose -Request for Comments: 1081 TWG - November 1988 - - Post Office Protocol - Version 3 - - -Status of this Memo - - This memo suggests a simple method for workstations to dynamically - access mail from a mailbox server. This RFC specifies a proposed - protocol for the Internet community, and requests discussion and - suggestions for improvements. Distribution of this memo is - unlimited. - - This memo is based on RFC 918 (since revised as RFC 937). Although - similar in form to the original Post Office Protocol (POP) proposed - for the Internet community, the protocol discussed in this memo is - similar in spirit to the ideas investigated by the MZnet project at - the University of California, Irvine. - - Further, substantial work was done on examining POP in a PC-based - environment. This work, which resulted in additional functionality - in this protocol, was performed by the ACIS Networking Systems Group - at Stanford University. The author gratefully acknowledges their - interest. - -Introduction - - On certain types of smaller nodes in the Internet it is often - impractical to maintain a message transport system (MTS). For - example, a workstation may not have sufficient resources (cycles, - disk space) in order to permit a SMTP server and associated local - mail delivery system to be kept resident and continuously running. - Similarly, it may be expensive (or impossible) to keep a personal - computer interconnected to an IP-style network for long amounts of - time (the node is lacking the resource known as "connectivity"). - - Despite this, it is often very useful to be able to manage mail on - these smaller nodes, and they often support a user agent (UA) to aid - the tasks of mail handling. To solve this problem, a node which can - support an MTS entity offers a maildrop service to these less endowed - nodes. The Post Office Protocol - Version 3 (POP3) is intended to - permit a workstation to dynamically access a maildrop on a server - host in a useful fashion. Usually, this means that the POP3 is used - to allow a workstation to retrieve mail that the server is holding - for it. - - - - -Rose [Page 1] - -RFC 1081 POP3 November 1988 - - - For the remainder of this memo, the term "client host" refers to a - host making use of the POP3 service, while the term "server host" - refers to a host which offers the POP3 service. - -A Short Digression - - This memo does not specify how a client host enters mail into the - transport system, although a method consistent with the philosophy of - this memo is presented here: - - When the user agent on a client host wishes to enter a message - into the transport system, it establishes an SMTP connection to - its relay host (this relay host could be, but need not be, the - POP3 server host for the client host). - - If this method is followed, then the client host appears to the MTS - as a user agent, and should NOT be regarded as a "trusted" MTS entity - in any sense whatsoever. This concept, along with the role of the - POP3 as a part of a split-UA model is discussed later in this memo. - - Initially, the server host starts the POP3 service by listening on - TCP port 110. When a client host wishes to make use of the service, - it establishes a TCP connection with the server host. When the - connection is established, the POP3 server sends a greeting. The - client and POP3 server then exchange commands and responses - (respectively) until the connection is closed or aborted. - - Commands in the POP3 consist of a keyword possibly followed by an - argument. All commands are terminated by a CRLF pair. - - Responses in the POP3 consist of a success indicator and a keyword - possibly followed by additional information. All responses are - terminated by a CRLF pair. There are currently two success - indicators: positive ("+OK") and negative ("-ERR"). - - Responses to certain commands are multi-line. In these cases, which - are clearly indicated below, after sending the first line of the - response and a CRLF, any additional lines are sent, each terminated - by a CRLF pair. When all lines of the response have been sent, a - final line is sent, consisting of a termination octet (decimal code - 046, ".") and a CRLF pair. If any line of the multi-line response - begins with the termination octet, the line is "byte-stuffed" by - pre-pending the termination octet to that line of the response. - Hence a multi-line response is terminated with the five octets - "CRLF.CRLF". When examining a multi-line response, the client checks - to see if the line begins with the termination octet. If so and if - octets other than CRLF follow, the the first octet of the line (the - termination octet) is stripped away. If so and if CRLF immediately - - - -Rose [Page 2] - -RFC 1081 POP3 November 1988 - - - follows the termination character, then the response from the POP - server is ended and the line containing ".CRLF" is not considered - part of the multi-line response. - - A POP3 session progresses through a number of states during its - lifetime. Once the TCP connection has been opened and the POP3 - server has sent the greeting, the session enters the AUTHORIZATION - state. In this state, the client must identify itself to the POP3 - server. Once the client has successfully done this, the server - acquires resources associated with the client's maildrop, and the - session enters the TRANSACTION state. In this state, the client - requests actions on the part of the POP3 server. When the client has - finished its transactions, the session enters the UPDATE state. In - this state, the POP3 server releases any resources acquired during - the TRANSACTION state and says goodbye. The TCP connection is then - closed. - -The AUTHORIZATION State - - Once the TCP connection has been opened by a POP3 client, the POP3 - server issues a one line greeting. This can be any string terminated - by CRLF. An example might be: - - S. +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) - - Note that this greeting is a POP3 reply. The POP3 server should - always give a positive response as the greeting. - - The POP3 session is now in the AUTHORIZATION state. The client must - now issue the USER command. If the POP3 server responds with a - positive success indicator ("+OK"), then the client may issue either - the PASS command to complete the authorization, or the QUIT command - to terminate the POP3 session. If the POP3 server responds with a - negative success indicator ("-ERR") to the USER command, then the - client may either issue a new USER command or may issue the QUIT - command. - - When the client issues the PASS command, the POP3 server uses the - argument pair from the USER and PASS commands to determine if the - client should be given access to the appropriate maildrop. If so, - the POP3 server then acquires an exclusive-access lock on the - maildrop. If the lock is successfully acquired, the POP3 server - parses the maildrop into individual messages (read note below), - determines the last message (if any) present in the maildrop that was - referenced by the RETR command, and responds with a positive success - indicator. The POP3 session now enters the TRANSACTION state. If - the lock can not be acquired or the client should is denied access to - the appropriate maildrop or the maildrop can't be parsed for some - - - -Rose [Page 3] - -RFC 1081 POP3 November 1988 - - - reason, the POP3 server responds with a negative success indicator. - (If a lock was acquired but the POP3 server intends to respond with a - negative success indicator, the POP3 server must release the lock - prior to rejecting the command.) At this point, the client may - either issue a new USER command and start again, or the client may - issue the QUIT command. - - NOTE: Minimal implementations of the POP3 need only be - able to break a maildrop into its component messages; - they need NOT be able to parse individual messages. - More advanced implementations may wish to have this - capability, for reasons discussed later. - - After the POP3 server has parsed the maildrop into individual - messages, it assigns a message-id to each message, and notes the size - of the message in octets. The first message in the maildrop is - assigned a message-id of "1", the second is assigned "2", and so on, - so that the n'th message in a maildrop is assigned a message-id of - "n". In POP3 commands and responses, all message-id's and message - sizes are expressed in base-10 (i.e., decimal). - - It sets the "highest number accessed" to be that of the last message - referenced by the RETR command. - - Here are summaries for the three POP3 commands discussed thus far: - - USER name - Arguments: a server specific user-id (required) - Restrictions: may only be given in the AUTHORIZATION - state after the POP3 greeting or after an - unsuccessful USER or PASS command - Possible Responses: - +OK name is welcome here - -ERR never heard of name - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - ... - C: USER frated - S: -ERR sorry, frated doesn't get his mail here - - PASS string - Arguments: a server/user-id specific password (required) - Restrictions: may only be given in the AUTHORIZATION - state after a successful USER command - Possible Responses: - +OK maildrop locked and ready - -ERR invalid password - - - -Rose [Page 4] - -RFC 1081 POP3 November 1988 - - - -ERR unable to lock maildrop - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: +OK mrose's maildrop has 2 messages - (320 octets) - ... - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: -ERR unable to lock mrose's maildrop, file - already locked - - QUIT - Arguments: none - Restrictions: none - Possible Responses: - +OK - Examples: - C: QUIT - S: +OK dewey POP3 server signing off - - -The TRANSACTION State - - Once the client has successfully identified itself to the POP3 server - and the POP3 server has locked and burst the appropriate maildrop, - the POP3 session is now in the TRANSACTION state. The client may now - issue any of the following POP3 commands repeatedly. After each - command, the POP3 server issues a response. Eventually, the client - issues the QUIT command and the POP3 session enters the UPDATE state. - - Here are the POP3 commands valid in the TRANSACTION state: - - STAT - Arguments: none - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - The POP3 server issues a positive response with a line - containing information for the maildrop. This line is - called a "drop listing" for that maildrop. - - In order to simplify parsing, all POP3 servers are - required to use a certain format for drop listings. - The first octets present must indicate the number of - messages in the maildrop. Following this is the size - - - -Rose [Page 5] - -RFC 1081 POP3 November 1988 - - - of the maildrop in octets. This memo makes no - requirement on what follows the maildrop size. - Minimal implementations should just end that line of - the response with a CRLF pair. More advanced - implementations may include other information. - - NOTE: This memo STRONGLY discourages - implementations from supplying additional - information in the drop listing. Other, - optional, facilities are discussed later on - which permit the client to parse the messages - in the maildrop. - - Note that messages marked as deleted are not counted in - either total. - - Possible Responses: - +OK nn mm - Examples: - C: STAT - S: +OK 2 320 - - LIST [msg] - Arguments: a message-id (optionally) If a message-id is - given, it may NOT refer to a message marked as - deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If an argument was given and the POP3 server issues a - positive response with a line containing information - for that message. This line is called a "scan listing" - for that message. - - If no argument was given and the POP3 server issues a - positive response, then the response given is - multi-line. After the initial +OK, for each message - in the maildrop, the POP3 server responds with a line - containing information for that message. This line - is called a "scan listing" for that message. - - In order to simplify parsing, all POP3 servers are - required to use a certain format for scan listings. - The first octets present must be the message-id of - the message. Following the message-id is the size of - the message in octets. This memo makes no requirement - on what follows the message size in the scan listing. - Minimal implementations should just end that line of - - - -Rose [Page 6] - -RFC 1081 POP3 November 1988 - - - the response with a CRLF pair. More advanced - implementations may include other information, as - parsed from the message. - - NOTE: This memo STRONGLY discourages - implementations from supplying additional - information in the scan listing. Other, optional, - facilities are discussed later on which permit - the client to parse the messages in the maildrop. - - Note that messages marked as deleted are not listed. - - Possible Responses: - +OK scan listing follows - -ERR no such message - Examples: - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - ... - C: LIST 2 - S: +OK 2 200 - ... - C: LIST 3 - S: -ERR no such message, only 2 messages in - maildrop - - RETR msg - Arguments: a message-id (required) This message-id may - NOT refer to a message marked as deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If the POP3 server issues a positive response, then the - response given is multi-line. After the initial +OK, - the POP3 server sends the message corresponding to the - given message-id, being careful to byte-stuff the - termination character (as with all multi-line - responses). - - If the number associated with this message is higher - than the "highest number accessed" in the maildrop, the - POP3 server updates the "highest number accessed" to - the number associated with this message. - - - - - -Rose [Page 7] - -RFC 1081 POP3 November 1988 - - - Possible Responses: - +OK message follows - -ERR no such message - Examples: - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends the entire message here> - S: . - - DELE msg - Arguments: a message-id (required) This message-id - may NOT refer to a message marked as deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - The POP3 server marks the message as deleted. Any - future reference to the message-id associated with the - message in a POP3 command generates an error. The POP3 - server does not actually delete the message until the - POP3 session enters the UPDATE state. - - If the number associated with this message is higher - than the "highest number accessed" in the maildrop, - the POP3 server updates the "highest number accessed" - to the number associated with this message. - - Possible Responses: - +OK message deleted - -ERR no such message - Examples: - C: DELE 1 - S: +OK message 1 deleted - ... - C: DELE 2 - S: -ERR message 2 already deleted - - NOOP - Arguments: none - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - The POP3 server does nothing, it merely replies with a - positive response. - - Possible Responses: - +OK - - - - - -Rose [Page 8] - -RFC 1081 POP3 November 1988 - - - Examples: - C: NOOP - S: +OK - - LAST - Arguments: none - Restrictions: may only be issued in the TRANSACTION state. - Discussion: - - The POP3 server issues a positive response with a line - containing the highest message number which accessed. - Zero is returned in case no message in the maildrop has - been accessed during previous transactions. A client - may thereafter infer that messages, if any, numbered - greater than the response to the LAST command are - messages not yet accessed by the client. - - Possible Response: - +OK nn - - Examples: - C: STAT - S: +OK 4 320 - C: LAST - S: +OK 1 - C: RETR 3 - S: +OK 120 octets - S: <the POP3 server sends the entire message - here> - S: . - C: LAST - S: +OK 3 - C: DELE 2 - S: +OK message 2 deleted - C: LAST - S: +OK 3 - C: RSET - S: +OK - C: LAST - S: +OK 1 - - RSET - Arguments: none - Restrictions: may only be given in the TRANSACTION - state. - Discussion: - - If any messages have been marked as deleted by the POP3 - - - -Rose [Page 9] - -RFC 1081 POP3 November 1988 - - - server, they are unmarked. The POP3 server then - replies with a positive response. In addition, the - "highest number accessed" is also reset to the value - determined at the beginning of the POP3 session. - - Possible Responses: - +OK - Examples: - C: RSET - S: +OK maildrop has 2 messages (320 octets) - - - -The UPDATE State - - When the client issues the QUIT command from the TRANSACTION state, - the POP3 session enters the UPDATE state. (Note that if the client - issues the QUIT command from the AUTHORIZATION state, the POP3 - session terminates but does NOT enter the UPDATE state.) - - QUIT - Arguments: none - Restrictions: none - Discussion: - - The POP3 server removes all messages marked as deleted - from the maildrop. It then releases the - exclusive-access lock on the maildrop and replies as - to the success of - these operations. The TCP connection is then closed. - - Possible Responses: - +OK - Examples: - C: QUIT - S: +OK dewey POP3 server signing off (maildrop - empty) - ... - C: QUIT - S: +OK dewey POP3 server signing off (2 messages - left) - ... - - -Optional POP3 Commands - - The POP3 commands discussed above must be supported by all minimal - implementations of POP3 servers. - - - -Rose [Page 10] - -RFC 1081 POP3 November 1988 - - - The optional POP3 commands described below permit a POP3 client - greater freedom in message handling, while preserving a simple POP3 - server implementation. - - NOTE: This memo STRONGLY encourages implementations to - support these commands in lieu of developing augmented - drop and scan listings. In short, the philosophy of - this memo is to put intelligence in the part of the - POP3 client and not the POP3 server. - - TOP msg n - Arguments: a message-id (required) and a number. This - message-id may NOT refer to a message marked as - deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If the POP3 server issues a positive response, then - the response given is multi-line. After the initial - +OK, the POP3 server sends the headers of the message, - the blank line separating the headers from the body, - and then the number of lines indicated message's body, - being careful to byte-stuff the termination character - (as with all multi-line responses). - - Note that if the number of lines requested by the POP3 - client is greater than than the number of lines in the - body, then the POP3 server sends the entire message. - - Possible Responses: - +OK top of message follows - -ERR no such message - Examples: - C: TOP 10 - S: +OK - S: <the POP3 server sends the headers of the - message, a blank line, and the first 10 lines - of the body of the message> - S: . - ... - C: TOP 100 - S: -ERR no such message - - RPOP user - Arguments: a client specific user-id (required) - Restrictions: may only be given in the AUTHORIZATION - state after a successful USER command; in addition, - may only be given if the client used a reserved - - - -Rose [Page 11] - -RFC 1081 POP3 November 1988 - - - (privileged) TCP port to connect to the server. - Discussion: - - The RPOP command may be used instead of the PASS - command to authenticate access to the maildrop. In - order for this command to be successful, the POP3 - client must use a reserved TCP port (port < 1024) to - connect tothe server. The POP3 server uses the - argument pair from the USER and RPOP commands to - determine if the client should be given access to - the appropriate maildrop. Unlike the PASS command - however, the POP3 server considers if the remote user - specified by the RPOP command who resides on the POP3 - client host is allowed to access the maildrop for the - user specified by the USER command (e.g., on Berkeley - UNIX, the .rhosts mechanism is used). With the - exception of this differing in authentication, this - command is identical to the PASS command. - - Note that the use of this feature has allowed much wider - penetration into numerous hosts on local networks (and - sometimes remote networks) by those who gain illegal - access to computers by guessing passwords or otherwise - breaking into the system. - - Possible Responses: - +OK maildrop locked and ready - -ERR permission denied - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - C: RPOP mrose - S: +OK mrose's maildrop has 2 messages (320 - octets) - - Minimal POP3 Commands: - USER name valid in the AUTHORIZATION state - PASS string - QUIT - - STAT valid in the TRANSACTION state - LIST [msg] - RETR msg - DELE msg - NOOP - LAST - RSET - - - - -Rose [Page 12] - -RFC 1081 POP3 November 1988 - - - QUIT valid in the UPDATE state - - Optional POP3 Commands: - RPOP user valid in the AUTHORIZATION state - - TOP msg n valid in the TRANSACTION state - - POP3 Replies: - +OK - -ERR - - Note that with the exception of the STAT command, the reply given - by the POP3 server to any command is significant only to "+OK" - and "-ERR". Any text occurring after this reply may be ignored - by the client. - -Example POP3 Session - - S: <wait for connection on TCP port 110> - ... - C: <open connection> - S: +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: +OK mrose's maildrop has 2 messages (320 octets) - C: STAT - S: +OK 2 320 - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends message 1> - S: . - C: DELE 1 - S: +OK message 1 deleted - C: RETR 2 - S: +OK 200 octets - S: <the POP3 server sends message 2> - S: . - C: DELE 2 - S: +OK message 2 deleted - C: QUIT - - - - - -Rose [Page 13] - -RFC 1081 POP3 November 1988 - - - S: +OK dewey POP3 server signing off (maildrop empty) - C: <close connection> - S: <wait for next connection> - -Message Format - - All messages transmitted during a POP3 session are assumed to conform - to the standard for the format of Internet text messages [RFC822]. - - It is important to note that the byte count for a message on the - server host may differ from the octet count assigned to that message - due to local conventions for designating end-of-line. Usually, - during the AUTHORIZATION state of the POP3 session, the POP3 client - can calculate the size of each message in octets when it parses the - maildrop into messages. For example, if the POP3 server host - internally represents end-of-line as a single character, then the - POP3 server simply counts each occurrence of this character in a - message as two octets. Note that lines in the message which start - with the termination octet need not be counted twice, since the POP3 - client will remove all byte-stuffed termination characters when it - receives a multi-line response. - -The POP and the Split-UA model - - The underlying paradigm in which the POP3 functions is that of a - split-UA model. The POP3 client host, being a remote PC based - workstation, acts solely as a client to the message transport system. - It does not provide delivery/authentication services to others. - Hence, it is acting as a UA, on behalf of the person using the - workstation. Furthermore, the workstation uses SMTP to enter mail - into the MTS. - - In this sense, we have two UA functions which interface to the - message transport system: Posting (SMTP) and Retrieval (POP3). The - entity which supports this type of environment is called a split-UA - (since the user agent is split between two hosts which must - interoperate to provide these functions). - - ASIDE: Others might term this a remote-UA instead. - There are arguments supporting the use of both terms. - - This memo has explicitly referenced TCP as the underlying transport - agent for the POP3. This need not be the case. In the MZnet split- - UA, for example, personal micro-computer systems are used which do - not have IP-style networking capability. To connect to the POP3 - server host, a PC establishes a terminal connection using some simple - protocol (PhoneNet). A program on the PC drives the connection, - first establishing a login session as a normal user. The login shell - - - -Rose [Page 14] - -RFC 1081 POP3 November 1988 - - - for this pseudo-user is a program which drives the other half of the - terminal protocol and communicates with one of two servers. Although - MZnet can support several PCs, a single pseudo-user login is present - on the server host. The user-id and password for this pseudo-user - login is known to all members of MZnet. Hence, the first action of - the login shell, after starting the terminal protocol, is to demand a - USER/PASS authorization pair from the PC. This second level of - authorization is used to ascertain who is interacting with the MTS. - Although the server host is deemed to support a "trusted" MTS entity, - PCs in MZnet are not. Naturally, the USER/PASS authorization pair - for a PC is known only to the owner of the PC (in theory, at least). - - After successfully verifying the identity of the client, a modified - SMTP server is started, and the PC posts mail with the server host. - After the QUIT command is given to the SMTP server and it terminates, - a modified POP3 server is started, and the PC retrieves mail from the - server host. After the QUIT command is given to the POP3 server and - it terminates, the login shell for the pseudo-user terminates the - terminal protocol and logs the job out. The PC then closes the - terminal connection to the server host. - - The SMTP server used by MZnet is modified in the sense that it knows - that it's talking to a user agent and not a "trusted" entity in the - message transport system. Hence, it does performs the validation - activities normally performed by an entity in the MTS when it accepts - a message from a UA. - - The POP3 server used by MZnet is modified in the sense that it does - not require a USER/PASS combination before entering the TRANSACTION - state. The reason for this (of course) is that the PC has already - identified itself during the second-level authorization step - described above. - - NOTE: Truth in advertising laws require that the author - of this memo state that MZnet has not actually been - fully implemented. The concepts presented and proven - by the project led to the notion of the MZnet - split-slot model. This notion has inspired the - split-UA concept described in this memo, led to the - author's interest in the POP, and heavily influenced - the the description of the POP3 herein. - - In fact, some UAs present in the Internet already support the notion - of posting directly to an SMTP server and retrieving mail directly - from a POP server, even if the POP server and client resided on the - same host! - - ASIDE: this discussion raises an issue which this memo - - - -Rose [Page 15] - -RFC 1081 POP3 November 1988 - - - purposedly avoids: how does SMTP know that it's talking - to a "trusted" MTS entity? - -References - - [MZnet] Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail - Service for Personal Micro-Computer Systems", - Proceedings, IFIP 6.5 International Conference on - Computer Message Systems, Nottingham, U.K., May 1984. - - [RFC821] Postel, J., "Simple Mail Transfer Protocol", - USC/Information Sciences Institute, August 1982. - - [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet - Text Messages", University of Delaware, August 1982. - - [RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. - Reynolds, "Post Office Protocol - Version 2", RFC 937, - USC/Information Sciences Institute, February 1985. - - [RFC1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC - 1010, USC/Information Sciences Institute, May 1987. - -Author's Address: - - - Marshall Rose - The Wollongong Group - 1129 San Antonio Rd. - Palo Alto, California 94303 - - Phone: (415) 962-7100 - - Email: MRose@TWG.COM - - - - - - - - - - - - - - - - - -Rose [Page 16] -
\ No newline at end of file diff --git a/RFC/rfc1123.txt b/RFC/rfc1123.txt deleted file mode 100644 index 51cdf83c..00000000 --- a/RFC/rfc1123.txt +++ /dev/null @@ -1,5782 +0,0 @@ - - - - - - -Network Working Group Internet Engineering Task Force -Request for Comments: 1123 R. Braden, Editor - October 1989 - - - Requirements for Internet Hosts -- Application and Support - -Status of This Memo - - This RFC is an official specification for the Internet community. It - incorporates by reference, amends, corrects, and supplements the - primary protocol standards documents relating to hosts. Distribution - of this document is unlimited. - -Summary - - This RFC is one of a pair that defines and discusses the requirements - for Internet host software. This RFC covers the application and - support protocols; its companion RFC-1122 covers the communication - protocol layers: link layer, IP layer, and transport layer. - - - - Table of Contents - - - - - 1. INTRODUCTION ............................................... 5 - 1.1 The Internet Architecture .............................. 6 - 1.2 General Considerations ................................. 6 - 1.2.1 Continuing Internet Evolution ..................... 6 - 1.2.2 Robustness Principle .............................. 7 - 1.2.3 Error Logging ..................................... 8 - 1.2.4 Configuration ..................................... 8 - 1.3 Reading this Document .................................. 10 - 1.3.1 Organization ...................................... 10 - 1.3.2 Requirements ...................................... 10 - 1.3.3 Terminology ....................................... 11 - 1.4 Acknowledgments ........................................ 12 - - 2. GENERAL ISSUES ............................................. 13 - 2.1 Host Names and Numbers ................................. 13 - 2.2 Using Domain Name Service .............................. 13 - 2.3 Applications on Multihomed hosts ....................... 14 - 2.4 Type-of-Service ........................................ 14 - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 - - - - -Internet Engineering Task Force [Page 1] - - - - -RFC1123 INTRODUCTION October 1989 - - - 3. REMOTE LOGIN -- TELNET PROTOCOL ............................ 16 - 3.1 INTRODUCTION ........................................... 16 - 3.2 PROTOCOL WALK-THROUGH .................................. 16 - 3.2.1 Option Negotiation ................................ 16 - 3.2.2 Telnet Go-Ahead Function .......................... 16 - 3.2.3 Control Functions ................................. 17 - 3.2.4 Telnet "Synch" Signal ............................. 18 - 3.2.5 NVT Printer and Keyboard .......................... 19 - 3.2.6 Telnet Command Structure .......................... 20 - 3.2.7 Telnet Binary Option .............................. 20 - 3.2.8 Telnet Terminal-Type Option ....................... 20 - 3.3 SPECIFIC ISSUES ........................................ 21 - 3.3.1 Telnet End-of-Line Convention ..................... 21 - 3.3.2 Data Entry Terminals .............................. 23 - 3.3.3 Option Requirements ............................... 24 - 3.3.4 Option Initiation ................................. 24 - 3.3.5 Telnet Linemode Option ............................ 25 - 3.4 TELNET/USER INTERFACE .................................. 25 - 3.4.1 Character Set Transparency ........................ 25 - 3.4.2 Telnet Commands ................................... 26 - 3.4.3 TCP Connection Errors ............................. 26 - 3.4.4 Non-Default Telnet Contact Port ................... 26 - 3.4.5 Flushing Output ................................... 26 - 3.5. TELNET REQUIREMENTS SUMMARY ........................... 27 - - 4. FILE TRANSFER .............................................. 29 - 4.1 FILE TRANSFER PROTOCOL -- FTP .......................... 29 - 4.1.1 INTRODUCTION ...................................... 29 - 4.1.2. PROTOCOL WALK-THROUGH ............................ 29 - 4.1.2.1 LOCAL Type ................................... 29 - 4.1.2.2 Telnet Format Control ........................ 30 - 4.1.2.3 Page Structure ............................... 30 - 4.1.2.4 Data Structure Transformations ............... 30 - 4.1.2.5 Data Connection Management ................... 31 - 4.1.2.6 PASV Command ................................. 31 - 4.1.2.7 LIST and NLST Commands ....................... 31 - 4.1.2.8 SITE Command ................................. 32 - 4.1.2.9 STOU Command ................................. 32 - 4.1.2.10 Telnet End-of-line Code ..................... 32 - 4.1.2.11 FTP Replies ................................. 33 - 4.1.2.12 Connections ................................. 34 - 4.1.2.13 Minimum Implementation; RFC-959 Section ..... 34 - 4.1.3 SPECIFIC ISSUES ................................... 35 - 4.1.3.1 Non-standard Command Verbs ................... 35 - 4.1.3.2 Idle Timeout ................................. 36 - 4.1.3.3 Concurrency of Data and Control .............. 36 - 4.1.3.4 FTP Restart Mechanism ........................ 36 - 4.1.4 FTP/USER INTERFACE ................................ 39 - - - -Internet Engineering Task Force [Page 2] - - - - -RFC1123 INTRODUCTION October 1989 - - - 4.1.4.1 Pathname Specification ....................... 39 - 4.1.4.2 "QUOTE" Command .............................. 40 - 4.1.4.3 Displaying Replies to User ................... 40 - 4.1.4.4 Maintaining Synchronization .................. 40 - 4.1.5 FTP REQUIREMENTS SUMMARY ......................... 41 - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP ................. 44 - 4.2.1 INTRODUCTION ...................................... 44 - 4.2.2 PROTOCOL WALK-THROUGH ............................. 44 - 4.2.2.1 Transfer Modes ............................... 44 - 4.2.2.2 UDP Header ................................... 44 - 4.2.3 SPECIFIC ISSUES ................................... 44 - 4.2.3.1 Sorcerer's Apprentice Syndrome ............... 44 - 4.2.3.2 Timeout Algorithms ........................... 46 - 4.2.3.3 Extensions ................................... 46 - 4.2.3.4 Access Control ............................... 46 - 4.2.3.5 Broadcast Request ............................ 46 - 4.2.4 TFTP REQUIREMENTS SUMMARY ......................... 47 - - 5. ELECTRONIC MAIL -- SMTP and RFC-822 ........................ 48 - 5.1 INTRODUCTION ........................................... 48 - 5.2 PROTOCOL WALK-THROUGH .................................. 48 - 5.2.1 The SMTP Model .................................... 48 - 5.2.2 Canonicalization .................................. 49 - 5.2.3 VRFY and EXPN Commands ............................ 50 - 5.2.4 SEND, SOML, and SAML Commands ..................... 50 - 5.2.5 HELO Command ...................................... 50 - 5.2.6 Mail Relay ........................................ 51 - 5.2.7 RCPT Command ...................................... 52 - 5.2.8 DATA Command ...................................... 53 - 5.2.9 Command Syntax .................................... 54 - 5.2.10 SMTP Replies ..................................... 54 - 5.2.11 Transparency ..................................... 55 - 5.2.12 WKS Use in MX Processing ......................... 55 - 5.2.13 RFC-822 Message Specification .................... 55 - 5.2.14 RFC-822 Date and Time Specification .............. 55 - 5.2.15 RFC-822 Syntax Change ............................ 56 - 5.2.16 RFC-822 Local-part .............................. 56 - 5.2.17 Domain Literals .................................. 57 - 5.2.18 Common Address Formatting Errors ................. 58 - 5.2.19 Explicit Source Routes ........................... 58 - 5.3 SPECIFIC ISSUES ........................................ 59 - 5.3.1 SMTP Queueing Strategies .......................... 59 - 5.3.1.1 Sending Strategy .............................. 59 - 5.3.1.2 Receiving strategy ........................... 61 - 5.3.2 Timeouts in SMTP .................................. 61 - 5.3.3 Reliable Mail Receipt ............................. 63 - 5.3.4 Reliable Mail Transmission ........................ 63 - 5.3.5 Domain Name Support ............................... 65 - - - -Internet Engineering Task Force [Page 3] - - - - -RFC1123 INTRODUCTION October 1989 - - - 5.3.6 Mailing Lists and Aliases ......................... 65 - 5.3.7 Mail Gatewaying ................................... 66 - 5.3.8 Maximum Message Size .............................. 68 - 5.4 SMTP REQUIREMENTS SUMMARY .............................. 69 - - 6. SUPPORT SERVICES ............................................ 72 - 6.1 DOMAIN NAME TRANSLATION ................................. 72 - 6.1.1 INTRODUCTION ....................................... 72 - 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 - 6.1.2.1 Resource Records with Zero TTL ............... 73 - 6.1.2.2 QCLASS Values ................................ 73 - 6.1.2.3 Unused Fields ................................ 73 - 6.1.2.4 Compression .................................. 73 - 6.1.2.5 Misusing Configuration Info .................. 73 - 6.1.3 SPECIFIC ISSUES ................................... 74 - 6.1.3.1 Resolver Implementation ...................... 74 - 6.1.3.2 Transport Protocols .......................... 75 - 6.1.3.3 Efficient Resource Usage ..................... 77 - 6.1.3.4 Multihomed Hosts ............................. 78 - 6.1.3.5 Extensibility ................................ 79 - 6.1.3.6 Status of RR Types ........................... 79 - 6.1.3.7 Robustness ................................... 80 - 6.1.3.8 Local Host Table ............................. 80 - 6.1.4 DNS USER INTERFACE ................................ 81 - 6.1.4.1 DNS Administration ........................... 81 - 6.1.4.2 DNS User Interface ........................... 81 - 6.1.4.3 Interface Abbreviation Facilities ............. 82 - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 - 6.2 HOST INITIALIZATION .................................... 87 - 6.2.1 INTRODUCTION ...................................... 87 - 6.2.2 REQUIREMENTS ...................................... 87 - 6.2.2.1 Dynamic Configuration ........................ 87 - 6.2.2.2 Loading Phase ................................ 89 - 6.3 REMOTE MANAGEMENT ...................................... 90 - 6.3.1 INTRODUCTION ...................................... 90 - 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 - - 7. REFERENCES ................................................. 93 - - - - - - - - - - - - -Internet Engineering Task Force [Page 4] - - - - -RFC1123 INTRODUCTION October 1989 - - -1. INTRODUCTION - - This document is one of a pair that defines and discusses the - requirements for host system implementations of the Internet protocol - suite. This RFC covers the applications layer and support protocols. - Its companion RFC, "Requirements for Internet Hosts -- Communications - Layers" [INTRO:1] covers the lower layer protocols: transport layer, - IP layer, and link layer. - - These documents are intended to provide guidance for vendors, - implementors, and users of Internet communication software. They - represent the consensus of a large body of technical experience and - wisdom, contributed by members of the Internet research and vendor - communities. - - This RFC enumerates standard protocols that a host connected to the - Internet must use, and it incorporates by reference the RFCs and - other documents describing the current specifications for these - protocols. It corrects errors in the referenced documents and adds - additional discussion and guidance for an implementor. - - For each protocol, this document also contains an explicit set of - requirements, recommendations, and options. The reader must - understand that the list of requirements in this document is - incomplete by itself; the complete set of requirements for an - Internet host is primarily defined in the standard protocol - specification documents, with the corrections, amendments, and - supplements contained in this RFC. - - A good-faith implementation of the protocols that was produced after - careful reading of the RFC's and with some interaction with the - Internet technical community, and that followed good communications - software engineering practices, should differ from the requirements - of this document in only minor ways. Thus, in many cases, the - "requirements" in this RFC are already stated or implied in the - standard protocol documents, so that their inclusion here is, in a - sense, redundant. However, they were included because some past - implementation has made the wrong choice, causing problems of - interoperability, performance, and/or robustness. - - This document includes discussion and explanation of many of the - requirements and recommendations. A simple list of requirements - would be dangerous, because: - - o Some required features are more important than others, and some - features are optional. - - o There may be valid reasons why particular vendor products that - - - -Internet Engineering Task Force [Page 5] - - - - -RFC1123 INTRODUCTION October 1989 - - - are designed for restricted contexts might choose to use - different specifications. - - However, the specifications of this document must be followed to meet - the general goal of arbitrary host interoperation across the - diversity and complexity of the Internet system. Although most - current implementations fail to meet these requirements in various - ways, some minor and some major, this specification is the ideal - towards which we need to move. - - These requirements are based on the current level of Internet - architecture. This document will be updated as required to provide - additional clarifications or to include additional information in - those areas in which specifications are still evolving. - - This introductory section begins with general advice to host software - vendors, and then gives some guidance on reading the rest of the - document. Section 2 contains general requirements that may be - applicable to all application and support protocols. Sections 3, 4, - and 5 contain the requirements on protocols for the three major - applications: Telnet, file transfer, and electronic mail, - respectively. Section 6 covers the support applications: the domain - name system, system initialization, and management. Finally, all - references will be found in Section 7. - - 1.1 The Internet Architecture - - For a brief introduction to the Internet architecture from a host - viewpoint, see Section 1.1 of [INTRO:1]. That section also - contains recommended references for general background on the - Internet architecture. - - 1.2 General Considerations - - There are two important lessons that vendors of Internet host - software have learned and which a new vendor should consider - seriously. - - 1.2.1 Continuing Internet Evolution - - The enormous growth of the Internet has revealed problems of - management and scaling in a large datagram-based packet - communication system. These problems are being addressed, and - as a result there will be continuing evolution of the - specifications described in this document. These changes will - be carefully planned and controlled, since there is extensive - participation in this planning by the vendors and by the - organizations responsible for operations of the networks. - - - -Internet Engineering Task Force [Page 6] - - - - -RFC1123 INTRODUCTION October 1989 - - - Development, evolution, and revision are characteristic of - computer network protocols today, and this situation will - persist for some years. A vendor who develops computer - communication software for the Internet protocol suite (or any - other protocol suite!) and then fails to maintain and update - that software for changing specifications is going to leave a - trail of unhappy customers. The Internet is a large - communication network, and the users are in constant contact - through it. Experience has shown that knowledge of - deficiencies in vendor software propagates quickly through the - Internet technical community. - - 1.2.2 Robustness Principle - - At every layer of the protocols, there is a general rule whose - application can lead to enormous benefits in robustness and - interoperability: - - "Be liberal in what you accept, and - conservative in what you send" - - Software should be written to deal with every conceivable - error, no matter how unlikely; sooner or later a packet will - come in with that particular combination of errors and - attributes, and unless the software is prepared, chaos can - ensue. In general, it is best to assume that the network is - filled with malevolent entities that will send in packets - designed to have the worst possible effect. This assumption - will lead to suitable protective design, although the most - serious problems in the Internet have been caused by - unenvisaged mechanisms triggered by low-probability events; - mere human malice would never have taken so devious a course! - - Adaptability to change must be designed into all levels of - Internet host software. As a simple example, consider a - protocol specification that contains an enumeration of values - for a particular header field -- e.g., a type field, a port - number, or an error code; this enumeration must be assumed to - be incomplete. Thus, if a protocol specification defines four - possible error codes, the software must not break when a fifth - code shows up. An undefined code might be logged (see below), - but it must not cause a failure. - - The second part of the principle is almost as important: - software on other hosts may contain deficiencies that make it - unwise to exploit legal but obscure protocol features. It is - unwise to stray far from the obvious and simple, lest untoward - effects result elsewhere. A corollary of this is "watch out - - - -Internet Engineering Task Force [Page 7] - - - - -RFC1123 INTRODUCTION October 1989 - - - for misbehaving hosts"; host software should be prepared, not - just to survive other misbehaving hosts, but also to cooperate - to limit the amount of disruption such hosts can cause to the - shared communication facility. - - 1.2.3 Error Logging - - The Internet includes a great variety of host and gateway - systems, each implementing many protocols and protocol layers, - and some of these contain bugs and mis-features in their - Internet protocol software. As a result of complexity, - diversity, and distribution of function, the diagnosis of user - problems is often very difficult. - - Problem diagnosis will be aided if host implementations include - a carefully designed facility for logging erroneous or - "strange" protocol events. It is important to include as much - diagnostic information as possible when an error is logged. In - particular, it is often useful to record the header(s) of a - packet that caused an error. However, care must be taken to - ensure that error logging does not consume prohibitive amounts - of resources or otherwise interfere with the operation of the - host. - - There is a tendency for abnormal but harmless protocol events - to overflow error logging files; this can be avoided by using a - "circular" log, or by enabling logging only while diagnosing a - known failure. It may be useful to filter and count duplicate - successive messages. One strategy that seems to work well is: - (1) always count abnormalities and make such counts accessible - through the management protocol (see Section 6.3); and (2) - allow the logging of a great variety of events to be - selectively enabled. For example, it might useful to be able - to "log everything" or to "log everything for host X". - - Note that different managements may have differing policies - about the amount of error logging that they want normally - enabled in a host. Some will say, "if it doesn't hurt me, I - don't want to know about it", while others will want to take a - more watchful and aggressive attitude about detecting and - removing protocol abnormalities. - - 1.2.4 Configuration - - It would be ideal if a host implementation of the Internet - protocol suite could be entirely self-configuring. This would - allow the whole suite to be implemented in ROM or cast into - silicon, it would simplify diskless workstations, and it would - - - -Internet Engineering Task Force [Page 8] - - - - -RFC1123 INTRODUCTION October 1989 - - - be an immense boon to harried LAN administrators as well as - system vendors. We have not reached this ideal; in fact, we - are not even close. - - At many points in this document, you will find a requirement - that a parameter be a configurable option. There are several - different reasons behind such requirements. In a few cases, - there is current uncertainty or disagreement about the best - value, and it may be necessary to update the recommended value - in the future. In other cases, the value really depends on - external factors -- e.g., the size of the host and the - distribution of its communication load, or the speeds and - topology of nearby networks -- and self-tuning algorithms are - unavailable and may be insufficient. In some cases, - configurability is needed because of administrative - requirements. - - Finally, some configuration options are required to communicate - with obsolete or incorrect implementations of the protocols, - distributed without sources, that unfortunately persist in many - parts of the Internet. To make correct systems coexist with - these faulty systems, administrators often have to "mis- - configure" the correct systems. This problem will correct - itself gradually as the faulty systems are retired, but it - cannot be ignored by vendors. - - When we say that a parameter must be configurable, we do not - intend to require that its value be explicitly read from a - configuration file at every boot time. We recommend that - implementors set up a default for each parameter, so a - configuration file is only necessary to override those defaults - that are inappropriate in a particular installation. Thus, the - configurability requirement is an assurance that it will be - POSSIBLE to override the default when necessary, even in a - binary-only or ROM-based product. - - This document requires a particular value for such defaults in - some cases. The choice of default is a sensitive issue when - the configuration item controls the accommodation to existing - faulty systems. If the Internet is to converge successfully to - complete interoperability, the default values built into - implementations must implement the official protocol, not - "mis-configurations" to accommodate faulty implementations. - Although marketing considerations have led some vendors to - choose mis-configuration defaults, we urge vendors to choose - defaults that will conform to the standard. - - Finally, we note that a vendor needs to provide adequate - - - -Internet Engineering Task Force [Page 9] - - - - -RFC1123 INTRODUCTION October 1989 - - - documentation on all configuration parameters, their limits and - effects. - - - 1.3 Reading this Document - - 1.3.1 Organization - - In general, each major section is organized into the following - subsections: - - (1) Introduction - - (2) Protocol Walk-Through -- considers the protocol - specification documents section-by-section, correcting - errors, stating requirements that may be ambiguous or - ill-defined, and providing further clarification or - explanation. - - (3) Specific Issues -- discusses protocol design and - implementation issues that were not included in the walk- - through. - - (4) Interfaces -- discusses the service interface to the next - higher layer. - - (5) Summary -- contains a summary of the requirements of the - section. - - Under many of the individual topics in this document, there is - parenthetical material labeled "DISCUSSION" or - "IMPLEMENTATION". This material is intended to give - clarification and explanation of the preceding requirements - text. It also includes some suggestions on possible future - directions or developments. The implementation material - contains suggested approaches that an implementor may want to - consider. - - The summary sections are intended to be guides and indexes to - the text, but are necessarily cryptic and incomplete. The - summaries should never be used or referenced separately from - the complete RFC. - - 1.3.2 Requirements - - In this document, the words that are used to define the - significance of each particular requirement are capitalized. - These words are: - - - -Internet Engineering Task Force [Page 10] - - - - -RFC1123 INTRODUCTION October 1989 - - - * "MUST" - - This word or the adjective "REQUIRED" means that the item - is an absolute requirement of the specification. - - * "SHOULD" - - This word or the adjective "RECOMMENDED" means that there - may exist valid reasons in particular circumstances to - ignore this item, but the full implications should be - understood and the case carefully weighed before choosing - a different course. - - * "MAY" - - This word or the adjective "OPTIONAL" means that this item - is truly optional. One vendor may choose to include the - item because a particular marketplace requires it or - because it enhances the product, for example; another - vendor may omit the same item. - - - An implementation is not compliant if it fails to satisfy one - or more of the MUST requirements for the protocols it - implements. An implementation that satisfies all the MUST and - all the SHOULD requirements for its protocols is said to be - "unconditionally compliant"; one that satisfies all the MUST - requirements but not all the SHOULD requirements for its - protocols is said to be "conditionally compliant". - - 1.3.3 Terminology - - This document uses the following technical terms: - - Segment - A segment is the unit of end-to-end transmission in the - TCP protocol. A segment consists of a TCP header followed - by application data. A segment is transmitted by - encapsulation in an IP datagram. - - Message - This term is used by some application layer protocols - (particularly SMTP) for an application data unit. - - Datagram - A [UDP] datagram is the unit of end-to-end transmission in - the UDP protocol. - - - - -Internet Engineering Task Force [Page 11] - - - - -RFC1123 INTRODUCTION October 1989 - - - Multihomed - A host is said to be multihomed if it has multiple IP - addresses to connected networks. - - - - 1.4 Acknowledgments - - This document incorporates contributions and comments from a large - group of Internet protocol experts, including representatives of - university and research labs, vendors, and government agencies. - It was assembled primarily by the Host Requirements Working Group - of the Internet Engineering Task Force (IETF). - - The Editor would especially like to acknowledge the tireless - dedication of the following people, who attended many long - meetings and generated 3 million bytes of electronic mail over the - past 18 months in pursuit of this document: Philip Almquist, Dave - Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve - Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), - John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), - Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge - (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software). - - In addition, the following people made major contributions to the - effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia - (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), - Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), - John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill - Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul - (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue - Technology), and Mike StJohns (DCA). The following also made - significant contributions to particular areas: Eric Allman - (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic - (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn - (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann - (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun - Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen - (Toronto). - - We are grateful to all, including any contributors who may have - been inadvertently omitted from this list. - - - - - - - - - -Internet Engineering Task Force [Page 12] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - -2. GENERAL ISSUES - - This section contains general requirements that may be applicable to - all application-layer protocols. - - 2.1 Host Names and Numbers - - The syntax of a legal Internet host name was specified in RFC-952 - [DNS:4]. One aspect of host name syntax is hereby changed: the - restriction on the first character is relaxed to allow either a - letter or a digit. Host software MUST support this more liberal - syntax. - - Host software MUST handle host names of up to 63 characters and - SHOULD handle host names of up to 255 characters. - - Whenever a user inputs the identity of an Internet host, it SHOULD - be possible to enter either (1) a host domain name or (2) an IP - address in dotted-decimal ("#.#.#.#") form. The host SHOULD check - the string syntactically for a dotted-decimal number before - looking it up in the Domain Name System. - - DISCUSSION: - This last requirement is not intended to specify the complete - syntactic form for entering a dotted-decimal host number; - that is considered to be a user-interface issue. For - example, a dotted-decimal number must be enclosed within - "[ ]" brackets for SMTP mail (see Section 5.2.17). This - notation could be made universal within a host system, - simplifying the syntactic checking for a dotted-decimal - number. - - If a dotted-decimal number can be entered without such - identifying delimiters, then a full syntactic check must be - made, because a segment of a host domain name is now allowed - to begin with a digit and could legally be entirely numeric - (see Section 6.1.2.4). However, a valid host name can never - have the dotted-decimal form #.#.#.#, since at least the - highest-level component label will be alphabetic. - - 2.2 Using Domain Name Service - - Host domain names MUST be translated to IP addresses as described - in Section 6.1. - - Applications using domain name services MUST be able to cope with - soft error conditions. Applications MUST wait a reasonable - interval between successive retries due to a soft error, and MUST - - - -Internet Engineering Task Force [Page 13] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - allow for the possibility that network problems may deny service - for hours or even days. - - An application SHOULD NOT rely on the ability to locate a WKS - record containing an accurate listing of all services at a - particular host address, since the WKS RR type is not often used - by Internet sites. To confirm that a service is present, simply - attempt to use it. - - 2.3 Applications on Multihomed hosts - - When the remote host is multihomed, the name-to-address - translation will return a list of alternative IP addresses. As - specified in Section 6.1.3.4, this list should be in order of - decreasing preference. Application protocol implementations - SHOULD be prepared to try multiple addresses from the list until - success is obtained. More specific requirements for SMTP are - given in Section 5.3.4. - - When the local host is multihomed, a UDP-based request/response - application SHOULD send the response with an IP source address - that is the same as the specific destination address of the UDP - request datagram. The "specific destination address" is defined - in the "IP Addressing" section of the companion RFC [INTRO:1]. - - Similarly, a server application that opens multiple TCP - connections to the same client SHOULD use the same local IP - address for all. - - 2.4 Type-of-Service - - Applications MUST select appropriate TOS values when they invoke - transport layer services, and these values MUST be configurable. - Note that a TOS value contains 5 bits, of which only the most- - significant 3 bits are currently defined; the other two bits MUST - be zero. - - DISCUSSION: - As gateway algorithms are developed to implement Type-of- - Service, the recommended values for various application - protocols may change. In addition, it is likely that - particular combinations of users and Internet paths will want - non-standard TOS values. For these reasons, the TOS values - must be configurable. - - See the latest version of the "Assigned Numbers" RFC - [INTRO:5] for the recommended TOS values for the major - application protocols. - - - -Internet Engineering Task Force [Page 14] - - - - -RFC1123 APPLICATIONS LAYER -- GENERAL October 1989 - - - 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -User interfaces: | | | | | | | - Allow host name to begin with digit |2.1 |x| | | | | - Host names of up to 635 characters |2.1 |x| | | | | - Host names of up to 255 characters |2.1 | |x| | | | - Support dotted-decimal host numbers |2.1 | |x| | | | - Check syntactically for dotted-dec first |2.1 | |x| | | | - | | | | | | | -Map domain names per Section 6.1 |2.2 |x| | | | | -Cope with soft DNS errors |2.2 |x| | | | | - Reasonable interval between retries |2.2 |x| | | | | - Allow for long outages |2.2 |x| | | | | -Expect WKS records to be available |2.2 | | | |x| | - | | | | | | | -Try multiple addr's for remote multihomed host |2.3 | |x| | | | -UDP reply src addr is specific dest of request |2.3 | |x| | | | -Use same IP addr for related TCP connections |2.3 | |x| | | | -Specify appropriate TOS values |2.4 |x| | | | | - TOS values configurable |2.4 |x| | | | | - Unused TOS bits zero |2.4 |x| | | | | - | | | | | | | - | | | | | | | - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 15] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - -3. REMOTE LOGIN -- TELNET PROTOCOL - - 3.1 INTRODUCTION - - Telnet is the standard Internet application protocol for remote - login. It provides the encoding rules to link a user's - keyboard/display on a client ("user") system with a command - interpreter on a remote server system. A subset of the Telnet - protocol is also incorporated within other application protocols, - e.g., FTP and SMTP. - - Telnet uses a single TCP connection, and its normal data stream - ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with - escape sequences to embed control functions. Telnet also allows - the negotiation of many optional modes and functions. - - The primary Telnet specification is to be found in RFC-854 - [TELNET:1], while the options are defined in many other RFCs; see - Section 7 for references. - - 3.2 PROTOCOL WALK-THROUGH - - 3.2.1 Option Negotiation: RFC-854, pp. 2-3 - - Every Telnet implementation MUST include option negotiation and - subnegotiation machinery [TELNET:2]. - - A host MUST carefully follow the rules of RFC-854 to avoid - option-negotiation loops. A host MUST refuse (i.e, reply - WONT/DONT to a DO/WILL) an unsupported option. Option - negotiation SHOULD continue to function (even if all requests - are refused) throughout the lifetime of a Telnet connection. - - If all option negotiations fail, a Telnet implementation MUST - default to, and support, an NVT. - - DISCUSSION: - Even though more sophisticated "terminals" and supporting - option negotiations are becoming the norm, all - implementations must be prepared to support an NVT for any - user-server communication. - - 3.2.2 Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858 - - On a host that never sends the Telnet command Go Ahead (GA), - the Telnet Server MUST attempt to negotiate the Suppress Go - Ahead option (i.e., send "WILL Suppress Go Ahead"). A User or - Server Telnet MUST always accept negotiation of the Suppress Go - - - -Internet Engineering Task Force [Page 16] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Ahead option. - - When it is driving a full-duplex terminal for which GA has no - meaning, a User Telnet implementation MAY ignore GA commands. - - DISCUSSION: - Half-duplex ("locked-keyboard") line-at-a-time terminals - for which the Go-Ahead mechanism was designed have largely - disappeared from the scene. It turned out to be difficult - to implement sending the Go-Ahead signal in many operating - systems, even some systems that support native half-duplex - terminals. The difficulty is typically that the Telnet - server code does not have access to information about - whether the user process is blocked awaiting input from - the Telnet connection, i.e., it cannot reliably determine - when to send a GA command. Therefore, most Telnet Server - hosts do not send GA commands. - - The effect of the rules in this section is to allow either - end of a Telnet connection to veto the use of GA commands. - - There is a class of half-duplex terminals that is still - commercially important: "data entry terminals," which - interact in a full-screen manner. However, supporting - data entry terminals using the Telnet protocol does not - require the Go Ahead signal; see Section 3.3.2. - - 3.2.3 Control Functions: RFC-854, pp. 7-8 - - The list of Telnet commands has been extended to include EOR - (End-of-Record), with code 239 [TELNET:9]. - - Both User and Server Telnets MAY support the control functions - EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP, - SB, and SE. - - A host MUST be able to receive and ignore any Telnet control - functions that it does not support. - - DISCUSSION: - Note that a Server Telnet is required to support the - Telnet IP (Interrupt Process) function, even if the server - host has an equivalent in-stream function (e.g., Control-C - in many systems). The Telnet IP function may be stronger - than an in-stream interrupt command, because of the out- - of-band effect of TCP urgent data. - - The EOR control function may be used to delimit the - - - -Internet Engineering Task Force [Page 17] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - stream. An important application is data entry terminal - support (see Section 3.3.2). There was concern that since - EOR had not been defined in RFC-854, a host that was not - prepared to correctly ignore unknown Telnet commands might - crash if it received an EOR. To protect such hosts, the - End-of-Record option [TELNET:9] was introduced; however, a - properly implemented Telnet program will not require this - protection. - - 3.2.4 Telnet "Synch" Signal: RFC-854, pp. 8-10 - - When it receives "urgent" TCP data, a User or Server Telnet - MUST discard all data except Telnet commands until the DM (and - end of urgent) is reached. - - When it sends Telnet IP (Interrupt Process), a User Telnet - SHOULD follow it by the Telnet "Synch" sequence, i.e., send as - TCP urgent data the sequence "IAC IP IAC DM". The TCP urgent - pointer points to the DM octet. - - When it receives a Telnet IP command, a Server Telnet MAY send - a Telnet "Synch" sequence back to the user, to flush the output - stream. The choice ought to be consistent with the way the - server operating system behaves when a local user interrupts a - process. - - When it receives a Telnet AO command, a Server Telnet MUST send - a Telnet "Synch" sequence back to the user, to flush the output - stream. - - A User Telnet SHOULD have the capability of flushing output - when it sends a Telnet IP; see also Section 3.4.5. - - DISCUSSION: - There are three possible ways for a User Telnet to flush - the stream of server output data: - - (1) Send AO after IP. - - This will cause the server host to send a "flush- - buffered-output" signal to its operating system. - However, the AO may not take effect locally, i.e., - stop terminal output at the User Telnet end, until - the Server Telnet has received and processed the AO - and has sent back a "Synch". - - (2) Send DO TIMING-MARK [TELNET:7] after IP, and discard - all output locally until a WILL/WONT TIMING-MARK is - - - -Internet Engineering Task Force [Page 18] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - received from the Server Telnet. - - Since the DO TIMING-MARK will be processed after the - IP at the server, the reply to it should be in the - right place in the output data stream. However, the - TIMING-MARK will not send a "flush buffered output" - signal to the server operating system. Whether or - not this is needed is dependent upon the server - system. - - (3) Do both. - - The best method is not entirely clear, since it must - accommodate a number of existing server hosts that do not - follow the Telnet standards in various ways. The safest - approach is probably to provide a user-controllable option - to select (1), (2), or (3). - - 3.2.5 NVT Printer and Keyboard: RFC-854, p. 11 - - In NVT mode, a Telnet SHOULD NOT send characters with the - high-order bit 1, and MUST NOT send it as a parity bit. - Implementations that pass the high-order bit to applications - SHOULD negotiate binary mode (see Section 3.2.6). - - - DISCUSSION: - Implementors should be aware that a strict reading of - RFC-854 allows a client or server expecting NVT ASCII to - ignore characters with the high-order bit set. In - general, binary mode is expected to be used for - transmission of an extended (beyond 7-bit) character set - with Telnet. - - However, there exist applications that really need an 8- - bit NVT mode, which is currently not defined, and these - existing applications do set the high-order bit during - part or all of the life of a Telnet connection. Note that - binary mode is not the same as 8-bit NVT mode, since - binary mode turns off end-of-line processing. For this - reason, the requirements on the high-order bit are stated - as SHOULD, not MUST. - - RFC-854 defines a minimal set of properties of a "network - virtual terminal" or NVT; this is not meant to preclude - additional features in a real terminal. A Telnet - connection is fully transparent to all 7-bit ASCII - characters, including arbitrary ASCII control characters. - - - -Internet Engineering Task Force [Page 19] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - For example, a terminal might support full-screen commands - coded as ASCII escape sequences; a Telnet implementation - would pass these sequences as uninterpreted data. Thus, - an NVT should not be conceived as a terminal type of a - highly-restricted device. - - 3.2.6 Telnet Command Structure: RFC-854, p. 13 - - Since options may appear at any point in the data stream, a - Telnet escape character (known as IAC, with the value 255) to - be sent as data MUST be doubled. - - 3.2.7 Telnet Binary Option: RFC-856 - - When the Binary option has been successfully negotiated, - arbitrary 8-bit characters are allowed. However, the data - stream MUST still be scanned for IAC characters, any embedded - Telnet commands MUST be obeyed, and data bytes equal to IAC - MUST be doubled. Other character processing (e.g., replacing - CR by CR NUL or by CR LF) MUST NOT be done. In particular, - there is no end-of-line convention (see Section 3.3.1) in - binary mode. - - DISCUSSION: - The Binary option is normally negotiated in both - directions, to change the Telnet connection from NVT mode - to "binary mode". - - The sequence IAC EOR can be used to delimit blocks of data - within a binary-mode Telnet stream. - - 3.2.8 Telnet Terminal-Type Option: RFC-1091 - - The Terminal-Type option MUST use the terminal type names - officially defined in the Assigned Numbers RFC [INTRO:5], when - they are available for the particular terminal. However, the - receiver of a Terminal-Type option MUST accept any name. - - DISCUSSION: - RFC-1091 [TELNET:10] updates an earlier version of the - Terminal-Type option defined in RFC-930. The earlier - version allowed a server host capable of supporting - multiple terminal types to learn the type of a particular - client's terminal, assuming that each physical terminal - had an intrinsic type. However, today a "terminal" is - often really a terminal emulator program running in a PC, - perhaps capable of emulating a range of terminal types. - Therefore, RFC-1091 extends the specification to allow a - - - -Internet Engineering Task Force [Page 20] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - more general terminal-type negotiation between User and - Server Telnets. - - 3.3 SPECIFIC ISSUES - - 3.3.1 Telnet End-of-Line Convention - - The Telnet protocol defines the sequence CR LF to mean "end- - of-line". For terminal input, this corresponds to a command- - completion or "end-of-line" key being pressed on a user - terminal; on an ASCII terminal, this is the CR key, but it may - also be labelled "Return" or "Enter". - - When a Server Telnet receives the Telnet end-of-line sequence - CR LF as input from a remote terminal, the effect MUST be the - same as if the user had pressed the "end-of-line" key on a - local terminal. On server hosts that use ASCII, in particular, - receipt of the Telnet sequence CR LF must cause the same effect - as a local user pressing the CR key on a local terminal. Thus, - CR LF and CR NUL MUST have the same effect on an ASCII server - host when received as input over a Telnet connection. - - A User Telnet MUST be able to send any of the forms: CR LF, CR - NUL, and LF. A User Telnet on an ASCII host SHOULD have a - user-controllable mode to send either CR LF or CR NUL when the - user presses the "end-of-line" key, and CR LF SHOULD be the - default. - - The Telnet end-of-line sequence CR LF MUST be used to send - Telnet data that is not terminal-to-computer (e.g., for Server - Telnet sending output, or the Telnet protocol incorporated - another application protocol). - - DISCUSSION: - To allow interoperability between arbitrary Telnet clients - and servers, the Telnet protocol defined a standard - representation for a line terminator. Since the ASCII - character set includes no explicit end-of-line character, - systems have chosen various representations, e.g., CR, LF, - and the sequence CR LF. The Telnet protocol chose the CR - LF sequence as the standard for network transmission. - - Unfortunately, the Telnet protocol specification in RFC- - 854 [TELNET:1] has turned out to be somewhat ambiguous on - what character(s) should be sent from client to server for - the "end-of-line" key. The result has been a massive and - continuing interoperability headache, made worse by - various faulty implementations of both User and Server - - - -Internet Engineering Task Force [Page 21] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Telnets. - - Although the Telnet protocol is based on a perfectly - symmetric model, in a remote login session the role of the - user at a terminal differs from the role of the server - host. For example, RFC-854 defines the meaning of CR, LF, - and CR LF as output from the server, but does not specify - what the User Telnet should send when the user presses the - "end-of-line" key on the terminal; this turns out to be - the point at issue. - - When a user presses the "end-of-line" key, some User - Telnet implementations send CR LF, while others send CR - NUL (based on a different interpretation of the same - sentence in RFC-854). These will be equivalent for a - correctly-implemented ASCII server host, as discussed - above. For other servers, a mode in the User Telnet is - needed. - - The existence of User Telnets that send only CR NUL when - CR is pressed creates a dilemma for non-ASCII hosts: they - can either treat CR NUL as equivalent to CR LF in input, - thus precluding the possibility of entering a "bare" CR, - or else lose complete interworking. - - Suppose a user on host A uses Telnet to log into a server - host B, and then execute B's User Telnet program to log - into server host C. It is desirable for the Server/User - Telnet combination on B to be as transparent as possible, - i.e., to appear as if A were connected directly to C. In - particular, correct implementation will make B transparent - to Telnet end-of-line sequences, except that CR LF may be - translated to CR NUL or vice versa. - - IMPLEMENTATION: - To understand Telnet end-of-line issues, one must have at - least a general model of the relationship of Telnet to the - local operating system. The Server Telnet process is - typically coupled into the terminal driver software of the - operating system as a pseudo-terminal. A Telnet end-of- - line sequence received by the Server Telnet must have the - same effect as pressing the end-of-line key on a real - locally-connected terminal. - - Operating systems that support interactive character-at- - a-time applications (e.g., editors) typically have two - internal modes for their terminal I/O: a formatted mode, - in which local conventions for end-of-line and other - - - -Internet Engineering Task Force [Page 22] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - formatting rules have been applied to the data stream, and - a "raw" mode, in which the application has direct access - to every character as it was entered. A Server Telnet - must be implemented in such a way that these modes have - the same effect for remote as for local terminals. For - example, suppose a CR LF or CR NUL is received by the - Server Telnet on an ASCII host. In raw mode, a CR - character is passed to the application; in formatted mode, - the local system's end-of-line convention is used. - - 3.3.2 Data Entry Terminals - - DISCUSSION: - In addition to the line-oriented and character-oriented - ASCII terminals for which Telnet was designed, there are - several families of video display terminals that are - sometimes known as "data entry terminals" or DETs. The - IBM 3270 family is a well-known example. - - Two Internet protocols have been designed to support - generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET - option [TELNET:18, TELNET:19]. The DET option drives a - data entry terminal over a Telnet connection using (sub-) - negotiation. SUPDUP is a completely separate terminal - protocol, which can be entered from Telnet by negotiation. - Although both SUPDUP and the DET option have been used - successfully in particular environments, neither has - gained general acceptance or wide implementation. - - A different approach to DET interaction has been developed - for supporting the IBM 3270 family through Telnet, - although the same approach would be applicable to any DET. - The idea is to enter a "native DET" mode, in which the - native DET input/output stream is sent as binary data. - The Telnet EOR command is used to delimit logical records - (e.g., "screens") within this binary stream. - - IMPLEMENTATION: - The rules for entering and leaving native DET mode are as - follows: - - o The Server uses the Terminal-Type option [TELNET:10] - to learn that the client is a DET. - - o It is conventional, but not required, that both ends - negotiate the EOR option [TELNET:9]. - - o Both ends negotiate the Binary option [TELNET:3] to - - - -Internet Engineering Task Force [Page 23] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - enter native DET mode. - - o When either end negotiates out of binary mode, the - other end does too, and the mode then reverts to - normal NVT. - - - 3.3.3 Option Requirements - - Every Telnet implementation MUST support the Binary option - [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and - SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of- - Record [TELNET:9], and Extended Options List [TELNET:8] - options. - - A User or Server Telnet SHOULD support the Window Size Option - [TELNET:12] if the local operating system provides the - corresponding capability. - - DISCUSSION: - Note that the End-of-Record option only signifies that a - Telnet can receive a Telnet EOR without crashing; - therefore, every Telnet ought to be willing to accept - negotiation of the End-of-Record option. See also the - discussion in Section 3.2.3. - - 3.3.4 Option Initiation - - When the Telnet protocol is used in a client/server situation, - the server SHOULD initiate negotiation of the terminal - interaction mode it expects. - - DISCUSSION: - The Telnet protocol was defined to be perfectly - symmetrical, but its application is generally asymmetric. - Remote login has been known to fail because NEITHER side - initiated negotiation of the required non-default terminal - modes. It is generally the server that determines the - preferred mode, so the server needs to initiate the - negotiation; since the negotiation is symmetric, the user - can also initiate it. - - A client (User Telnet) SHOULD provide a means for users to - enable and disable the initiation of option negotiation. - - DISCUSSION: - A user sometimes needs to connect to an application - service (e.g., FTP or SMTP) that uses Telnet for its - - - -Internet Engineering Task Force [Page 24] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - control stream but does not support Telnet options. User - Telnet may be used for this purpose if initiation of - option negotiation is disabled. - - 3.3.5 Telnet Linemode Option - - DISCUSSION: - An important new Telnet option, LINEMODE [TELNET:12], has - been proposed. The LINEMODE option provides a standard - way for a User Telnet and a Server Telnet to agree that - the client rather than the server will perform terminal - character processing. When the client has prepared a - complete line of text, it will send it to the server in - (usually) one TCP packet. This option will greatly - decrease the packet cost of Telnet sessions and will also - give much better user response over congested or long- - delay networks. - - The LINEMODE option allows dynamic switching between local - and remote character processing. For example, the Telnet - connection will automatically negotiate into single- - character mode while a full screen editor is running, and - then return to linemode when the editor is finished. - - We expect that when this RFC is released, hosts should - implement the client side of this option, and may - implement the server side of this option. To properly - implement the server side, the server needs to be able to - tell the local system not to do any input character - processing, but to remember its current terminal state and - notify the Server Telnet process whenever the state - changes. This will allow password echoing and full screen - editors to be handled properly, for example. - - 3.4 TELNET/USER INTERFACE - - 3.4.1 Character Set Transparency - - User Telnet implementations SHOULD be able to send or receive - any 7-bit ASCII character. Where possible, any special - character interpretations by the user host's operating system - SHOULD be bypassed so that these characters can conveniently be - sent and received on the connection. - - Some character value MUST be reserved as "escape to command - mode"; conventionally, doubling this character allows it to be - entered as data. The specific character used SHOULD be user - selectable. - - - -Internet Engineering Task Force [Page 25] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - On binary-mode connections, a User Telnet program MAY provide - an escape mechanism for entering arbitrary 8-bit values, if the - host operating system doesn't allow them to be entered directly - from the keyboard. - - IMPLEMENTATION: - The transparency issues are less pressing on servers, but - implementors should take care in dealing with issues like: - masking off parity bits (sent by an older, non-conforming - client) before they reach programs that expect only NVT - ASCII, and properly handling programs that request 8-bit - data streams. - - 3.4.2 Telnet Commands - - A User Telnet program MUST provide a user the capability of - entering any of the Telnet control functions IP, AO, or AYT, - and SHOULD provide the capability of entering EC, EL, and - Break. - - 3.4.3 TCP Connection Errors - - A User Telnet program SHOULD report to the user any TCP errors - that are reported by the transport layer (see "TCP/Application - Layer Interface" section in [INTRO:1]). - - 3.4.4 Non-Default Telnet Contact Port - - A User Telnet program SHOULD allow the user to optionally - specify a non-standard contact port number at the Server Telnet - host. - - 3.4.5 Flushing Output - - A User Telnet program SHOULD provide the user the ability to - specify whether or not output should be flushed when an IP is - sent; see Section 3.2.4. - - For any output flushing scheme that causes the User Telnet to - flush output locally until a Telnet signal is received from the - Server, there SHOULD be a way for the user to manually restore - normal output, in case the Server fails to send the expected - signal. - - - - - - - - -Internet Engineering Task Force [Page 26] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - 3.5. TELNET REQUIREMENTS SUMMARY - - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- - | | | | | | | -Option Negotiation |3.2.1 |x| | | | | - Avoid negotiation loops |3.2.1 |x| | | | | - Refuse unsupported options |3.2.1 |x| | | | | - Negotiation OK anytime on connection |3.2.1 | |x| | | | - Default to NVT |3.2.1 |x| | | | | - Send official name in Term-Type option |3.2.8 |x| | | | | - Accept any name in Term-Type option |3.2.8 |x| | | | | - Implement Binary, Suppress-GA options |3.3.3 |x| | | | | - Echo, Status, EOL, Ext-Opt-List options |3.3.3 | |x| | | | - Implement Window-Size option if appropriate |3.3.3 | |x| | | | - Server initiate mode negotiations |3.3.4 | |x| | | | - User can enable/disable init negotiations |3.3.4 | |x| | | | - | | | | | | | -Go-Aheads | | | | | | | - Non-GA server negotiate SUPPRESS-GA option |3.2.2 |x| | | | | - User or Server accept SUPPRESS-GA option |3.2.2 |x| | | | | - User Telnet ignore GA's |3.2.2 | | |x| | | - | | | | | | | -Control Functions | | | | | | | - Support SE NOP DM IP AO AYT SB |3.2.3 |x| | | | | - Support EOR EC EL Break |3.2.3 | | |x| | | - Ignore unsupported control functions |3.2.3 |x| | | | | - User, Server discard urgent data up to DM |3.2.4 |x| | | | | - User Telnet send "Synch" after IP, AO, AYT |3.2.4 | |x| | | | - Server Telnet reply Synch to IP |3.2.4 | | |x| | | - Server Telnet reply Synch to AO |3.2.4 |x| | | | | - User Telnet can flush output when send IP |3.2.4 | |x| | | | - | | | | | | | -Encoding | | | | | | | - Send high-order bit in NVT mode |3.2.5 | | | |x| | - Send high-order bit as parity bit |3.2.5 | | | | |x| - Negot. BINARY if pass high-ord. bit to applic |3.2.5 | |x| | | | - Always double IAC data byte |3.2.6 |x| | | | | - - - -Internet Engineering Task Force [Page 27] - - - - -RFC1123 REMOTE LOGIN -- TELNET October 1989 - - - Double IAC data byte in binary mode |3.2.7 |x| | | | | - Obey Telnet cmds in binary mode |3.2.7 |x| | | | | - End-of-line, CR NUL in binary mode |3.2.7 | | | | |x| - | | | | | | | -End-of-Line | | | | | | | - EOL at Server same as local end-of-line |3.3.1 |x| | | | | - ASCII Server accept CR LF or CR NUL for EOL |3.3.1 |x| | | | | - User Telnet able to send CR LF, CR NUL, or LF |3.3.1 |x| | | | | - ASCII user able to select CR LF/CR NUL |3.3.1 | |x| | | | - User Telnet default mode is CR LF |3.3.1 | |x| | | | - Non-interactive uses CR LF for EOL |3.3.1 |x| | | | | - | | | | | | | -User Telnet interface | | | | | | | - Input & output all 7-bit characters |3.4.1 | |x| | | | - Bypass local op sys interpretation |3.4.1 | |x| | | | - Escape character |3.4.1 |x| | | | | - User-settable escape character |3.4.1 | |x| | | | - Escape to enter 8-bit values |3.4.1 | | |x| | | - Can input IP, AO, AYT |3.4.2 |x| | | | | - Can input EC, EL, Break |3.4.2 | |x| | | | - Report TCP connection errors to user |3.4.3 | |x| | | | - Optional non-default contact port |3.4.4 | |x| | | | - Can spec: output flushed when IP sent |3.4.5 | |x| | | | - Can manually restore output mode |3.4.5 | |x| | | | - | | | | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 28] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -4. FILE TRANSFER - - 4.1 FILE TRANSFER PROTOCOL -- FTP - - 4.1.1 INTRODUCTION - - The File Transfer Protocol FTP is the primary Internet standard - for file transfer. The current specification is contained in - RFC-959 [FTP:1]. - - FTP uses separate simultaneous TCP connections for control and - for data transfer. The FTP protocol includes many features, - some of which are not commonly implemented. However, for every - feature in FTP, there exists at least one implementation. The - minimum implementation defined in RFC-959 was too small, so a - somewhat larger minimum implementation is defined here. - - Internet users have been unnecessarily burdened for years by - deficient FTP implementations. Protocol implementors have - suffered from the erroneous opinion that implementing FTP ought - to be a small and trivial task. This is wrong, because FTP has - a user interface, because it has to deal (correctly) with the - whole variety of communication and operating system errors that - may occur, and because it has to handle the great diversity of - real file systems in the world. - - 4.1.2. PROTOCOL WALK-THROUGH - - 4.1.2.1 LOCAL Type: RFC-959 Section 3.1.1.4 - - An FTP program MUST support TYPE I ("IMAGE" or binary type) - as well as TYPE L 8 ("LOCAL" type with logical byte size 8). - A machine whose memory is organized into m-bit words, where - m is not a multiple of 8, MAY also support TYPE L m. - - DISCUSSION: - The command "TYPE L 8" is often required to transfer - binary data between a machine whose memory is organized - into (e.g.) 36-bit words and a machine with an 8-bit - byte organization. For an 8-bit byte machine, TYPE L 8 - is equivalent to IMAGE. - - "TYPE L m" is sometimes specified to the FTP programs - on two m-bit word machines to ensure the correct - transfer of a native-mode binary file from one machine - to the other. However, this command should have the - same effect on these machines as "TYPE I". - - - - -Internet Engineering Task Force [Page 29] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.2.2 Telnet Format Control: RFC-959 Section 3.1.1.5.2 - - A host that makes no distinction between TYPE N and TYPE T - SHOULD implement TYPE T to be identical to TYPE N. - - DISCUSSION: - This provision should ease interoperation with hosts - that do make this distinction. - - Many hosts represent text files internally as strings - of ASCII characters, using the embedded ASCII format - effector characters (LF, BS, FF, ...) to control the - format when a file is printed. For such hosts, there - is no distinction between "print" files and other - files. However, systems that use record structured - files typically need a special format for printable - files (e.g., ASA carriage control). For the latter - hosts, FTP allows a choice of TYPE N or TYPE T. - - 4.1.2.3 Page Structure: RFC-959 Section 3.1.2.3 and Appendix I - - Implementation of page structure is NOT RECOMMENDED in - general. However, if a host system does need to implement - FTP for "random access" or "holey" files, it MUST use the - defined page structure format rather than define a new - private FTP format. - - 4.1.2.4 Data Structure Transformations: RFC-959 Section 3.1.2 - - An FTP transformation between record-structure and file- - structure SHOULD be invertible, to the extent possible while - making the result useful on the target host. - - DISCUSSION: - RFC-959 required strict invertibility between record- - structure and file-structure, but in practice, - efficiency and convenience often preclude it. - Therefore, the requirement is being relaxed. There are - two different objectives for transferring a file: - processing it on the target host, or just storage. For - storage, strict invertibility is important. For - processing, the file created on the target host needs - to be in the format expected by application programs on - that host. - - As an example of the conflict, imagine a record- - oriented operating system that requires some data files - to have exactly 80 bytes in each record. While STORing - - - -Internet Engineering Task Force [Page 30] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - a file on such a host, an FTP Server must be able to - pad each line or record to 80 bytes; a later retrieval - of such a file cannot be strictly invertible. - - 4.1.2.5 Data Connection Management: RFC-959 Section 3.3 - - A User-FTP that uses STREAM mode SHOULD send a PORT command - to assign a non-default data port before each transfer - command is issued. - - DISCUSSION: - This is required because of the long delay after a TCP - connection is closed until its socket pair can be - reused, to allow multiple transfers during a single FTP - session. Sending a port command can avoided if a - transfer mode other than stream is used, by leaving the - data transfer connection open between transfers. - - 4.1.2.6 PASV Command: RFC-959 Section 4.1.2 - - A server-FTP MUST implement the PASV command. - - If multiple third-party transfers are to be executed during - the same session, a new PASV command MUST be issued before - each transfer command, to obtain a unique port pair. - - IMPLEMENTATION: - The format of the 227 reply to a PASV command is not - well standardized. In particular, an FTP client cannot - assume that the parentheses shown on page 40 of RFC-959 - will be present (and in fact, Figure 3 on page 43 omits - them). Therefore, a User-FTP program that interprets - the PASV reply must scan the reply for the first digit - of the host and port numbers. - - Note that the host number h1,h2,h3,h4 is the IP address - of the server host that is sending the reply, and that - p1,p2 is a non-default data transfer port that PASV has - assigned. - - 4.1.2.7 LIST and NLST Commands: RFC-959 Section 4.1.3 - - The data returned by an NLST command MUST contain only a - simple list of legal pathnames, such that the server can use - them directly as the arguments of subsequent data transfer - commands for the individual files. - - The data returned by a LIST or NLST command SHOULD use an - - - -Internet Engineering Task Force [Page 31] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - implied TYPE AN, unless the current type is EBCDIC, in which - case an implied TYPE EN SHOULD be used. - - DISCUSSION: - Many FTP clients support macro-commands that will get - or put files matching a wildcard specification, using - NLST to obtain a list of pathnames. The expansion of - "multiple-put" is local to the client, but "multiple- - get" requires cooperation by the server. - - The implied type for LIST and NLST is designed to - provide compatibility with existing User-FTPs, and in - particular with multiple-get commands. - - 4.1.2.8 SITE Command: RFC-959 Section 4.1.3 - - A Server-FTP SHOULD use the SITE command for non-standard - features, rather than invent new private commands or - unstandardized extensions to existing commands. - - 4.1.2.9 STOU Command: RFC-959 Section 4.1.3 - - The STOU command stores into a uniquely named file. When it - receives an STOU command, a Server-FTP MUST return the - actual file name in the "125 Transfer Starting" or the "150 - Opening Data Connection" message that precedes the transfer - (the 250 reply code mentioned in RFC-959 is incorrect). The - exact format of these messages is hereby defined to be as - follows: - - 125 FILE: pppp - 150 FILE: pppp - - where pppp represents the unique pathname of the file that - will be written. - - 4.1.2.10 Telnet End-of-line Code: RFC-959, Page 34 - - Implementors MUST NOT assume any correspondence between READ - boundaries on the control connection and the Telnet EOL - sequences (CR LF). - - DISCUSSION: - Thus, a server-FTP (or User-FTP) must continue reading - characters from the control connection until a complete - Telnet EOL sequence is encountered, before processing - the command (or response, respectively). Conversely, a - single READ from the control connection may include - - - -Internet Engineering Task Force [Page 32] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - more than one FTP command. - - 4.1.2.11 FTP Replies: RFC-959 Section 4.2, Page 35 - - A Server-FTP MUST send only correctly formatted replies on - the control connection. Note that RFC-959 (unlike earlier - versions of the FTP spec) contains no provision for a - "spontaneous" reply message. - - A Server-FTP SHOULD use the reply codes defined in RFC-959 - whenever they apply. However, a server-FTP MAY use a - different reply code when needed, as long as the general - rules of Section 4.2 are followed. When the implementor has - a choice between a 4xx and 5xx reply code, a Server-FTP - SHOULD send a 4xx (temporary failure) code when there is any - reasonable possibility that a failed FTP will succeed a few - hours later. - - A User-FTP SHOULD generally use only the highest-order digit - of a 3-digit reply code for making a procedural decision, to - prevent difficulties when a Server-FTP uses non-standard - reply codes. - - A User-FTP MUST be able to handle multi-line replies. If - the implementation imposes a limit on the number of lines - and if this limit is exceeded, the User-FTP MUST recover, - e.g., by ignoring the excess lines until the end of the - multi-line reply is reached. - - A User-FTP SHOULD NOT interpret a 421 reply code ("Service - not available, closing control connection") specially, but - SHOULD detect closing of the control connection by the - server. - - DISCUSSION: - Server implementations that fail to strictly follow the - reply rules often cause FTP user programs to hang. - Note that RFC-959 resolved ambiguities in the reply - rules found in earlier FTP specifications and must be - followed. - - It is important to choose FTP reply codes that properly - distinguish between temporary and permanent failures, - to allow the successful use of file transfer client - daemons. These programs depend on the reply codes to - decide whether or not to retry a failed transfer; using - a permanent failure code (5xx) for a temporary error - will cause these programs to give up unnecessarily. - - - -Internet Engineering Task Force [Page 33] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - When the meaning of a reply matches exactly the text - shown in RFC-959, uniformity will be enhanced by using - the RFC-959 text verbatim. However, a Server-FTP - implementor is encouraged to choose reply text that - conveys specific system-dependent information, when - appropriate. - - 4.1.2.12 Connections: RFC-959 Section 5.2 - - The words "and the port used" in the second paragraph of - this section of RFC-959 are erroneous (historical), and they - should be ignored. - - On a multihomed server host, the default data transfer port - (L-1) MUST be associated with the same local IP address as - the corresponding control connection to port L. - - A user-FTP MUST NOT send any Telnet controls other than - SYNCH and IP on an FTP control connection. In particular, it - MUST NOT attempt to negotiate Telnet options on the control - connection. However, a server-FTP MUST be capable of - accepting and refusing Telnet negotiations (i.e., sending - DONT/WONT). - - DISCUSSION: - Although the RFC says: "Server- and User- processes - should follow the conventions for the Telnet - protocol...[on the control connection]", it is not the - intent that Telnet option negotiation is to be - employed. - - 4.1.2.13 Minimum Implementation; RFC-959 Section 5.1 - - The following commands and options MUST be supported by - every server-FTP and user-FTP, except in cases where the - underlying file system or operating system does not allow or - support a particular command. - - Type: ASCII Non-print, IMAGE, LOCAL 8 - Mode: Stream - Structure: File, Record* - Commands: - USER, PASS, ACCT, - PORT, PASV, - TYPE, MODE, STRU, - RETR, STOR, APPE, - RNFR, RNTO, DELE, - CWD, CDUP, RMD, MKD, PWD, - - - -Internet Engineering Task Force [Page 34] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LIST, NLST, - SYST, STAT, - HELP, NOOP, QUIT. - - *Record structure is REQUIRED only for hosts whose file - systems support record structure. - - DISCUSSION: - Vendors are encouraged to implement a larger subset of - the protocol. For example, there are important - robustness features in the protocol (e.g., Restart, - ABOR, block mode) that would be an aid to some Internet - users but are not widely implemented. - - A host that does not have record structures in its file - system may still accept files with STRU R, recording - the byte stream literally. - - 4.1.3 SPECIFIC ISSUES - - 4.1.3.1 Non-standard Command Verbs - - FTP allows "experimental" commands, whose names begin with - "X". If these commands are subsequently adopted as - standards, there may still be existing implementations using - the "X" form. At present, this is true for the directory - commands: - - RFC-959 "Experimental" - - MKD XMKD - RMD XRMD - PWD XPWD - CDUP XCUP - CWD XCWD - - All FTP implementations SHOULD recognize both forms of these - commands, by simply equating them with extra entries in the - command lookup table. - - IMPLEMENTATION: - A User-FTP can access a server that supports only the - "X" forms by implementing a mode switch, or - automatically using the following procedure: if the - RFC-959 form of one of the above commands is rejected - with a 500 or 502 response code, then try the - experimental form; any other response would be passed - to the user. - - - -Internet Engineering Task Force [Page 35] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.3.2 Idle Timeout - - A Server-FTP process SHOULD have an idle timeout, which will - terminate the process and close the control connection if - the server is inactive (i.e., no command or data transfer in - progress) for a long period of time. The idle timeout time - SHOULD be configurable, and the default should be at least 5 - minutes. - - A client FTP process ("User-PI" in RFC-959) will need - timeouts on responses only if it is invoked from a program. - - DISCUSSION: - Without a timeout, a Server-FTP process may be left - pending indefinitely if the corresponding client - crashes without closing the control connection. - - 4.1.3.3 Concurrency of Data and Control - - DISCUSSION: - The intent of the designers of FTP was that a user - should be able to send a STAT command at any time while - data transfer was in progress and that the server-FTP - would reply immediately with status -- e.g., the number - of bytes transferred so far. Similarly, an ABOR - command should be possible at any time during a data - transfer. - - Unfortunately, some small-machine operating systems - make such concurrent programming difficult, and some - other implementers seek minimal solutions, so some FTP - implementations do not allow concurrent use of the data - and control connections. Even such a minimal server - must be prepared to accept and defer a STAT or ABOR - command that arrives during data transfer. - - 4.1.3.4 FTP Restart Mechanism - - The description of the 110 reply on pp. 40-41 of RFC-959 is - incorrect; the correct description is as follows. A restart - reply message, sent over the control connection from the - receiving FTP to the User-FTP, has the format: - - 110 MARK ssss = rrrr - - Here: - - * ssss is a text string that appeared in a Restart Marker - - - -Internet Engineering Task Force [Page 36] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - in the data stream and encodes a position in the - sender's file system; - - * rrrr encodes the corresponding position in the - receiver's file system. - - The encoding, which is specific to a particular file system - and network implementation, is always generated and - interpreted by the same system, either sender or receiver. - - When an FTP that implements restart receives a Restart - Marker in the data stream, it SHOULD force the data to that - point to be written to stable storage before encoding the - corresponding position rrrr. An FTP sending Restart Markers - MUST NOT assume that 110 replies will be returned - synchronously with the data, i.e., it must not await a 110 - reply before sending more data. - - Two new reply codes are hereby defined for errors - encountered in restarting a transfer: - - 554 Requested action not taken: invalid REST parameter. - - A 554 reply may result from a FTP service command that - follows a REST command. The reply indicates that the - existing file at the Server-FTP cannot be repositioned - as specified in the REST. - - 555 Requested action not taken: type or stru mismatch. - - A 555 reply may result from an APPE command or from any - FTP service command following a REST command. The - reply indicates that there is some mismatch between the - current transfer parameters (type and stru) and the - attributes of the existing file. - - DISCUSSION: - Note that the FTP Restart mechanism requires that Block - or Compressed mode be used for data transfer, to allow - the Restart Markers to be included within the data - stream. The frequency of Restart Markers can be low. - - Restart Markers mark a place in the data stream, but - the receiver may be performing some transformation on - the data as it is stored into stable storage. In - general, the receiver's encoding must include any state - information necessary to restart this transformation at - any point of the FTP data stream. For example, in TYPE - - - -Internet Engineering Task Force [Page 37] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - A transfers, some receiver hosts transform CR LF - sequences into a single LF character on disk. If a - Restart Marker happens to fall between CR and LF, the - receiver must encode in rrrr that the transfer must be - restarted in a "CR has been seen and discarded" state. - - Note that the Restart Marker is required to be encoded - as a string of printable ASCII characters, regardless - of the type of the data. - - RFC-959 says that restart information is to be returned - "to the user". This should not be taken literally. In - general, the User-FTP should save the restart - information (ssss,rrrr) in stable storage, e.g., append - it to a restart control file. An empty restart control - file should be created when the transfer first starts - and deleted automatically when the transfer completes - successfully. It is suggested that this file have a - name derived in an easily-identifiable manner from the - name of the file being transferred and the remote host - name; this is analogous to the means used by many text - editors for naming "backup" files. - - There are three cases for FTP restart. - - (1) User-to-Server Transfer - - The User-FTP puts Restart Markers <ssss> at - convenient places in the data stream. When the - Server-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - transformation state as rrrr, and returns a "110 - MARK ssss = rrrr" reply over the control - connection. The User-FTP appends the pair - (ssss,rrrr) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, repositions its local file system and - transformation state using ssss, and sends the - command "REST rrrr" to the Server-FTP. - - (2) Server-to-User Transfer - - The Server-FTP puts Restart Markers <ssss> at - convenient places in the data stream. When the - User-FTP receives a Marker, it writes all prior - data to disk, encodes its file system position and - - - -Internet Engineering Task Force [Page 38] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - transformation state as rrrr, and appends the pair - (rrrr,ssss) to its restart control file. - - To restart the transfer, the User-FTP fetches the - last (rrrr,ssss) pair from the restart control - file, repositions its local file system and - transformation state using rrrr, and sends the - command "REST ssss" to the Server-FTP. - - (3) Server-to-Server ("Third-Party") Transfer - - The sending Server-FTP puts Restart Markers <ssss> - at convenient places in the data stream. When it - receives a Marker, the receiving Server-FTP writes - all prior data to disk, encodes its file system - position and transformation state as rrrr, and - sends a "110 MARK ssss = rrrr" reply over the - control connection to the User. The User-FTP - appends the pair (ssss,rrrr) to its restart - control file. - - To restart the transfer, the User-FTP fetches the - last (ssss,rrrr) pair from the restart control - file, sends "REST ssss" to the sending Server-FTP, - and sends "REST rrrr" to the receiving Server-FTP. - - - 4.1.4 FTP/USER INTERFACE - - This section discusses the user interface for a User-FTP - program. - - 4.1.4.1 Pathname Specification - - Since FTP is intended for use in a heterogeneous - environment, User-FTP implementations MUST support remote - pathnames as arbitrary character strings, so that their form - and content are not limited by the conventions of the local - operating system. - - DISCUSSION: - In particular, remote pathnames can be of arbitrary - length, and all the printing ASCII characters as well - as space (0x20) must be allowed. RFC-959 allows a - pathname to contain any 7-bit ASCII character except CR - or LF. - - - - - -Internet Engineering Task Force [Page 39] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.4.2 "QUOTE" Command - - A User-FTP program MUST implement a "QUOTE" command that - will pass an arbitrary character string to the server and - display all resulting response messages to the user. - - To make the "QUOTE" command useful, a User-FTP SHOULD send - transfer control commands to the server as the user enters - them, rather than saving all the commands and sending them - to the server only when a data transfer is started. - - DISCUSSION: - The "QUOTE" command is essential to allow the user to - access servers that require system-specific commands - (e.g., SITE or ALLO), or to invoke new or optional - features that are not implemented by the User-FTP. For - example, "QUOTE" may be used to specify "TYPE A T" to - send a print file to hosts that require the - distinction, even if the User-FTP does not recognize - that TYPE. - - 4.1.4.3 Displaying Replies to User - - A User-FTP SHOULD display to the user the full text of all - error reply messages it receives. It SHOULD have a - "verbose" mode in which all commands it sends and the full - text and reply codes it receives are displayed, for - diagnosis of problems. - - 4.1.4.4 Maintaining Synchronization - - The state machine in a User-FTP SHOULD be forgiving of - missing and unexpected reply messages, in order to maintain - command synchronization with the server. - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 40] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - 4.1.5 FTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------|---------------|-|-|-|-|-|-- -Implement TYPE T if same as TYPE N |4.1.2.2 | |x| | | | -File/Record transform invertible if poss. |4.1.2.4 | |x| | | | -User-FTP send PORT cmd for stream mode |4.1.2.5 | |x| | | | -Server-FTP implement PASV |4.1.2.6 |x| | | | | - PASV is per-transfer |4.1.2.6 |x| | | | | -NLST reply usable in RETR cmds |4.1.2.7 |x| | | | | -Implied type for LIST and NLST |4.1.2.7 | |x| | | | -SITE cmd for non-standard features |4.1.2.8 | |x| | | | -STOU cmd return pathname as specified |4.1.2.9 |x| | | | | -Use TCP READ boundaries on control conn. |4.1.2.10 | | | | |x| - | | | | | | | -Server-FTP send only correct reply format |4.1.2.11 |x| | | | | -Server-FTP use defined reply code if poss. |4.1.2.11 | |x| | | | - New reply code following Section 4.2 |4.1.2.11 | | |x| | | -User-FTP use only high digit of reply |4.1.2.11 | |x| | | | -User-FTP handle multi-line reply lines |4.1.2.11 |x| | | | | -User-FTP handle 421 reply specially |4.1.2.11 | | | |x| | - | | | | | | | -Default data port same IP addr as ctl conn |4.1.2.12 |x| | | | | -User-FTP send Telnet cmds exc. SYNCH, IP |4.1.2.12 | | | | |x| -User-FTP negotiate Telnet options |4.1.2.12 | | | | |x| -Server-FTP handle Telnet options |4.1.2.12 |x| | | | | -Handle "Experimental" directory cmds |4.1.3.1 | |x| | | | -Idle timeout in server-FTP |4.1.3.2 | |x| | | | - Configurable idle timeout |4.1.3.2 | |x| | | | -Receiver checkpoint data at Restart Marker |4.1.3.4 | |x| | | | -Sender assume 110 replies are synchronous |4.1.3.4 | | | | |x| - | | | | | | | -Support TYPE: | | | | | | | - ASCII - Non-Print (AN) |4.1.2.13 |x| | | | | - ASCII - Telnet (AT) -- if same as AN |4.1.2.2 | |x| | | | - ASCII - Carriage Control (AC) |959 3.1.1.5.2 | | |x| | | - EBCDIC - (any form) |959 3.1.1.2 | | |x| | | - IMAGE |4.1.2.1 |x| | | | | - LOCAL 8 |4.1.2.1 |x| | | | | - - - -Internet Engineering Task Force [Page 41] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - - LOCAL m |4.1.2.1 | | |x| | |2 - | | | | | | | -Support MODE: | | | | | | | - Stream |4.1.2.13 |x| | | | | - Block |959 3.4.2 | | |x| | | - | | | | | | | -Support STRUCTURE: | | | | | | | - File |4.1.2.13 |x| | | | | - Record |4.1.2.13 |x| | | | |3 - Page |4.1.2.3 | | | |x| | - | | | | | | | -Support commands: | | | | | | | - USER |4.1.2.13 |x| | | | | - PASS |4.1.2.13 |x| | | | | - ACCT |4.1.2.13 |x| | | | | - CWD |4.1.2.13 |x| | | | | - CDUP |4.1.2.13 |x| | | | | - SMNT |959 5.3.1 | | |x| | | - REIN |959 5.3.1 | | |x| | | - QUIT |4.1.2.13 |x| | | | | - | | | | | | | - PORT |4.1.2.13 |x| | | | | - PASV |4.1.2.6 |x| | | | | - TYPE |4.1.2.13 |x| | | | |1 - STRU |4.1.2.13 |x| | | | |1 - MODE |4.1.2.13 |x| | | | |1 - | | | | | | | - RETR |4.1.2.13 |x| | | | | - STOR |4.1.2.13 |x| | | | | - STOU |959 5.3.1 | | |x| | | - APPE |4.1.2.13 |x| | | | | - ALLO |959 5.3.1 | | |x| | | - REST |959 5.3.1 | | |x| | | - RNFR |4.1.2.13 |x| | | | | - RNTO |4.1.2.13 |x| | | | | - ABOR |959 5.3.1 | | |x| | | - DELE |4.1.2.13 |x| | | | | - RMD |4.1.2.13 |x| | | | | - MKD |4.1.2.13 |x| | | | | - PWD |4.1.2.13 |x| | | | | - LIST |4.1.2.13 |x| | | | | - NLST |4.1.2.13 |x| | | | | - SITE |4.1.2.8 | | |x| | | - STAT |4.1.2.13 |x| | | | | - SYST |4.1.2.13 |x| | | | | - HELP |4.1.2.13 |x| | | | | - NOOP |4.1.2.13 |x| | | | | - | | | | | | | - - - -Internet Engineering Task Force [Page 42] - - - - -RFC1123 FILE TRANSFER -- FTP October 1989 - - -User Interface: | | | | | | | - Arbitrary pathnames |4.1.4.1 |x| | | | | - Implement "QUOTE" command |4.1.4.2 |x| | | | | - Transfer control commands immediately |4.1.4.2 | |x| | | | - Display error messages to user |4.1.4.3 | |x| | | | - Verbose mode |4.1.4.3 | |x| | | | - Maintain synchronization with server |4.1.4.4 | |x| | | | - -Footnotes: - -(1) For the values shown earlier. - -(2) Here m is number of bits in a memory word. - -(3) Required for host with record-structured file system, optional - otherwise. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 43] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - 4.2 TRIVIAL FILE TRANSFER PROTOCOL -- TFTP - - 4.2.1 INTRODUCTION - - The Trivial File Transfer Protocol TFTP is defined in RFC-783 - [TFTP:1]. - - TFTP provides its own reliable delivery with UDP as its - transport protocol, using a simple stop-and-wait acknowledgment - system. Since TFTP has an effective window of only one 512 - octet segment, it can provide good performance only over paths - that have a small delay*bandwidth product. The TFTP file - interface is very simple, providing no access control or - security. - - TFTP's most important application is bootstrapping a host over - a local network, since it is simple and small enough to be - easily implemented in EPROM [BOOT:1, BOOT:2]. Vendors are - urged to support TFTP for booting. - - 4.2.2 PROTOCOL WALK-THROUGH - - The TFTP specification [TFTP:1] is written in an open style, - and does not fully specify many parts of the protocol. - - 4.2.2.1 Transfer Modes: RFC-783, Page 3 - - The transfer mode "mail" SHOULD NOT be supported. - - 4.2.2.2 UDP Header: RFC-783, Page 17 - - The Length field of a UDP header is incorrectly defined; it - includes the UDP header length (8). - - 4.2.3 SPECIFIC ISSUES - - 4.2.3.1 Sorcerer's Apprentice Syndrome - - There is a serious bug, known as the "Sorcerer's Apprentice - Syndrome," in the protocol specification. While it does not - cause incorrect operation of the transfer (the file will - always be transferred correctly if the transfer completes), - this bug may cause excessive retransmission, which may cause - the transfer to time out. - - Implementations MUST contain the fix for this problem: the - sender (i.e., the side originating the DATA packets) must - never resend the current DATA packet on receipt of a - - - -Internet Engineering Task Force [Page 44] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - duplicate ACK. - - DISCUSSION: - The bug is caused by the protocol rule that either - side, on receiving an old duplicate datagram, may - resend the current datagram. If a packet is delayed in - the network but later successfully delivered after - either side has timed out and retransmitted a packet, a - duplicate copy of the response may be generated. If - the other side responds to this duplicate with a - duplicate of its own, then every datagram will be sent - in duplicate for the remainder of the transfer (unless - a datagram is lost, breaking the repetition). Worse - yet, since the delay is often caused by congestion, - this duplicate transmission will usually causes more - congestion, leading to more delayed packets, etc. - - The following example may help to clarify this problem. - - TFTP A TFTP B - - (1) Receive ACK X-1 - Send DATA X - (2) Receive DATA X - Send ACK X - (ACK X is delayed in network, - and A times out): - (3) Retransmit DATA X - - (4) Receive DATA X again - Send ACK X again - (5) Receive (delayed) ACK X - Send DATA X+1 - (6) Receive DATA X+1 - Send ACK X+1 - (7) Receive ACK X again - Send DATA X+1 again - (8) Receive DATA X+1 again - Send ACK X+1 again - (9) Receive ACK X+1 - Send DATA X+2 - (10) Receive DATA X+2 - Send ACK X+3 - (11) Receive ACK X+1 again - Send DATA X+2 again - (12) Receive DATA X+2 again - Send ACK X+3 again - - - - -Internet Engineering Task Force [Page 45] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - Notice that once the delayed ACK arrives, the protocol - settles down to duplicate all further packets - (sequences 5-8 and 9-12). The problem is caused not by - either side timing out, but by both sides - retransmitting the current packet when they receive a - duplicate. - - The fix is to break the retransmission loop, as - indicated above. This is analogous to the behavior of - TCP. It is then possible to remove the retransmission - timer on the receiver, since the resent ACK will never - cause any action; this is a useful simplification where - TFTP is used in a bootstrap program. It is OK to allow - the timer to remain, and it may be helpful if the - retransmitted ACK replaces one that was genuinely lost - in the network. The sender still requires a retransmit - timer, of course. - - 4.2.3.2 Timeout Algorithms - - A TFTP implementation MUST use an adaptive timeout. - - IMPLEMENTATION: - TCP retransmission algorithms provide a useful base to - work from. At least an exponential backoff of - retransmission timeout is necessary. - - 4.2.3.3 Extensions - - A variety of non-standard extensions have been made to TFTP, - including additional transfer modes and a secure operation - mode (with passwords). None of these have been - standardized. - - 4.2.3.4 Access Control - - A server TFTP implementation SHOULD include some - configurable access control over what pathnames are allowed - in TFTP operations. - - 4.2.3.5 Broadcast Request - - A TFTP request directed to a broadcast address SHOULD be - silently ignored. - - DISCUSSION: - Due to the weak access control capability of TFTP, - directed broadcasts of TFTP requests to random networks - - - -Internet Engineering Task Force [Page 46] - - - - -RFC1123 FILE TRANSFER -- TFTP October 1989 - - - could create a significant security hole. - - 4.2.4 TFTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e --------------------------------------------------|--------|-|-|-|-|-|-- -Fix Sorcerer's Apprentice Syndrome |4.2.3.1 |x| | | | | -Transfer modes: | | | | | | | - netascii |RFC-783 |x| | | | | - octet |RFC-783 |x| | | | | - mail |4.2.2.1 | | | |x| | - extensions |4.2.3.3 | | |x| | | -Use adaptive timeout |4.2.3.2 |x| | | | | -Configurable access control |4.2.3.4 | |x| | | | -Silently ignore broadcast request |4.2.3.5 | |x| | | | --------------------------------------------------|--------|-|-|-|-|-|-- --------------------------------------------------|--------|-|-|-|-|-|-- - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 47] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - -5. ELECTRONIC MAIL -- SMTP and RFC-822 - - 5.1 INTRODUCTION - - In the TCP/IP protocol suite, electronic mail in a format - specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail - Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1]. - - While SMTP has remained unchanged over the years, the Internet - community has made several changes in the way SMTP is used. In - particular, the conversion to the Domain Name System (DNS) has - caused changes in address formats and in mail routing. In this - section, we assume familiarity with the concepts and terminology - of the DNS, whose requirements are given in Section 6.1. - - RFC-822 specifies the Internet standard format for electronic mail - messages. RFC-822 supercedes an older standard, RFC-733, that may - still be in use in a few places, although it is obsolete. The two - formats are sometimes referred to simply by number ("822" and - "733"). - - RFC-822 is used in some non-Internet mail environments with - different mail transfer protocols than SMTP, and SMTP has also - been adapted for use in some non-Internet environments. Note that - this document presents the rules for the use of SMTP and RFC-822 - for the Internet environment only; other mail environments that - use these protocols may be expected to have their own rules. - - 5.2 PROTOCOL WALK-THROUGH - - This section covers both RFC-821 and RFC-822. - - The SMTP specification in RFC-821 is clear and contains numerous - examples, so implementors should not find it difficult to - understand. This section simply updates or annotates portions of - RFC-821 to conform with current usage. - - RFC-822 is a long and dense document, defining a rich syntax. - Unfortunately, incomplete or defective implementations of RFC-822 - are common. In fact, nearly all of the many formats of RFC-822 - are actually used, so an implementation generally needs to - recognize and correctly interpret all of the RFC-822 syntax. - - 5.2.1 The SMTP Model: RFC-821 Section 2 - - DISCUSSION: - Mail is sent by a series of request/response transactions - between a client, the "sender-SMTP," and a server, the - - - -Internet Engineering Task Force [Page 48] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "receiver-SMTP". These transactions pass (1) the message - proper, which is composed of header and body, and (2) SMTP - source and destination addresses, referred to as the - "envelope". - - The SMTP programs are analogous to Message Transfer Agents - (MTAs) of X.400. There will be another level of protocol - software, closer to the end user, that is responsible for - composing and analyzing RFC-822 message headers; this - component is known as the "User Agent" in X.400, and we - use that term in this document. There is a clear logical - distinction between the User Agent and the SMTP - implementation, since they operate on different levels of - protocol. Note, however, that this distinction is may not - be exactly reflected the structure of typical - implementations of Internet mail. Often there is a - program known as the "mailer" that implements SMTP and - also some of the User Agent functions; the rest of the - User Agent functions are included in a user interface used - for entering and reading mail. - - The SMTP envelope is constructed at the originating site, - typically by the User Agent when the message is first - queued for the Sender-SMTP program. The envelope - addresses may be derived from information in the message - header, supplied by the user interface (e.g., to implement - a bcc: request), or derived from local configuration - information (e.g., expansion of a mailing list). The SMTP - envelope cannot in general be re-derived from the header - at a later stage in message delivery, so the envelope is - transmitted separately from the message itself using the - MAIL and RCPT commands of SMTP. - - The text of RFC-821 suggests that mail is to be delivered - to an individual user at a host. With the advent of the - domain system and of mail routing using mail-exchange (MX) - resource records, implementors should now think of - delivering mail to a user at a domain, which may or may - not be a particular host. This DOES NOT change the fact - that SMTP is a host-to-host mail exchange protocol. - - 5.2.2 Canonicalization: RFC-821 Section 3.1 - - The domain names that a Sender-SMTP sends in MAIL and RCPT - commands MUST have been "canonicalized," i.e., they must be - fully-qualified principal names or domain literals, not - nicknames or domain abbreviations. A canonicalized name either - identifies a host directly or is an MX name; it cannot be a - - - -Internet Engineering Task Force [Page 49] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - CNAME. - - 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3 - - A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN - (this requirement overrides RFC-821). However, there MAY be - configuration information to disable VRFY and EXPN in a - particular installation; this might even allow EXPN to be - disabled for selected lists. - - A new reply code is defined for the VRFY command: - - 252 Cannot VRFY user (e.g., info is not local), but will - take message for this user and attempt delivery. - - DISCUSSION: - SMTP users and administrators make regular use of these - commands for diagnosing mail delivery problems. With the - increasing use of multi-level mailing list expansion - (sometimes more than two levels), EXPN has been - increasingly important for diagnosing inadvertent mail - loops. On the other hand, some feel that EXPN represents - a significant privacy, and perhaps even a security, - exposure. - - 5.2.4 SEND, SOML, and SAML Commands: RFC-821 Section 3.4 - - An SMTP MAY implement the commands to send a message to a - user's terminal: SEND, SOML, and SAML. - - DISCUSSION: - It has been suggested that the use of mail relaying - through an MX record is inconsistent with the intent of - SEND to deliver a message immediately and directly to a - user's terminal. However, an SMTP receiver that is unable - to write directly to the user terminal can return a "251 - User Not Local" reply to the RCPT following a SEND, to - inform the originator of possibly deferred delivery. - - 5.2.5 HELO Command: RFC-821 Section 3.5 - - The sender-SMTP MUST ensure that the <domain> parameter in a - HELO command is a valid principal host domain name for the - client host. As a result, the receiver-SMTP will not have to - perform MX resolution on this name in order to validate the - HELO parameter. - - The HELO receiver MAY verify that the HELO parameter really - - - -Internet Engineering Task Force [Page 50] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - corresponds to the IP address of the sender. However, the - receiver MUST NOT refuse to accept a message, even if the - sender's HELO command fails verification. - - DISCUSSION: - Verifying the HELO parameter requires a domain name lookup - and may therefore take considerable time. An alternative - tool for tracking bogus mail sources is suggested below - (see "DATA Command"). - - Note also that the HELO argument is still required to have - valid <domain> syntax, since it will appear in a Received: - line; otherwise, a 501 error is to be sent. - - IMPLEMENTATION: - When HELO parameter validation fails, a suggested - procedure is to insert a note about the unknown - authenticity of the sender into the message header (e.g., - in the "Received:" line). - - 5.2.6 Mail Relay: RFC-821 Section 3.6 - - We distinguish three types of mail (store-and-) forwarding: - - (1) A simple forwarder or "mail exchanger" forwards a message - using private knowledge about the recipient; see section - 3.2 of RFC-821. - - (2) An SMTP mail "relay" forwards a message within an SMTP - mail environment as the result of an explicit source route - (as defined in section 3.6 of RFC-821). The SMTP relay - function uses the "@...:" form of source route from RFC- - 822 (see Section 5.2.19 below). - - (3) A mail "gateway" passes a message between different - environments. The rules for mail gateways are discussed - below in Section 5.3.7. - - An Internet host that is forwarding a message but is not a - gateway to a different mail environment (i.e., it falls under - (1) or (2)) SHOULD NOT alter any existing header fields, - although the host will add an appropriate Received: line as - required in Section 5.2.8. - - A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an - explicit source route using the "@...:" address form. Thus, - the relay function defined in section 3.6 of RFC-821 should - not be used. - - - -Internet Engineering Task Force [Page 51] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - The intent is to discourage all source routing and to - abolish explicit source routing for mail delivery within - the Internet environment. Source-routing is unnecessary; - the simple target address "user@domain" should always - suffice. This is the result of an explicit architectural - decision to use universal naming rather than source - routing for mail. Thus, SMTP provides end-to-end - connectivity, and the DNS provides globally-unique, - location-independent names. MX records handle the major - case where source routing might otherwise be needed. - - A receiver-SMTP MUST accept the explicit source route syntax in - the envelope, but it MAY implement the relay function as - defined in section 3.6 of RFC-821. If it does not implement - the relay function, it SHOULD attempt to deliver the message - directly to the host to the right of the right-most "@" sign. - - DISCUSSION: - For example, suppose a host that does not implement the - relay function receives a message with the SMTP command: - "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and - GAMMA represent domain names. Rather than immediately - refusing the message with a 550 error reply as suggested - on page 20 of RFC-821, the host should try to forward the - message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>". - Since this host does not support relaying, it is not - required to update the reverse path. - - Some have suggested that source routing may be needed - occasionally for manually routing mail around failures; - however, the reality and importance of this need is - controversial. The use of explicit SMTP mail relaying for - this purpose is discouraged, and in fact it may not be - successful, as many host systems do not support it. Some - have used the "%-hack" (see Section 5.2.16) for this - purpose. - - 5.2.7 RCPT Command: RFC-821 Section 4.1.1 - - A host that supports a receiver-SMTP MUST support the reserved - mailbox "Postmaster". - - The receiver-SMTP MAY verify RCPT parameters as they arrive; - however, RCPT responses MUST NOT be delayed beyond a reasonable - time (see Section 5.3.2). - - Therefore, a "250 OK" response to a RCPT does not necessarily - - - -Internet Engineering Task Force [Page 52] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - imply that the delivery address(es) are valid. Errors found - after message acceptance will be reported by mailing a - notification message to an appropriate address (see Section - 5.3.3). - - DISCUSSION: - The set of conditions under which a RCPT parameter can be - validated immediately is an engineering design choice. - Reporting destination mailbox errors to the Sender-SMTP - before mail is transferred is generally desirable to save - time and network bandwidth, but this advantage is lost if - RCPT verification is lengthy. - - For example, the receiver can verify immediately any - simple local reference, such as a single locally- - registered mailbox. On the other hand, the "reasonable - time" limitation generally implies deferring verification - of a mailing list until after the message has been - transferred and accepted, since verifying a large mailing - list can take a very long time. An implementation might - or might not choose to defer validation of addresses that - are non-local and therefore require a DNS lookup. If a - DNS lookup is performed but a soft domain system error - (e.g., timeout) occurs, validity must be assumed. - - 5.2.8 DATA Command: RFC-821 Section 4.1.1 - - Every receiver-SMTP (not just one that "accepts a message for - relaying or for final delivery" [SMTP:1]) MUST insert a - "Received:" line at the beginning of a message. In this line, - called a "time stamp line" in RFC-821: - - * The FROM field SHOULD contain both (1) the name of the - source host as presented in the HELO command and (2) a - domain literal containing the IP address of the source, - determined from the TCP connection. - - * The ID field MAY contain an "@" as suggested in RFC-822, - but this is not required. - - * The FOR field MAY contain a list of <path> entries when - multiple RCPT commands have been given. - - - An Internet mail program MUST NOT change a Received: line that - was previously added to the message header. - - - - - -Internet Engineering Task Force [Page 53] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Including both the source host and the IP source address - in the Received: line may provide enough information for - tracking illicit mail sources and eliminate a need to - explicitly verify the HELO parameter. - - Received: lines are primarily intended for humans tracing - mail routes, primarily of diagnosis of faults. See also - the discussion under 5.3.7. - - When the receiver-SMTP makes "final delivery" of a message, - then it MUST pass the MAIL FROM: address from the SMTP envelope - with the message, for use if an error notification message must - be sent later (see Section 5.3.3). There is an analogous - requirement when gatewaying from the Internet into a different - mail environment; see Section 5.3.7. - - DISCUSSION: - Note that the final reply to the DATA command depends only - upon the successful transfer and storage of the message. - Any problem with the destination address(es) must either - (1) have been reported in an SMTP error reply to the RCPT - command(s), or (2) be reported in a later error message - mailed to the originator. - - IMPLEMENTATION: - The MAIL FROM: information may be passed as a parameter or - in a Return-Path: line inserted at the beginning of the - message. - - 5.2.9 Command Syntax: RFC-821 Section 4.1.2 - - The syntax shown in RFC-821 for the MAIL FROM: command omits - the case of an empty path: "MAIL FROM: <>" (see RFC-821 Page - 15). An empty reverse path MUST be supported. - - 5.2.10 SMTP Replies: RFC-821 Section 4.2 - - A receiver-SMTP SHOULD send only the reply codes listed in - section 4.2.2 of RFC-821 or in this document. A receiver-SMTP - SHOULD use the text shown in examples in RFC-821 whenever - appropriate. - - A sender-SMTP MUST determine its actions only by the reply - code, not by the text (except for 251 and 551 replies); any - text, including no text at all, must be acceptable. The space - (blank) following the reply code is considered part of the - text. Whenever possible, a sender-SMTP SHOULD test only the - - - -Internet Engineering Task Force [Page 54] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - first digit of the reply code, as specified in Appendix E of - RFC-821. - - DISCUSSION: - Interoperability problems have arisen with SMTP systems - using reply codes that are not listed explicitly in RFC- - 821 Section 4.3 but are legal according to the theory of - reply codes explained in Appendix E. - - 5.2.11 Transparency: RFC-821 Section 4.5.2 - - Implementors MUST be sure that their mail systems always add - and delete periods to ensure message transparency. - - 5.2.12 WKS Use in MX Processing: RFC-974, p. 5 - - RFC-974 [SMTP:3] recommended that the domain system be queried - for WKS ("Well-Known Service") records, to verify that each - proposed mail target does support SMTP. Later experience has - shown that WKS is not widely supported, so the WKS step in MX - processing SHOULD NOT be used. - - The following are notes on RFC-822, organized by section of that - document. - - 5.2.13 RFC-822 Message Specification: RFC-822 Section 4 - - The syntax shown for the Return-path line omits the possibility - of a null return path, which is used to prevent looping of - error notifications (see Section 5.3.3). The complete syntax - is: - - return = "Return-path" ":" route-addr - / "Return-path" ":" "<" ">" - - The set of optional header fields is hereby expanded to include - the Content-Type field defined in RFC-1049 [SMTP:7]. This - field "allows mail reading systems to automatically identify - the type of a structured message body and to process it for - display accordingly". [SMTP:7] A User Agent MAY support this - field. - - 5.2.14 RFC-822 Date and Time Specification: RFC-822 Section 5 - - The syntax for the date is hereby changed to: - - date = 1*2DIGIT month 2*4DIGIT - - - - -Internet Engineering Task Force [Page 55] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - All mail software SHOULD use 4-digit years in dates, to ease - the transition to the next century. - - There is a strong trend towards the use of numeric timezone - indicators, and implementations SHOULD use numeric timezones - instead of timezone names. However, all implementations MUST - accept either notation. If timezone names are used, they MUST - be exactly as defined in RFC-822. - - The military time zones are specified incorrectly in RFC-822: - they count the wrong way from UT (the signs are reversed). As - a result, military time zones in RFC-822 headers carry no - information. - - Finally, note that there is a typo in the definition of "zone" - in the syntax summary of appendix D; the correct definition - occurs in Section 3 of RFC-822. - - 5.2.15 RFC-822 Syntax Change: RFC-822 Section 6.1 - - The syntactic definition of "mailbox" in RFC-822 is hereby - changed to: - - mailbox = addr-spec ; simple address - / [phrase] route-addr ; name & addr-spec - - That is, the phrase preceding a route address is now OPTIONAL. - This change makes the following header field legal, for - example: - - From: <craig@nnsc.nsf.net> - - 5.2.16 RFC-822 Local-part: RFC-822 Section 6.2 - - The basic mailbox address specification has the form: "local- - part@domain". Here "local-part", sometimes called the "left- - hand side" of the address, is domain-dependent. - - A host that is forwarding the message but is not the - destination host implied by the right-hand side "domain" MUST - NOT interpret or modify the "local-part" of the address. - - When mail is to be gatewayed from the Internet mail environment - into a foreign mail environment (see Section 5.3.7), routing - information for that foreign environment MAY be embedded within - the "local-part" of the address. The gateway will then - interpret this local part appropriately for the foreign mail - environment. - - - -Internet Engineering Task Force [Page 56] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - DISCUSSION: - Although source routes are discouraged within the Internet - (see Section 5.2.6), there are non-Internet mail - environments whose delivery mechanisms do depend upon - source routes. Source routes for extra-Internet - environments can generally be buried in the "local-part" - of the address (see Section 5.2.16) while mail traverses - the Internet. When the mail reaches the appropriate - Internet mail gateway, the gateway will interpret the - local-part and build the necessary address or route for - the target mail environment. - - For example, an Internet host might send mail to: - "a!b!c!user@gateway-domain". The complex local part - "a!b!c!user" would be uninterpreted within the Internet - domain, but could be parsed and understood by the - specified mail gateway. - - An embedded source route is sometimes encoded in the - "local-part" using "%" as a right-binding routing - operator. For example, in: - - user%domain%relay3%relay2@relay1 - - the "%" convention implies that the mail is to be routed - from "relay1" through "relay2", "relay3", and finally to - "user" at "domain". This is commonly known as the "%- - hack". It is suggested that "%" have lower precedence - than any other routing operator (e.g., "!") hidden in the - local-part; for example, "a!b%c" would be interpreted as - "(a!b)%c". - - Only the target host (in this case, "relay1") is permitted - to analyze the local-part "user%domain%relay3%relay2". - - 5.2.17 Domain Literals: RFC-822 Section 6.2.3 - - A mailer MUST be able to accept and parse an Internet domain - literal whose content ("dtext"; see RFC-822) is a dotted- - decimal host address. This satisfies the requirement of - Section 2.1 for the case of mail. - - An SMTP MUST accept and recognize a domain literal for any of - its own IP addresses. - - - - - - - -Internet Engineering Task Force [Page 57] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.2.18 Common Address Formatting Errors: RFC-822 Section 6.1 - - Errors in formatting or parsing 822 addresses are unfortunately - common. This section mentions only the most common errors. A - User Agent MUST accept all valid RFC-822 address formats, and - MUST NOT generate illegal address syntax. - - o A common error is to leave out the semicolon after a group - identifier. - - o Some systems fail to fully-qualify domain names in - messages they generate. The right-hand side of an "@" - sign in a header address field MUST be a fully-qualified - domain name. - - For example, some systems fail to fully-qualify the From: - address; this prevents a "reply" command in the user - interface from automatically constructing a return - address. - - DISCUSSION: - Although RFC-822 allows the local use of abbreviated - domain names within a domain, the application of - RFC-822 in Internet mail does not allow this. The - intent is that an Internet host must not send an SMTP - message header containing an abbreviated domain name - in an address field. This allows the address fields - of the header to be passed without alteration across - the Internet, as required in Section 5.2.6. - - o Some systems mis-parse multiple-hop explicit source routes - such as: - - @relay1,@relay2,@relay3:user@domain. - - - o Some systems over-qualify domain names by adding a - trailing dot to some or all domain names in addresses or - message-ids. This violates RFC-822 syntax. - - - 5.2.19 Explicit Source Routes: RFC-822 Section 6.2.7 - - Internet host software SHOULD NOT create an RFC-822 header - containing an address with an explicit source route, but MUST - accept such headers for compatibility with earlier systems. - - DISCUSSION: - - - -Internet Engineering Task Force [Page 58] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - In an understatement, RFC-822 says "The use of explicit - source routing is discouraged". Many hosts implemented - RFC-822 source routes incorrectly, so the syntax cannot be - used unambiguously in practice. Many users feel the - syntax is ugly. Explicit source routes are not needed in - the mail envelope for delivery; see Section 5.2.6. For - all these reasons, explicit source routes using the RFC- - 822 notations are not to be used in Internet mail headers. - - As stated in Section 5.2.16, it is necessary to allow an - explicit source route to be buried in the local-part of an - address, e.g., using the "%-hack", in order to allow mail - to be gatewayed into another environment in which explicit - source routing is necessary. The vigilant will observe - that there is no way for a User Agent to detect and - prevent the use of such implicit source routing when the - destination is within the Internet. We can only - discourage source routing of any kind within the Internet, - as unnecessary and undesirable. - - 5.3 SPECIFIC ISSUES - - 5.3.1 SMTP Queueing Strategies - - The common structure of a host SMTP implementation includes - user mailboxes, one or more areas for queueing messages in - transit, and one or more daemon processes for sending and - receiving mail. The exact structure will vary depending on the - needs of the users on the host and the number and size of - mailing lists supported by the host. We describe several - optimizations that have proved helpful, particularly for - mailers supporting high traffic levels. - - Any queueing strategy MUST include: - - o Timeouts on all activities. See Section 5.3.2. - - o Never sending error messages in response to error - messages. - - - 5.3.1.1 Sending Strategy - - The general model of a sender-SMTP is one or more processes - that periodically attempt to transmit outgoing mail. In a - typical system, the program that composes a message has some - method for requesting immediate attention for a new piece of - outgoing mail, while mail that cannot be transmitted - - - -Internet Engineering Task Force [Page 59] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - immediately MUST be queued and periodically retried by the - sender. A mail queue entry will include not only the - message itself but also the envelope information. - - The sender MUST delay retrying a particular destination - after one attempt has failed. In general, the retry - interval SHOULD be at least 30 minutes; however, more - sophisticated and variable strategies will be beneficial - when the sender-SMTP can determine the reason for non- - delivery. - - Retries continue until the message is transmitted or the - sender gives up; the give-up time generally needs to be at - least 4-5 days. The parameters to the retry algorithm MUST - be configurable. - - A sender SHOULD keep a list of hosts it cannot reach and - corresponding timeouts, rather than just retrying queued - mail items. - - DISCUSSION: - Experience suggests that failures are typically - transient (the target system has crashed), favoring a - policy of two connection attempts in the first hour the - message is in the queue, and then backing off to once - every two or three hours. - - The sender-SMTP can shorten the queueing delay by - cooperation with the receiver-SMTP. In particular, if - mail is received from a particular address, it is good - evidence that any mail queued for that host can now be - sent. - - The strategy may be further modified as a result of - multiple addresses per host (see Section 5.3.4), to - optimize delivery time vs. resource usage. - - A sender-SMTP may have a large queue of messages for - each unavailable destination host, and if it retried - all these messages in every retry cycle, there would be - excessive Internet overhead and the daemon would be - blocked for a long period. Note that an SMTP can - generally determine that a delivery attempt has failed - only after a timeout of a minute or more; a one minute - timeout per connection will result in a very large - delay if it is repeated for dozens or even hundreds of - queued messages. - - - - -Internet Engineering Task Force [Page 60] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - When the same message is to be delivered to several users on - the same host, only one copy of the message SHOULD be - transmitted. That is, the sender-SMTP should use the - command sequence: RCPT, RCPT,... RCPT, DATA instead of the - sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA. - Implementation of this efficiency feature is strongly urged. - - Similarly, the sender-SMTP MAY support multiple concurrent - outgoing mail transactions to achieve timely delivery. - However, some limit SHOULD be imposed to protect the host - from devoting all its resources to mail. - - The use of the different addresses of a multihomed host is - discussed below. - - 5.3.1.2 Receiving strategy - - The receiver-SMTP SHOULD attempt to keep a pending listen on - the SMTP port at all times. This will require the support - of multiple incoming TCP connections for SMTP. Some limit - MAY be imposed. - - IMPLEMENTATION: - When the receiver-SMTP receives mail from a particular - host address, it could notify the sender-SMTP to retry - any mail pending for that host address. - - 5.3.2 Timeouts in SMTP - - There are two approaches to timeouts in the sender-SMTP: (a) - limit the time for each SMTP command separately, or (b) limit - the time for the entire SMTP dialogue for a single mail - message. A sender-SMTP SHOULD use option (a), per-command - timeouts. Timeouts SHOULD be easily reconfigurable, preferably - without recompiling the SMTP code. - - DISCUSSION: - Timeouts are an essential feature of an SMTP - implementation. If the timeouts are too long (or worse, - there are no timeouts), Internet communication failures or - software bugs in receiver-SMTP programs can tie up SMTP - processes indefinitely. If the timeouts are too short, - resources will be wasted with attempts that time out part - way through message delivery. - - If option (b) is used, the timeout has to be very large, - e.g., an hour, to allow time to expand very large mailing - lists. The timeout may also need to increase linearly - - - -Internet Engineering Task Force [Page 61] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - with the size of the message, to account for the time to - transmit a very large message. A large fixed timeout - leads to two problems: a failure can still tie up the - sender for a very long time, and very large messages may - still spuriously time out (which is a wasteful failure!). - - Using the recommended option (a), a timer is set for each - SMTP command and for each buffer of the data transfer. - The latter means that the overall timeout is inherently - proportional to the size of the message. - - Based on extensive experience with busy mail-relay hosts, the - minimum per-command timeout values SHOULD be as follows: - - o Initial 220 Message: 5 minutes - - A Sender-SMTP process needs to distinguish between a - failed TCP connection and a delay in receiving the initial - 220 greeting message. Many receiver-SMTPs will accept a - TCP connection but delay delivery of the 220 message until - their system load will permit more mail to be processed. - - o MAIL Command: 5 minutes - - - o RCPT Command: 5 minutes - - A longer timeout would be required if processing of - mailing lists and aliases were not deferred until after - the message was accepted. - - o DATA Initiation: 2 minutes - - This is while awaiting the "354 Start Input" reply to a - DATA command. - - o Data Block: 3 minutes - - This is while awaiting the completion of each TCP SEND - call transmitting a chunk of data. - - o DATA Termination: 10 minutes. - - This is while awaiting the "250 OK" reply. When the - receiver gets the final period terminating the message - data, it typically performs processing to deliver the - message to a user mailbox. A spurious timeout at this - point would be very wasteful, since the message has been - - - -Internet Engineering Task Force [Page 62] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - successfully sent. - - A receiver-SMTP SHOULD have a timeout of at least 5 minutes - while it is awaiting the next command from the sender. - - 5.3.3 Reliable Mail Receipt - - When the receiver-SMTP accepts a piece of mail (by sending a - "250 OK" message in response to DATA), it is accepting - responsibility for delivering or relaying the message. It must - take this responsibility seriously, i.e., it MUST NOT lose the - message for frivolous reasons, e.g., because the host later - crashes or because of a predictable resource shortage. - - If there is a delivery failure after acceptance of a message, - the receiver-SMTP MUST formulate and mail a notification - message. This notification MUST be sent using a null ("<>") - reverse path in the envelope; see Section 3.6 of RFC-821. The - recipient of this notification SHOULD be the address from the - envelope return path (or the Return-Path: line). However, if - this address is null ("<>"), the receiver-SMTP MUST NOT send a - notification. If the address is an explicit source route, it - SHOULD be stripped down to its final hop. - - DISCUSSION: - For example, suppose that an error notification must be - sent for a message that arrived with: - "MAIL FROM:<@a,@b:user@d>". The notification message - should be sent to: "RCPT TO:<user@d>". - - Some delivery failures after the message is accepted by - SMTP will be unavoidable. For example, it may be - impossible for the receiver-SMTP to validate all the - delivery addresses in RCPT command(s) due to a "soft" - domain system error or because the target is a mailing - list (see earlier discussion of RCPT). - - To avoid receiving duplicate messages as the result of - timeouts, a receiver-SMTP MUST seek to minimize the time - required to respond to the final "." that ends a message - transfer. See RFC-1047 [SMTP:4] for a discussion of this - problem. - - 5.3.4 Reliable Mail Transmission - - To transmit a message, a sender-SMTP determines the IP address - of the target host from the destination address in the - envelope. Specifically, it maps the string to the right of the - - - -Internet Engineering Task Force [Page 63] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - "@" sign into an IP address. This mapping or the transfer - itself may fail with a soft error, in which case the sender- - SMTP will requeue the outgoing mail for a later retry, as - required in Section 5.3.1.1. - - When it succeeds, the mapping can result in a list of - alternative delivery addresses rather than a single address, - because of (a) multiple MX records, (b) multihoming, or both. - To provide reliable mail transmission, the sender-SMTP MUST be - able to try (and retry) each of the addresses in this list in - order, until a delivery attempt succeeds. However, there MAY - also be a configurable limit on the number of alternate - addresses that can be tried. In any case, a host SHOULD try at - least two addresses. - - The following information is to be used to rank the host - addresses: - - (1) Multiple MX Records -- these contain a preference - indication that should be used in sorting. If there are - multiple destinations with the same preference and there - is no clear reason to favor one (e.g., by address - preference), then the sender-SMTP SHOULD pick one at - random to spread the load across multiple mail exchanges - for a specific organization; note that this is a - refinement of the procedure in [DNS:3]. - - (2) Multihomed host -- The destination host (perhaps taken - from the preferred MX record) may be multihomed, in which - case the domain name resolver will return a list of - alternative IP addresses. It is the responsibility of the - domain name resolver interface (see Section 6.1.3.4 below) - to have ordered this list by decreasing preference, and - SMTP MUST try them in the order presented. - - DISCUSSION: - Although the capability to try multiple alternative - addresses is required, there may be circumstances where - specific installations want to limit or disable the use of - alternative addresses. The question of whether a sender - should attempt retries using the different addresses of a - multihomed host has been controversial. The main argument - for using the multiple addresses is that it maximizes the - probability of timely delivery, and indeed sometimes the - probability of any delivery; the counter argument is that - it may result in unnecessary resource use. - - Note that resource use is also strongly determined by the - - - -Internet Engineering Task Force [Page 64] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - sending strategy discussed in Section 5.3.1. - - 5.3.5 Domain Name Support - - SMTP implementations MUST use the mechanism defined in Section - 6.1 for mapping between domain names and IP addresses. This - means that every Internet SMTP MUST include support for the - Internet DNS. - - In particular, a sender-SMTP MUST support the MX record scheme - [SMTP:3]. See also Section 7.4 of [DNS:2] for information on - domain name support for SMTP. - - 5.3.6 Mailing Lists and Aliases - - An SMTP-capable host SHOULD support both the alias and the list - form of address expansion for multiple delivery. When a - message is delivered or forwarded to each address of an - expanded list form, the return address in the envelope - ("MAIL FROM:") MUST be changed to be the address of a person - who administers the list, but the message header MUST be left - unchanged; in particular, the "From" field of the message is - unaffected. - - DISCUSSION: - An important mail facility is a mechanism for multi- - destination delivery of a single message, by transforming - or "expanding" a pseudo-mailbox address into a list of - destination mailbox addresses. When a message is sent to - such a pseudo-mailbox (sometimes called an "exploder"), - copies are forwarded or redistributed to each mailbox in - the expanded list. We classify such a pseudo-mailbox as - an "alias" or a "list", depending upon the expansion - rules: - - (a) Alias - - To expand an alias, the recipient mailer simply - replaces the pseudo-mailbox address in the envelope - with each of the expanded addresses in turn; the rest - of the envelope and the message body are left - unchanged. The message is then delivered or - forwarded to each expanded address. - - (b) List - - A mailing list may be said to operate by - "redistribution" rather than by "forwarding". To - - - -Internet Engineering Task Force [Page 65] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - expand a list, the recipient mailer replaces the - pseudo-mailbox address in the envelope with each of - the expanded addresses in turn. The return address in - the envelope is changed so that all error messages - generated by the final deliveries will be returned to - a list administrator, not to the message originator, - who generally has no control over the contents of the - list and will typically find error messages annoying. - - - 5.3.7 Mail Gatewaying - - Gatewaying mail between different mail environments, i.e., - different mail formats and protocols, is complex and does not - easily yield to standardization. See for example [SMTP:5a], - [SMTP:5b]. However, some general requirements may be given for - a gateway between the Internet and another mail environment. - - (A) Header fields MAY be rewritten when necessary as messages - are gatewayed across mail environment boundaries. - - DISCUSSION: - This may involve interpreting the local-part of the - destination address, as suggested in Section 5.2.16. - - The other mail systems gatewayed to the Internet - generally use a subset of RFC-822 headers, but some - of them do not have an equivalent to the SMTP - envelope. Therefore, when a message leaves the - Internet environment, it may be necessary to fold the - SMTP envelope information into the message header. A - possible solution would be to create new header - fields to carry the envelope information (e.g., "X- - SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would - require changes in mail programs in the foreign - environment. - - (B) When forwarding a message into or out of the Internet - environment, a gateway MUST prepend a Received: line, but - it MUST NOT alter in any way a Received: line that is - already in the header. - - DISCUSSION: - This requirement is a subset of the general - "Received:" line requirement of Section 5.2.8; it is - restated here for emphasis. - - Received: fields of messages originating from other - - - -Internet Engineering Task Force [Page 66] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - environments may not conform exactly to RFC822. - However, the most important use of Received: lines is - for debugging mail faults, and this debugging can be - severely hampered by well-meaning gateways that try - to "fix" a Received: line. - - The gateway is strongly encouraged to indicate the - environment and protocol in the "via" clauses of - Received field(s) that it supplies. - - (C) From the Internet side, the gateway SHOULD accept all - valid address formats in SMTP commands and in RFC-822 - headers, and all valid RFC-822 messages. Although a - gateway must accept an RFC-822 explicit source route - ("@...:" format) in either the RFC-822 header or in the - envelope, it MAY or may not act on the source route; see - Sections 5.2.6 and 5.2.19. - - DISCUSSION: - It is often tempting to restrict the range of - addresses accepted at the mail gateway to simplify - the translation into addresses for the remote - environment. This practice is based on the - assumption that mail users have control over the - addresses their mailers send to the mail gateway. In - practice, however, users have little control over the - addresses that are finally sent; their mailers are - free to change addresses into any legal RFC-822 - format. - - (D) The gateway MUST ensure that all header fields of a - message that it forwards into the Internet meet the - requirements for Internet mail. In particular, all - addresses in "From:", "To:", "Cc:", etc., fields must be - transformed (if necessary) to satisfy RFC-822 syntax, and - they must be effective and useful for sending replies. - - - (E) The translation algorithm used to convert mail from the - Internet protocols to another environment's protocol - SHOULD try to ensure that error messages from the foreign - mail environment are delivered to the return path from the - SMTP envelope, not to the sender listed in the "From:" - field of the RFC-822 message. - - DISCUSSION: - Internet mail lists usually place the address of the - mail list maintainer in the envelope but leave the - - - -Internet Engineering Task Force [Page 67] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - original message header intact (with the "From:" - field containing the original sender). This yields - the behavior the average recipient expects: a reply - to the header gets sent to the original sender, not - to a mail list maintainer; however, errors get sent - to the maintainer (who can fix the problem) and not - the sender (who probably cannot). - - (F) Similarly, when forwarding a message from another - environment into the Internet, the gateway SHOULD set the - envelope return path in accordance with an error message - return address, if any, supplied by the foreign - environment. - - - 5.3.8 Maximum Message Size - - Mailer software MUST be able to send and receive messages of at - least 64K bytes in length (including header), and a much larger - maximum size is highly desirable. - - DISCUSSION: - Although SMTP does not define the maximum size of a - message, many systems impose implementation limits. - - The current de facto minimum limit in the Internet is 64K - bytes. However, electronic mail is used for a variety of - purposes that create much larger messages. For example, - mail is often used instead of FTP for transmitting ASCII - files, and in particular to transmit entire documents. As - a result, messages can be 1 megabyte or even larger. We - note that the present document together with its lower- - layer companion contains 0.5 megabytes. - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 68] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - 5.4 SMTP REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -RECEIVER-SMTP: | | | | | | | - Implement VRFY |5.2.3 |x| | | | | - Implement EXPN |5.2.3 | |x| | | | - EXPN, VRFY configurable |5.2.3 | | |x| | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Verify HELO parameter |5.2.5 | | |x| | | - Refuse message with bad HELO |5.2.5 | | | | |x| - Accept explicit src-route syntax in env. |5.2.6 |x| | | | | - Support "postmaster" |5.2.7 |x| | | | | - Process RCPT when received (except lists) |5.2.7 | | |x| | | - Long delay of RCPT responses |5.2.7 | | | | |x| - | | | | | | | - Add Received: line |5.2.8 |x| | | | | - Received: line include domain literal |5.2.8 | |x| | | | - Change previous Received: line |5.2.8 | | | | |x| - Pass Return-Path info (final deliv/gwy) |5.2.8 |x| | | | | - Support empty reverse path |5.2.9 |x| | | | | - Send only official reply codes |5.2.10 | |x| | | | - Send text from RFC-821 when appropriate |5.2.10 | |x| | | | - Delete "." for transparency |5.2.11 |x| | | | | - Accept and recognize self domain literal(s) |5.2.17 |x| | | | | - | | | | | | | - Error message about error message |5.3.1 | | | | |x| - Keep pending listen on SMTP port |5.3.1.2 | |x| | | | - Provide limit on recv concurrency |5.3.1.2 | | |x| | | - Wait at least 5 mins for next sender cmd |5.3.2 | |x| | | | - Avoidable delivery failure after "250 OK" |5.3.3 | | | | |x| - Send error notification msg after accept |5.3.3 |x| | | | | - Send using null return path |5.3.3 |x| | | | | - Send to envelope return path |5.3.3 | |x| | | | - Send to null address |5.3.3 | | | | |x| - Strip off explicit src route |5.3.3 | |x| | | | - Minimize acceptance delay (RFC-1047) |5.3.3 |x| | | | | ------------------------------------------------|----------|-|-|-|-|-|-- - - - -Internet Engineering Task Force [Page 69] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - | | | | | | | -SENDER-SMTP: | | | | | | | - Canonicalized domain names in MAIL, RCPT |5.2.2 |x| | | | | - Implement SEND, SOML, SAML |5.2.4 | | |x| | | - Send valid principal host name in HELO |5.2.5 |x| | | | | - Send explicit source route in RCPT TO: |5.2.6 | | | |x| | - Use only reply code to determine action |5.2.10 |x| | | | | - Use only high digit of reply code when poss. |5.2.10 | |x| | | | - Add "." for transparency |5.2.11 |x| | | | | - | | | | | | | - Retry messages after soft failure |5.3.1.1 |x| | | | | - Delay before retry |5.3.1.1 |x| | | | | - Configurable retry parameters |5.3.1.1 |x| | | | | - Retry once per each queued dest host |5.3.1.1 | |x| | | | - Multiple RCPT's for same DATA |5.3.1.1 | |x| | | | - Support multiple concurrent transactions |5.3.1.1 | | |x| | | - Provide limit on concurrency |5.3.1.1 | |x| | | | - | | | | | | | - Timeouts on all activities |5.3.1 |x| | | | | - Per-command timeouts |5.3.2 | |x| | | | - Timeouts easily reconfigurable |5.3.2 | |x| | | | - Recommended times |5.3.2 | |x| | | | - Try alternate addr's in order |5.3.4 |x| | | | | - Configurable limit on alternate tries |5.3.4 | | |x| | | - Try at least two alternates |5.3.4 | |x| | | | - Load-split across equal MX alternates |5.3.4 | |x| | | | - Use the Domain Name System |5.3.5 |x| | | | | - Support MX records |5.3.5 |x| | | | | - Use WKS records in MX processing |5.2.12 | | | |x| | ------------------------------------------------|----------|-|-|-|-|-|-- - | | | | | | | -MAIL FORWARDING: | | | | | | | - Alter existing header field(s) |5.2.6 | | | |x| | - Implement relay function: 821/section 3.6 |5.2.6 | | |x| | | - If not, deliver to RHS domain |5.2.6 | |x| | | | - Interpret 'local-part' of addr |5.2.16 | | | | |x| - | | | | | | | -MAILING LISTS AND ALIASES | | | | | | | - Support both |5.3.6 | |x| | | | - Report mail list error to local admin. |5.3.6 |x| | | | | - | | | | | | | -MAIL GATEWAYS: | | | | | | | - Embed foreign mail route in local-part |5.2.16 | | |x| | | - Rewrite header fields when necessary |5.3.7 | | |x| | | - Prepend Received: line |5.3.7 |x| | | | | - Change existing Received: line |5.3.7 | | | | |x| - Accept full RFC-822 on Internet side |5.3.7 | |x| | | | - Act on RFC-822 explicit source route |5.3.7 | | |x| | | - - - -Internet Engineering Task Force [Page 70] - - - - -RFC1123 MAIL -- SMTP & RFC-822 October 1989 - - - Send only valid RFC-822 on Internet side |5.3.7 |x| | | | | - Deliver error msgs to envelope addr |5.3.7 | |x| | | | - Set env return path from err return addr |5.3.7 | |x| | | | - | | | | | | | -USER AGENT -- RFC-822 | | | | | | | - Allow user to enter <route> address |5.2.6 | | | |x| | - Support RFC-1049 Content Type field |5.2.13 | | |x| | | - Use 4-digit years |5.2.14 | |x| | | | - Generate numeric timezones |5.2.14 | |x| | | | - Accept all timezones |5.2.14 |x| | | | | - Use non-num timezones from RFC-822 |5.2.14 |x| | | | | - Omit phrase before route-addr |5.2.15 | | |x| | | - Accept and parse dot.dec. domain literals |5.2.17 |x| | | | | - Accept all RFC-822 address formats |5.2.18 |x| | | | | - Generate invalid RFC-822 address format |5.2.18 | | | | |x| - Fully-qualified domain names in header |5.2.18 |x| | | | | - Create explicit src route in header |5.2.19 | | | |x| | - Accept explicit src route in header |5.2.19 |x| | | | | - | | | | | | | -Send/recv at least 64KB messages |5.3.8 |x| | | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 71] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - -6. SUPPORT SERVICES - - 6.1 DOMAIN NAME TRANSLATION - - 6.1.1 INTRODUCTION - - Every host MUST implement a resolver for the Domain Name System - (DNS), and it MUST implement a mechanism using this DNS - resolver to convert host names to IP addresses and vice-versa - [DNS:1, DNS:2]. - - In addition to the DNS, a host MAY also implement a host name - translation mechanism that searches a local Internet host - table. See Section 6.1.3.8 for more information on this - option. - - DISCUSSION: - Internet host name translation was originally performed by - searching local copies of a table of all hosts. This - table became too large to update and distribute in a - timely manner and too large to fit into many hosts, so the - DNS was invented. - - The DNS creates a distributed database used primarily for - the translation between host names and host addresses. - Implementation of DNS software is required. The DNS - consists of two logically distinct parts: name servers and - resolvers (although implementations often combine these - two logical parts in the interest of efficiency) [DNS:2]. - - Domain name servers store authoritative data about certain - sections of the database and answer queries about the - data. Domain resolvers query domain name servers for data - on behalf of user processes. Every host therefore needs a - DNS resolver; some host machines will also need to run - domain name servers. Since no name server has complete - information, in general it is necessary to obtain - information from more than one name server to resolve a - query. - - 6.1.2 PROTOCOL WALK-THROUGH - - An implementor must study references [DNS:1] and [DNS:2] - carefully. They provide a thorough description of the theory, - protocol, and implementation of the domain name system, and - reflect several years of experience. - - - - - -Internet Engineering Task Force [Page 72] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 - - All DNS name servers and resolvers MUST properly handle RRs - with a zero TTL: return the RR to the client but do not - cache it. - - DISCUSSION: - Zero TTL values are interpreted to mean that the RR can - only be used for the transaction in progress, and - should not be cached; they are useful for extremely - volatile data. - - 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 - - A query with "QCLASS=*" SHOULD NOT be used unless the - requestor is seeking data from more than one class. In - particular, if the requestor is only interested in Internet - data types, QCLASS=IN MUST be used. - - 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 - - Unused fields in a query or response message MUST be zero. - - 6.1.2.4 Compression: RFC-1035 Section 4.1.4 - - Name servers MUST use compression in responses. - - DISCUSSION: - Compression is essential to avoid overflowing UDP - datagrams; see Section 6.1.3.2. - - 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 - - Recursive name servers and full-service resolvers generally - have some configuration information containing hints about - the location of root or local name servers. An - implementation MUST NOT include any of these hints in a - response. - - DISCUSSION: - Many implementors have found it convenient to store - these hints as if they were cached data, but some - neglected to ensure that this "cached data" was not - included in responses. This has caused serious - problems in the Internet when the hints were obsolete - or incorrect. - - - - - -Internet Engineering Task Force [Page 73] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3 SPECIFIC ISSUES - - 6.1.3.1 Resolver Implementation - - A name resolver SHOULD be able to multiplex concurrent - requests if the host supports concurrent processes. - - In implementing a DNS resolver, one of two different models - MAY optionally be chosen: a full-service resolver, or a stub - resolver. - - - (A) Full-Service Resolver - - A full-service resolver is a complete implementation of - the resolver service, and is capable of dealing with - communication failures, failure of individual name - servers, location of the proper name server for a given - name, etc. It must satisfy the following requirements: - - o The resolver MUST implement a local caching - function to avoid repeated remote access for - identical requests, and MUST time out information - in the cache. - - o The resolver SHOULD be configurable with start-up - information pointing to multiple root name servers - and multiple name servers for the local domain. - This insures that the resolver will be able to - access the whole name space in normal cases, and - will be able to access local domain information - should the local network become disconnected from - the rest of the Internet. - - - (B) Stub Resolver - - A "stub resolver" relies on the services of a recursive - name server on the connected network or a "nearby" - network. This scheme allows the host to pass on the - burden of the resolver function to a name server on - another host. This model is often essential for less - capable hosts, such as PCs, and is also recommended - when the host is one of several workstations on a local - network, because it allows all of the workstations to - share the cache of the recursive name server and hence - reduce the number of domain requests exported by the - local network. - - - -Internet Engineering Task Force [Page 74] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - At a minimum, the stub resolver MUST be capable of - directing its requests to redundant recursive name - servers. Note that recursive name servers are allowed - to restrict the sources of requests that they will - honor, so the host administrator must verify that the - service will be provided. Stub resolvers MAY implement - caching if they choose, but if so, MUST timeout cached - information. - - - 6.1.3.2 Transport Protocols - - DNS resolvers and recursive servers MUST support UDP, and - SHOULD support TCP, for sending (non-zone-transfer) queries. - Specifically, a DNS resolver or server that is sending a - non-zone-transfer query MUST send a UDP query first. If the - Answer section of the response is truncated and if the - requester supports TCP, it SHOULD try the query again using - TCP. - - DNS servers MUST be able to service UDP queries and SHOULD - be able to service TCP queries. A name server MAY limit the - resources it devotes to TCP queries, but it SHOULD NOT - refuse to service a TCP query just because it would have - succeeded with UDP. - - Truncated responses MUST NOT be saved (cached) and later - used in such a way that the fact that they are truncated is - lost. - - DISCUSSION: - UDP is preferred over TCP for queries because UDP - queries have much lower overhead, both in packet count - and in connection state. The use of UDP is essential - for heavily-loaded servers, especially the root - servers. UDP also offers additional robustness, since - a resolver can attempt several UDP queries to different - servers for the cost of a single TCP query. - - It is possible for a DNS response to be truncated, - although this is a very rare occurrence in the present - Internet DNS. Practically speaking, truncation cannot - be predicted, since it is data-dependent. The - dependencies include the number of RRs in the answer, - the size of each RR, and the savings in space realized - by the name compression algorithm. As a rule of thumb, - truncation in NS and MX lists should not occur for - answers containing 15 or fewer RRs. - - - -Internet Engineering Task Force [Page 75] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Whether it is possible to use a truncated answer - depends on the application. A mailer must not use a - truncated MX response, since this could lead to mail - loops. - - Responsible practices can make UDP suffice in the vast - majority of cases. Name servers must use compression - in responses. Resolvers must differentiate truncation - of the Additional section of a response (which only - loses extra information) from truncation of the Answer - section (which for MX records renders the response - unusable by mailers). Database administrators should - list only a reasonable number of primary names in lists - of name servers, MX alternatives, etc. - - However, it is also clear that some new DNS record - types defined in the future will contain information - exceeding the 512 byte limit that applies to UDP, and - hence will require TCP. Thus, resolvers and name - servers should implement TCP services as a backup to - UDP today, with the knowledge that they will require - the TCP service in the future. - - By private agreement, name servers and resolvers MAY arrange - to use TCP for all traffic between themselves. TCP MUST be - used for zone transfers. - - A DNS server MUST have sufficient internal concurrency that - it can continue to process UDP queries while awaiting a - response or performing a zone transfer on an open TCP - connection [DNS:2]. - - A server MAY support a UDP query that is delivered using an - IP broadcast or multicast address. However, the Recursion - Desired bit MUST NOT be set in a query that is multicast, - and MUST be ignored by name servers receiving queries via a - broadcast or multicast address. A host that sends broadcast - or multicast DNS queries SHOULD send them only as occasional - probes, caching the IP address(es) it obtains from the - response(s) so it can normally send unicast queries. - - DISCUSSION: - Broadcast or (especially) IP multicast can provide a - way to locate nearby name servers without knowing their - IP addresses in advance. However, general broadcasting - of recursive queries can result in excessive and - unnecessary load on both network and servers. - - - - -Internet Engineering Task Force [Page 76] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.3 Efficient Resource Usage - - The following requirements on servers and resolvers are very - important to the health of the Internet as a whole, - particularly when DNS services are invoked repeatedly by - higher level automatic servers, such as mailers. - - (1) The resolver MUST implement retransmission controls to - insure that it does not waste communication bandwidth, - and MUST impose finite bounds on the resources consumed - to respond to a single request. See [DNS:2] pages 43- - 44 for specific recommendations. - - (2) After a query has been retransmitted several times - without a response, an implementation MUST give up and - return a soft error to the application. - - (3) All DNS name servers and resolvers SHOULD cache - temporary failures, with a timeout period of the order - of minutes. - - DISCUSSION: - This will prevent applications that immediately - retry soft failures (in violation of Section 2.2 - of this document) from generating excessive DNS - traffic. - - (4) All DNS name servers and resolvers SHOULD cache - negative responses that indicate the specified name, or - data of the specified type, does not exist, as - described in [DNS:2]. - - (5) When a DNS server or resolver retries a UDP query, the - retry interval SHOULD be constrained by an exponential - backoff algorithm, and SHOULD also have upper and lower - bounds. - - IMPLEMENTATION: - A measured RTT and variance (if available) should - be used to calculate an initial retransmission - interval. If this information is not available, a - default of no less than 5 seconds should be used. - Implementations may limit the retransmission - interval, but this limit must exceed twice the - Internet maximum segment lifetime plus service - delay at the name server. - - (6) When a resolver or server receives a Source Quench for - - - -Internet Engineering Task Force [Page 77] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query it has issued, it SHOULD take steps to reduce - the rate of querying that server in the near future. A - server MAY ignore a Source Quench that it receives as - the result of sending a response datagram. - - IMPLEMENTATION: - One recommended action to reduce the rate is to - send the next query attempt to an alternate - server, if there is one available. Another is to - backoff the retry interval for the same server. - - - 6.1.3.4 Multihomed Hosts - - When the host name-to-address function encounters a host - with multiple addresses, it SHOULD rank or sort the - addresses using knowledge of the immediately connected - network number(s) and any other applicable performance or - history information. - - DISCUSSION: - The different addresses of a multihomed host generally - imply different Internet paths, and some paths may be - preferable to others in performance, reliability, or - administrative restrictions. There is no general way - for the domain system to determine the best path. A - recommended approach is to base this decision on local - configuration information set by the system - administrator. - - IMPLEMENTATION: - The following scheme has been used successfully: - - (a) Incorporate into the host configuration data a - Network-Preference List, that is simply a list of - networks in preferred order. This list may be - empty if there is no preference. - - (b) When a host name is mapped into a list of IP - addresses, these addresses should be sorted by - network number, into the same order as the - corresponding networks in the Network-Preference - List. IP addresses whose networks do not appear - in the Network-Preference List should be placed at - the end of the list. - - - - - - -Internet Engineering Task Force [Page 78] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - 6.1.3.5 Extensibility - - DNS software MUST support all well-known, class-independent - formats [DNS:2], and SHOULD be written to minimize the - trauma associated with the introduction of new well-known - types and local experimentation with non-standard types. - - DISCUSSION: - The data types and classes used by the DNS are - extensible, and thus new types will be added and old - types deleted or redefined. Introduction of new data - types ought to be dependent only upon the rules for - compression of domain names inside DNS messages, and - the translation between printable (i.e., master file) - and internal formats for Resource Records (RRs). - - Compression relies on knowledge of the format of data - inside a particular RR. Hence compression must only be - used for the contents of well-known, class-independent - RRs, and must never be used for class-specific RRs or - RR types that are not well-known. The owner name of an - RR is always eligible for compression. - - A name server may acquire, via zone transfer, RRs that - the server doesn't know how to convert to printable - format. A resolver can receive similar information as - the result of queries. For proper operation, this data - must be preserved, and hence the implication is that - DNS software cannot use textual formats for internal - storage. - - The DNS defines domain name syntax very generally -- a - string of labels each containing up to 63 8-bit octets, - separated by dots, and with a maximum total of 255 - octets. Particular applications of the DNS are - permitted to further constrain the syntax of the domain - names they use, although the DNS deployment has led to - some applications allowing more general names. In - particular, Section 2.1 of this document liberalizes - slightly the syntax of a legal Internet host name that - was defined in RFC-952 [DNS:4]. - - 6.1.3.6 Status of RR Types - - Name servers MUST be able to load all RR types except MD and - MF from configuration files. The MD and MF types are - obsolete and MUST NOT be implemented; in particular, name - servers MUST NOT load these types from configuration files. - - - -Internet Engineering Task Force [Page 79] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - DISCUSSION: - The RR types MB, MG, MR, NULL, MINFO and RP are - considered experimental, and applications that use the - DNS cannot expect these RR types to be supported by - most domains. Furthermore these types are subject to - redefinition. - - The TXT and WKS RR types have not been widely used by - Internet sites; as a result, an application cannot rely - on the the existence of a TXT or WKS RR in most - domains. - - 6.1.3.7 Robustness - - DNS software may need to operate in environments where the - root servers or other servers are unavailable due to network - connectivity or other problems. In this situation, DNS name - servers and resolvers MUST continue to provide service for - the reachable part of the name space, while giving temporary - failures for the rest. - - DISCUSSION: - Although the DNS is meant to be used primarily in the - connected Internet, it should be possible to use the - system in networks which are unconnected to the - Internet. Hence implementations must not depend on - access to root servers before providing service for - local names. - - 6.1.3.8 Local Host Table - - DISCUSSION: - A host may use a local host table as a backup or - supplement to the DNS. This raises the question of - which takes precedence, the DNS or the host table; the - most flexible approach would make this a configuration - option. - - Typically, the contents of such a supplementary host - table will be determined locally by the site. However, - a publically-available table of Internet hosts is - maintained by the DDN Network Information Center (DDN - NIC), with a format documented in [DNS:4]. This table - can be retrieved from the DDN NIC using a protocol - described in [DNS:5]. It must be noted that this table - contains only a small fraction of all Internet hosts. - Hosts using this protocol to retrieve the DDN NIC host - table should use the VERSION command to check if the - - - -Internet Engineering Task Force [Page 80] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - table has changed before requesting the entire table - with the ALL command. The VERSION identifier should be - treated as an arbitrary string and tested only for - equality; no numerical sequence may be assumed. - - The DDN NIC host table includes administrative - information that is not needed for host operation and - is therefore not currently included in the DNS - database; examples include network and gateway entries. - However, much of this additional information will be - added to the DNS in the future. Conversely, the DNS - provides essential services (in particular, MX records) - that are not available from the DDN NIC host table. - - 6.1.4 DNS USER INTERFACE - - 6.1.4.1 DNS Administration - - This document is concerned with design and implementation - issues in host software, not with administrative or - operational issues. However, administrative issues are of - particular importance in the DNS, since errors in particular - segments of this large distributed database can cause poor - or erroneous performance for many sites. These issues are - discussed in [DNS:6] and [DNS:7]. - - 6.1.4.2 DNS User Interface - - Hosts MUST provide an interface to the DNS for all - application programs running on the host. This interface - will typically direct requests to a system process to - perform the resolver function [DNS:1, 6.1:2]. - - At a minimum, the basic interface MUST support a request for - all information of a specific type and class associated with - a specific name, and it MUST return either all of the - requested information, a hard error code, or a soft error - indication. When there is no error, the basic interface - returns the complete response information without - modification, deletion, or ordering, so that the basic - interface will not need to be changed to accommodate new - data types. - - DISCUSSION: - The soft error indication is an essential part of the - interface, since it may not always be possible to - access particular information from the DNS; see Section - 6.1.3.3. - - - -Internet Engineering Task Force [Page 81] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - A host MAY provide other DNS interfaces tailored to - particular functions, transforming the raw domain data into - formats more suited to these functions. In particular, a - host MUST provide a DNS interface to facilitate translation - between host addresses and host names. - - 6.1.4.3 Interface Abbreviation Facilities - - User interfaces MAY provide a method for users to enter - abbreviations for commonly-used names. Although the - definition of such methods is outside of the scope of the - DNS specification, certain rules are necessary to insure - that these methods allow access to the entire DNS name space - and to prevent excessive use of Internet resources. - - If an abbreviation method is provided, then: - - (a) There MUST be some convention for denoting that a name - is already complete, so that the abbreviation method(s) - are suppressed. A trailing dot is the usual method. - - (b) Abbreviation expansion MUST be done exactly once, and - MUST be done in the context in which the name was - entered. - - - DISCUSSION: - For example, if an abbreviation is used in a mail - program for a destination, the abbreviation should be - expanded into a full domain name and stored in the - queued message with an indication that it is already - complete. Otherwise, the abbreviation might be - expanded with a mail system search list, not the - user's, or a name could grow due to repeated - canonicalizations attempts interacting with wildcards. - - The two most common abbreviation methods are: - - (1) Interface-level aliases - - Interface-level aliases are conceptually implemented as - a list of alias/domain name pairs. The list can be - per-user or per-host, and separate lists can be - associated with different functions, e.g. one list for - host name-to-address translation, and a different list - for mail domains. When the user enters a name, the - interface attempts to match the name to the alias - component of a list entry, and if a matching entry can - - - -Internet Engineering Task Force [Page 82] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - be found, the name is replaced by the domain name found - in the pair. - - Note that interface-level aliases and CNAMEs are - completely separate mechanisms; interface-level aliases - are a local matter while CNAMEs are an Internet-wide - aliasing mechanism which is a required part of any DNS - implementation. - - (2) Search Lists - - A search list is conceptually implemented as an ordered - list of domain names. When the user enters a name, the - domain names in the search list are used as suffixes to - the user-supplied name, one by one, until a domain name - with the desired associated data is found, or the - search list is exhausted. Search lists often contain - the name of the local host's parent domain or other - ancestor domains. Search lists are often per-user or - per-process. - - It SHOULD be possible for an administrator to disable a - DNS search-list facility. Administrative denial may be - warranted in some cases, to prevent abuse of the DNS. - - There is danger that a search-list mechanism will - generate excessive queries to the root servers while - testing whether user input is a complete domain name, - lacking a final period to mark it as complete. A - search-list mechanism MUST have one of, and SHOULD have - both of, the following two provisions to prevent this: - - (a) The local resolver/name server can implement - caching of negative responses (see Section - 6.1.3.3). - - (b) The search list expander can require two or more - interior dots in a generated domain name before it - tries using the name in a query to non-local - domain servers, such as the root. - - DISCUSSION: - The intent of this requirement is to avoid - excessive delay for the user as the search list is - tested, and more importantly to prevent excessive - traffic to the root and other high-level servers. - For example, if the user supplied a name "X" and - the search list contained the root as a component, - - - -Internet Engineering Task Force [Page 83] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - a query would have to consult a root server before - the next search list alternative could be tried. - The resulting load seen by the root servers and - gateways near the root would be multiplied by the - number of hosts in the Internet. - - The negative caching alternative limits the effect - to the first time a name is used. The interior - dot rule is simpler to implement but can prevent - easy use of some top-level names. - - - 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -GENERAL ISSUES | | | | | | | - | | | | | | | -Implement DNS name-to-address conversion |6.1.1 |x| | | | | -Implement DNS address-to-name conversion |6.1.1 |x| | | | | -Support conversions using host table |6.1.1 | | |x| | | -Properly handle RR with zero TTL |6.1.2.1 |x| | | | | -Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | | - Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | | -Unused fields zero |6.1.2.3 |x| | | | | -Use compression in responses |6.1.2.4 |x| | | | | - | | | | | | | -Include config info in responses |6.1.2.5 | | | | |x| -Support all well-known, class-indep. types |6.1.3.5 |x| | | | | -Easily expand type list |6.1.3.5 | |x| | | | -Load all RR types (except MD and MF) |6.1.3.6 |x| | | | | -Load MD or MF type |6.1.3.6 | | | | |x| -Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOLVER ISSUES: | | | | | | | - | | | | | | | -Resolver support multiple concurrent requests |6.1.3.1 | |x| | | | -Full-service resolver: |6.1.3.1 | | |x| | | - Local caching |6.1.3.1 |x| | | | | - - - -Internet Engineering Task Force [Page 84] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Information in local cache times out |6.1.3.1 |x| | | | | - Configurable with starting info |6.1.3.1 | |x| | | | -Stub resolver: |6.1.3.1 | | |x| | | - Use redundant recursive name servers |6.1.3.1 |x| | | | | - Local caching |6.1.3.1 | | |x| | | - Information in local cache times out |6.1.3.1 |x| | | | | -Support for remote multi-homed hosts: | | | | | | | - Sort multiple addresses by preference list |6.1.3.4 | |x| | | | - | | | | | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -TRANSPORT PROTOCOLS: | | | | | | | - | | | | | | | -Support UDP queries |6.1.3.2 |x| | | | | -Support TCP queries |6.1.3.2 | |x| | | | - Send query using UDP first |6.1.3.2 |x| | | | |1 - Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | | -Name server limit TCP query resources |6.1.3.2 | | |x| | | - Punish unnecessary TCP query |6.1.3.2 | | | |x| | -Use truncated data as if it were not |6.1.3.2 | | | | |x| -Private agreement to use only TCP |6.1.3.2 | | |x| | | -Use TCP for zone transfers |6.1.3.2 |x| | | | | -TCP usage not block UDP queries |6.1.3.2 |x| | | | | -Support broadcast or multicast queries |6.1.3.2 | | |x| | | - RD bit set in query |6.1.3.2 | | | | |x| - RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | | - Send only as occasional probe for addr's |6.1.3.2 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- -RESOURCE USAGE: | | | | | | | - | | | | | | | -Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | | - Finite bounds per request |6.1.3.3 |x| | | | | -Failure after retries => soft error |6.1.3.3 |x| | | | | -Cache temporary failures |6.1.3.3 | |x| | | | -Cache negative responses |6.1.3.3 | |x| | | | -Retries use exponential backoff |6.1.3.3 | |x| | | | - Upper, lower bounds |6.1.3.3 | |x| | | | -Client handle Source Quench |6.1.3.3 | |x| | | | -Server ignore Source Quench |6.1.3.3 | | |x| | | ------------------------------------------------|-----------|-|-|-|-|-|-- -USER INTERFACE: | | | | | | | - | | | | | | | -All programs have access to DNS interface |6.1.4.2 |x| | | | | -Able to request all info for given name |6.1.4.2 |x| | | | | -Returns complete info or error |6.1.4.2 |x| | | | | -Special interfaces |6.1.4.2 | | |x| | | - Name<->Address translation |6.1.4.2 |x| | | | | - | | | | | | | -Abbreviation Facilities: |6.1.4.3 | | |x| | | - - - -Internet Engineering Task Force [Page 85] - - - - -RFC1123 SUPPORT SERVICES -- DOMAINS October 1989 - - - Convention for complete names |6.1.4.3 |x| | | | | - Conversion exactly once |6.1.4.3 |x| | | | | - Conversion in proper context |6.1.4.3 |x| | | | | - Search list: |6.1.4.3 | | |x| | | - Administrator can disable |6.1.4.3 | |x| | | | - Prevention of excessive root queries |6.1.4.3 |x| | | | | - Both methods |6.1.4.3 | |x| | | | ------------------------------------------------|-----------|-|-|-|-|-|-- ------------------------------------------------|-----------|-|-|-|-|-|-- - -1. Unless there is private agreement between particular resolver and - particular server. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 86] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - 6.2 HOST INITIALIZATION - - 6.2.1 INTRODUCTION - - This section discusses the initialization of host software - across a connected network, or more generally across an - Internet path. This is necessary for a diskless host, and may - optionally be used for a host with disk drives. For a diskless - host, the initialization process is called "network booting" - and is controlled by a bootstrap program located in a boot ROM. - - To initialize a diskless host across the network, there are two - distinct phases: - - (1) Configure the IP layer. - - Diskless machines often have no permanent storage in which - to store network configuration information, so that - sufficient configuration information must be obtained - dynamically to support the loading phase that follows. - This information must include at least the IP addresses of - the host and of the boot server. To support booting - across a gateway, the address mask and a list of default - gateways are also required. - - (2) Load the host system code. - - During the loading phase, an appropriate file transfer - protocol is used to copy the system code across the - network from the boot server. - - A host with a disk may perform the first step, dynamic - configuration. This is important for microcomputers, whose - floppy disks allow network configuration information to be - mistakenly duplicated on more than one host. Also, - installation of new hosts is much simpler if they automatically - obtain their configuration information from a central server, - saving administrator time and decreasing the probability of - mistakes. - - 6.2.2 REQUIREMENTS - - 6.2.2.1 Dynamic Configuration - - A number of protocol provisions have been made for dynamic - configuration. - - o ICMP Information Request/Reply messages - - - -Internet Engineering Task Force [Page 87] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - This obsolete message pair was designed to allow a host - to find the number of the network it is on. - Unfortunately, it was useful only if the host already - knew the host number part of its IP address, - information that hosts requiring dynamic configuration - seldom had. - - o Reverse Address Resolution Protocol (RARP) [BOOT:4] - - RARP is a link-layer protocol for a broadcast medium - that allows a host to find its IP address given its - link layer address. Unfortunately, RARP does not work - across IP gateways and therefore requires a RARP server - on every network. In addition, RARP does not provide - any other configuration information. - - o ICMP Address Mask Request/Reply messages - - These ICMP messages allow a host to learn the address - mask for a particular network interface. - - o BOOTP Protocol [BOOT:2] - - This protocol allows a host to determine the IP - addresses of the local host and the boot server, the - name of an appropriate boot file, and optionally the - address mask and list of default gateways. To locate a - BOOTP server, the host broadcasts a BOOTP request using - UDP. Ad hoc gateway extensions have been used to - transmit the BOOTP broadcast through gateways, and in - the future the IP Multicasting facility will provide a - standard mechanism for this purpose. - - - The suggested approach to dynamic configuration is to use - the BOOTP protocol with the extensions defined in "BOOTP - Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 - defines some important general (not vendor-specific) - extensions. In particular, these extensions allow the - address mask to be supplied in BOOTP; we RECOMMEND that the - address mask be supplied in this manner. - - DISCUSSION: - Historically, subnetting was defined long after IP, and - so a separate mechanism (ICMP Address Mask messages) - was designed to supply the address mask to a host. - However, the IP address mask and the corresponding IP - address conceptually form a pair, and for operational - - - -Internet Engineering Task Force [Page 88] - - - - -RFC1123 SUPPORT SERVICES -- INITIALIZATION October 1989 - - - simplicity they ought to be defined at the same time - and by the same mechanism, whether a configuration file - or a dynamic mechanism like BOOTP. - - Note that BOOTP is not sufficiently general to specify - the configurations of all interfaces of a multihomed - host. A multihomed host must either use BOOTP - separately for each interface, or configure one - interface using BOOTP to perform the loading, and - perform the complete initialization from a file later. - - Application layer configuration information is expected - to be obtained from files after loading of the system - code. - - 6.2.2.2 Loading Phase - - A suggested approach for the loading phase is to use TFTP - [BOOT:1] between the IP addresses established by BOOTP. - - TFTP to a broadcast address SHOULD NOT be used, for reasons - explained in Section 4.2.3.4. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 89] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - 6.3 REMOTE MANAGEMENT - - 6.3.1 INTRODUCTION - - The Internet community has recently put considerable effort - into the development of network management protocols. The - result has been a two-pronged approach [MGT:1, MGT:6]: the - Simple Network Management Protocol (SNMP) [MGT:4] and the - Common Management Information Protocol over TCP (CMOT) [MGT:5]. - - In order to be managed using SNMP or CMOT, a host will need to - implement an appropriate management agent. An Internet host - SHOULD include an agent for either SNMP or CMOT. - - Both SNMP and CMOT operate on a Management Information Base - (MIB) that defines a collection of management values. By - reading and setting these values, a remote application may - query and change the state of the managed system. - - A standard MIB [MGT:3] has been defined for use by both - management protocols, using data types defined by the Structure - of Management Information (SMI) defined in [MGT:2]. Additional - MIB variables can be introduced under the "enterprises" and - "experimental" subtrees of the MIB naming space [MGT:2]. - - Every protocol module in the host SHOULD implement the relevant - MIB variables. A host SHOULD implement the MIB variables as - defined in the most recent standard MIB, and MAY implement - other MIB variables when appropriate and useful. - - 6.3.2 PROTOCOL WALK-THROUGH - - The MIB is intended to cover both hosts and gateways, although - there may be detailed differences in MIB application to the two - cases. This section contains the appropriate interpretation of - the MIB for hosts. It is likely that later versions of the MIB - will include more entries for host management. - - A managed host must implement the following groups of MIB - object definitions: System, Interfaces, Address Translation, - IP, ICMP, TCP, and UDP. - - The following specific interpretations apply to hosts: - - o ipInHdrErrors - - Note that the error "time-to-live exceeded" can occur in a - host only when it is forwarding a source-routed datagram. - - - -Internet Engineering Task Force [Page 90] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - o ipOutNoRoutes - - This object counts datagrams discarded because no route - can be found. This may happen in a host if all the - default gateways in the host's configuration are down. - - o ipFragOKs, ipFragFails, ipFragCreates - - A host that does not implement intentional fragmentation - (see "Fragmentation" section of [INTRO:1]) MUST return the - value zero for these three objects. - - o icmpOutRedirects - - For a host, this object MUST always be zero, since hosts - do not send Redirects. - - o icmpOutAddrMaskReps - - For a host, this object MUST always be zero, unless the - host is an authoritative source of address mask - information. - - o ipAddrTable - - For a host, the "IP Address Table" object is effectively a - table of logical interfaces. - - o ipRoutingTable - - For a host, the "IP Routing Table" object is effectively a - combination of the host's Routing Cache and the static - route table described in "Routing Outbound Datagrams" - section of [INTRO:1]. - - Within each ipRouteEntry, ipRouteMetric1...4 normally will - have no meaning for a host and SHOULD always be -1, while - ipRouteType will normally have the value "remote". - - If destinations on the connected network do not appear in - the Route Cache (see "Routing Outbound Datagrams section - of [INTRO:1]), there will be no entries with ipRouteType - of "direct". - - - DISCUSSION: - The current MIB does not include Type-of-Service in an - ipRouteEntry, but a future revision is expected to make - - - -Internet Engineering Task Force [Page 91] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - this addition. - - We also expect the MIB to be expanded to allow the remote - management of applications (e.g., the ability to partially - reconfigure mail systems). Network service applications - such as mail systems should therefore be written with the - "hooks" for remote management. - - 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY - - | | | | |S| | - | | | | |H| |F - | | | | |O|M|o - | | |S| |U|U|o - | | |H| |L|S|t - | |M|O| |D|T|n - | |U|U|M| | |o - | |S|L|A|N|N|t - | |T|D|Y|O|O|t -FEATURE |SECTION | | | |T|T|e ------------------------------------------------|-----------|-|-|-|-|-|-- -Support SNMP or CMOT agent |6.3.1 | |x| | | | -Implement specified objects in standard MIB |6.3.1 | |x| | | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 92] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -7. REFERENCES - - This section lists the primary references with which every - implementer must be thoroughly familiar. It also lists some - secondary references that are suggested additional reading. - - INTRODUCTORY REFERENCES: - - - [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," - IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, - October 1989. - - [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, - (three volumes), SRI International, December 1985. - - [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, - RFC-1011, May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. - Postel, RFC-980, March 1986. - - [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, - May 1987. - - This document is republished periodically with new RFC numbers; - the latest version must be used. - - - TELNET REFERENCES: - - - [TELNET:1] "Telnet Protocol Specification," J. Postel and J. - Reynolds, RFC-854, May 1983. - - [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, - RFC-855, May 1983. - - [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, - RFC-856, May 1983. - - [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, - May 1983. - - [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J. - - - -Internet Engineering Task Force [Page 93] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - Reynolds, RFC-858, May 1983. - - [TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC- - 859, May 1983. - - [TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds, - RFC-860, May 1983. - - [TELNET:8] "Telnet Extended Options List," J. Postel and J. - Reynolds, RFC-861, May 1983. - - [TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855, - December 1983. - - [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091, - February 1989. - - This document supercedes RFC-930. - - [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073, - October 1988. - - [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August - 1989. - - [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079, - December 1988. - - [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC- - 1080, November 1988. - - - SECONDARY TELNET REFERENCES: - - - [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of - Defense, May 1984. - - This document is intended to describe the same protocol as RFC- - 854. In case of conflict, RFC-854 takes precedence, and the - present document takes precedence over both. - - [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977. - - [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October - 1977. - - [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977. - - - -Internet Engineering Task Force [Page 94] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS - Implementation," A. Yasuda and T. Thompson, RFC-1043, February - 1988. - - - FTP REFERENCES: - - - [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- - 959, October 1985. - - [FTP:2] "Document File Format Standards," J. Postel, RFC-678, - December 1974. - - [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of - Defense, May 1984. - - This document is based on an earlier version of the FTP - specification (RFC-765) and is obsolete. - - - TFTP REFERENCES: - - - [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June - 1981. - - - MAIL REFERENCES: - - - [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August - 1982. - - [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," - D. Crocker, RFC-822, August 1982. - - This document obsoleted an earlier specification, RFC-733. - - [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- - 974, January 1986. - - This RFC describes the use of MX records, a mandatory extension - to the mail delivery process. - - [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, - February 1988. - - - - -Internet Engineering Task Force [Page 95] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, - June 1986. - - [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. - - The two preceding RFC's define a proposed standard for - gatewaying mail between the Internet and the X.400 environments. - - [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. - Department of Defense, May 1984. - - This specification is intended to describe the same protocol as - does RFC-821. However, MIL-STD-1781 is incomplete; in - particular, it does not include MX records [SMTP:3]. - - [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, - RFC-1049, March 1988. - - - DOMAIN NAME SYSTEM REFERENCES: - - - [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, - RFC-1034, November 1987. - - This document and the following one obsolete RFC-882, RFC-883, - and RFC-973. - - [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, - P. Mockapetris, November 1987. - - - [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, - January 1986. - - - [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, - RFC-952, M. Stahl, E. Feinler, October 1985. - - SECONDARY DNS REFERENCES: - - - [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, - RFC-953, October 1985. - - [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November - 1987. - - - - -Internet Engineering Task Force [Page 96] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - - [DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- - 1033, November 1987. - - [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet - Protocol Handbook, NIC 50007, SRI Network Information Center, - August 1989. - - - SYSTEM INITIALIZATION REFERENCES: - - - [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June - 1984. - - [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- - 951, September 1985. - - [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- - 1084, December 1988. - - Note: this RFC revised and obsoleted RFC-1048. - - [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. - Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. - - - MANAGEMENT REFERENCES: - - - [MGT:1] "IAB Recommendations for the Development of Internet Network - Management Standards," V. Cerf, RFC-1052, April 1988. - - [MGT:2] "Structure and Identification of Management Information for - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, - August 1988. - - [MGT:3] "Management Information Base for Network Management of - TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, - August 1988. - - [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, - M. Schoffstall, and C. Davin, RFC-1098, April 1989. - - [MGT:5] "The Common Management Information Services and Protocol - over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. - - [MGT:6] "Report of the Second Ad Hoc Network Management Review - Group," V. Cerf, RFC-1109, August 1989. - - - -Internet Engineering Task Force [Page 97] - - - - -RFC1123 SUPPORT SERVICES -- MANAGEMENT October 1989 - - -Security Considerations - - There are many security issues in the application and support - programs of host software, but a full discussion is beyond the scope - of this RFC. Security-related issues are mentioned in sections - concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and - EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the - SMTP DATA command (Section 5.2.8). - -Author's Address - - Robert Braden - USC/Information Sciences Institute - 4676 Admiralty Way - Marina del Rey, CA 90292-6695 - - Phone: (213) 822 1511 - - EMail: Braden@ISI.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Internet Engineering Task Force [Page 98] - diff --git a/RFC/rfc1176.txt b/RFC/rfc1176.txt deleted file mode 100644 index 1ea72a11..00000000 --- a/RFC/rfc1176.txt +++ /dev/null @@ -1,1683 +0,0 @@ - - - - - - -Network Working Group M. Crispin -Request for Comments: 1176 Washington -Obsoletes: RFC 1064 August 1990 - - - INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2 - - -Status of this Memo - - This RFC suggests a method for personal computers and workstations to - dynamically access mail from a mailbox server ("repository"). It - obosoletes RFC 1064. This RFC specifies an Experimental Protocol for - the Internet community. Discussion and suggestions for improvement - are requested. Please refer to the current edition of the "IAB - Official Protocol Standards" for the standardization state and status - of this protocol. Distribution of this memo is unlimited. - -Introduction - - The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2) - is to allow a workstation, personal computer, or similar small - machine to access electronic mail from a mailbox server. Since the - distinction between personal computers and workstations is blurring - over time, it is desirable to have a single solution that addresses - the need in a general fashion. IMAP2 is the "glue" of a distributed - electronic mail system consisting of a family of client and server - implementations on a wide variety of platforms, from small single- - tasking personal computing engines to complex multi-user timesharing - systems. - - Although different in many ways from the Post Office Protocols (POP2 - and POP3, hereafter referred to collectively as "POP") described in - RFC 937 and RFC 1081, IMAP2 may be thought of as a functional - superset of these. RFC 937 was used as a model for this RFC. There - was a cognizant reason for this; POP deals with a similar problem, - albeit with a less comprehensive solution, and it was desirable to - offer a basis for comparison. - - Like POP, IMAP2 specifies a means of accessing stored mail and not of - posting mail; this function is handled by a mail transfer protocol - such as SMTP (RFC 821). - - This protocol assumes a reliable data stream such as provided by TCP - or any similar protocol. When TCP is used, the IMAP2 server listens - on port 143. - - - - - -Crispin [Page 1] - -RFC 1176 IMAP2 August 1990 - - -System Model and Philosophy - - Electronic mail is a primary means of communication for the widely - spread Internet community. The advent of distributed personal - computers and workstations has forced a significant rethinking of the - mechanisms employed to manage electronic mail. With mainframes, each - user tends to receive and process mail at the computer he uses most - of the time, his "primary host". The first inclination of many users - when an independent workstation is placed in front of them is to - begin receiving mail at the workstation, and many vendors have - implemented facilities to do this. However, this approach has - several disadvantages: - - (1) Personal computers and many workstations have a software - design that gives full control of all aspects of the system to the - user at the console. As a result, background tasks such as - receiving mail may not run for long periods of time; either - because the user is asking to use all the machine's resources, or - because the user has (perhaps accidentally) manipulated the - environment in such a way that it prevents mail reception. In - many personal computers, the operating system is single-tasking - and this is the only mode of operation. Any of these conditions - could lead to repeated failed delivery attempts by outside agents. - - (2) The hardware failure of a single machine can keep its user - "off the air" for a considerable time, since repair of individual - units may be delayed. Given the growing number of personal - computers and workstations spread throughout office environments, - quick repair of such systems is not assured. On the other hand, a - central mainframe is generally repaired soon after failure. - - (3) Personal computers and workstations are often not backed up - with as much diligence as a central mainframe, if at all. - - (4) It is more difficult to keep track of mailing addresses when - each person is associated with a distinct machine. Consider the - difficulty in keeping track of many postal addresses or phone - numbers, particularly if there was no single address or phone - number for an organization through which you could reach any - person in that organization. Traditionally, electronic mail on - the ARPANET involved remembering a name and one of several "hosts" - (machines) whose name reflected the organization in which the - individual worked. This was suitable at a time when most - organizations had only one central host. It is less satisfactory - today unless the concept of a host is changed to refer to an - organizational entity and not a particular machine. - - (5) It is difficult to keep a multitude of heterogeneous machines - - - -Crispin [Page 2] - -RFC 1176 IMAP2 August 1990 - - - working properly with complex mailing protocols, making it - difficult to move forward as progress is made in electronic - communication and as new standards emerge. Each system has to - worry about receiving incoming mail, routing and delivering - outgoing mail, formatting, storing, and providing for the - stability of mailboxes over a variety of possible filing and - mailing protocols. - - Consequently, while a personal computer or workstation may be viewed - as an Internet host in the sense that it implements TCP/IP, it should - not be viewed as the entity that contains the user's mailbox. - Instead, a mail server machine ("server", sometimes called a - "repository") should hold the mailbox, and the personal computer or - workstation (hereafter referred to as a "client") should access the - mailbox via mail transactions. - - Because the mail server machine is isolated from direct user - manipulation, it should achieve high software reliability easily, - and, as a shared resource, it should also achieve high hardware - reliability, perhaps through redundancy. The mail server may be - accessed from arbitrary locations, allowing users to read mail across - campus, town, or country using commonly available clients. - Furthermore, the same user may access his mailbox from different - clients at different times, and multiple users may access the same - mailbox simultaneously. - - The mail server acts an an interface among users, data storage, and - other mailers. A mail access protocol retrieves messages, accesss - and changes properties of messages, and otherwise manages mailboxes. - This differs from some approaches (e.g., Unix mail via NFS) in that - the mail access protocol is used for all message manipulations, - isolating the user and the client from all knowledge of how the data - storage is used. This means that the mail server can use the data - storage in whatever way is most efficient to organize the mail in - that particular environment, without having to worry about storage - representation compatibility across different machines. - - A mail access protocol further differs in that it transmits - information only on demand. A well-designed mail access protocol - requires considerably less network traffic than Unix mail via NFS, - particularly when the mail file is large. The result is that a mail - access protocol can scale well to situations of large mailboxes or - networks with high latency or low speed. - - In defining a mail access protocol, it is important to keep in mind - that the client and server form a macrosystem, in which it should be - possible to exploit the strong points of both while compensating for - each other's weaknesses. Furthermore, it is desirable to allow for a - - - -Crispin [Page 3] - -RFC 1176 IMAP2 August 1990 - - - growth path beyond the hoary text-only RFC 822 protocol, specifically - in the area of attachments and multi-media mail, to ease the eventual - transition to ISO solutions. - - Unlike POP, IMAP2 has extensive features for remote searching and - parsing of messages on the server. A free text search (optionally - with other searching) can be made in the entire mailbox by the server - and the results made available to the client without the client - having to transfer the entire mailbox and searching itself. Since - remote parsing of a message into a structured (and standard format) - "envelope" is available, a client can display envelope information - and implement commands such as REPLY without having any understanding - of how to parse RFC 822, etc. headers. The effect of this is - twofold: it further improves the ability to scale well in instances - where network traffic must be reduced, and it reduces the complexity - of the client program. - - Additionally, IMAP2 offers several facilities for managing individual - message state and the mailbox as a whole beyond the simple "delete - message" functionality of POP. Another benefit of IMAP2 is the use - of tagged responses to reduce the possibility of synchronization - errors and the concept of state on the client (a "local cache") that - the server may update without explicit request by the client. These - concepts and how they are used are explained under "Implementation - Discussion" below. - - In spite of this functional richness, IMAP2 is a small protocol. - Although servers should implement the full set of IMAP2 functions, a - simple client can be written that uses IMAP2 in much the way as a POP - client. - - A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL - (RFC 1056). IMAP2 differs from DMSP more fundamentally, reflecting a - differing architecture from PCMAIL. PCMAIL is either an online - ("interactive mode"), or offline ("batch mode") system with long-term - shared state. Some POP based systems are also offline; in such - systems, since there is no long-term shared state POP is little more - than a download mechanism of the "mail file" to the client. IMAP2- - based software is primarily an online system in which real-time and - simultaneous mail access were considered important. - - In PCMAIL, there is a long-term client/server relationship in which - some mailbox state is preserved on the client. There is a - registration of clients used by a particular user, and the client - keeps a set of "descriptors" for each message that summarize the - message. The server and client synchronize their states when the - DMSP connection starts up, and, if a client has not accessed the - server for a while, the client does a complete reset (reload) of its - - - -Crispin [Page 4] - -RFC 1176 IMAP2 August 1990 - - - state from the server. - - In IMAP2-based software, the client/server relationship lasts only - for the duration of the TCP connection. All mailbox state is - maintained on the server. There is no registration of clients. The - function of a descriptor is handled by a structured representation of - the message "envelope" as noted above. There is no client/server - synchronization since the client does not remember state between - IMAP2 connections. This is not a problem since in general the client - never needs the entire state of the mailbox in a single session, - therefore there isn't much overhead in fetching the state information - that is needed as it is needed. - - There are also some functional differences between IMAP2 and DMSP. - DMSP has functions for sending messages, printing messages, listing - mailboxes, and changing passwords; these are done outside IMAP2. - DMSP has 16 binary flags of which 8 are defined by the system. IMAP2 - has flag names; there are currently 5 defined system flag names and a - facility for some number (30 in the current implementations) of user - flag names. IMAP2 has a sophisticated message search facility in the - server to identify interesting messages based on dates, addresses, - flag status, or textual contents without compelling the client to - fetch this data for every message. - - It was felt that maintaining state on the client is advantageous only - in those cases where the client is only used by a single user, or if - there is some means on the client to restrict access to another - user's data. It can be a serious disadvantage in an environment in - which multiple users routinely use the same client, the same user - routinely uses different clients, and where there are no access - restrictions on the client. It was also observed that most user mail - access is to a small set of "interesting" messages, which were either - new mail or mail based on some user-selected criteria. Consequently, - IMAP2 was designed to easily identify those "interesting" messages so - that the client could fetch the state of those messages and not those - that were not "interesting". - -The Protocol - - The IMAP2 protocol consists of a sequence of client commands and - server responses, with server data interspersed between the - responses. Unlike most Internet protocols, commands and responses - are tagged. That is, a command begins with a unique identifier - (typically a short alphanumeric sequence such as a Lisp "gensym" - function would generate e.g., A0001, A0002, etc.), called a tag. The - response to this command is given the same tag from the server. - Additionally, the server may send an arbitrary amount of "unsolicited - data", which is identified by the special reserved tag of "*". There - - - -Crispin [Page 5] - -RFC 1176 IMAP2 August 1990 - - - is another special reserved tag, "+", discussed below. - - The server must be listening for a connection. When a connection is - opened the server sends an unsolicited OK response as a greeting - message and then waits for commands. - - The client opens a connection and waits for the greeting. The client - must not send any commands until it has received the greeting from - the server. - - Once the greeting has been received, the client may begin sending - commands and is not under any obligation to wait for a server - response to this command before sending another command, within the - constraints of TCP flow control. When commands are received the - server acts on them and responds with command responses, often - interspersed with data. The effect of a command can not be - considered complete until a command response with a tag matching the - command is received from the server. - - Although all known IMAP2 servers at the time of this writing process - commands to completion before processing the next command, it is not - required that a server do so. However, many commands can affect the - results of other commands, creating processing-order dependencies - (or, for SEARCH and FIND, ambiguities about which data is associated - with which command). All implementations that operate in a non- - lockstep fashion must recognize such dependencies and defer or - synchronize execution as necessary. In general, such multi- - processing is limited to consecutive FETCH commands. - - Generally, the first command from the client is a LOGIN command with - user name and password arguments to establish identity and access - authorization, unless this has already been accomplished through - other means, e.g. Kerberos. Until identity and access authorization - have been established, no operations other than LOGIN or LOGOUT are - permitted. - - Once identity and authorization have been established, the client - must send a SELECT command to access the desired mailbox; no mailbox - is selected by default. SELECT's argument is implementation- - dependent; however the word "INBOX" must be implemented to mean the - primary or default mailbox for this user, independent of any other - server semantics. On a successful SELECT, the server will send a - list of valid flags, number of messages, and number of messages - arrived since last access for this mailbox as unsolicited data, - followed by an OK response. The client may terminate access to this - mailbox and access a different one with another SELECT command. - - The client reads mailbox information with FETCH commands. The actual - - - -Crispin [Page 6] - -RFC 1176 IMAP2 August 1990 - - - data is transmitted via the unsolicited data mechanism (that is, - FETCH should be viewed as instructing the server to include the - desired data along with any other data it wishes to transmit to the - client). There are three major categories of data that may be - fetched. - - The first category is data that is associated with a message as an - entity in the mailbox. There are now three such items of data: the - "internal date", the "RFC 822 size", and the "flags". The internal - date is the date and time that the message was placed in the mailbox. - The RFC 822 size is subject to deletion in the future; it is the size - in bytes of the message, expressed as an RFC 822 text string. - Current clients only use it as part of a status display line. The - flags are a list of status flags associated with the message (see - below). All the first category data can be fetched by using the - macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS - INTERNALDATE RFC822.SIZE)". - - The second category is that data that describes the composition and - delivery information of a message; that is, information such as the - message sender, recipient lists, message-ID, subject, etc. This is - the information that is stored in the message header in RFC 822 - format message and is traditionally called the "envelope". [Note: - this should not be confused with the SMTP (RFC 821) envelope, which - is strictly limited to delivery information.] IMAP2 defines a - structured and unambiguous representation for the envelope that is - particularly suited for Lisp-based parsers. A client can use the - envelope for operations such as replying and not worry about RFC 822 - at all. Envelopes are discussed in more detail below. The first two - categories of data can be fetched together by using the macro-fetch - word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE - RFC822.SIZE ENVELOPE)". - - The third category is that data that is intended for direct human - viewing. The present RFC 822 based IMAP2 defines three such items: - RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two - former appended together in a single text string). RFC822.HEADER is - the "raw", unprocessed RFC 822 format header of the message. - Fetching "RFC822" is equivalent to fetching the RFC 822 - representation of the message as stored on the mailbox without any - filtering or processing. - - An intelligent client will "FETCH ALL" for some (or all) of the - messages in the mailbox for use as a presentation menu, and when the - user wishes to read a particular message will "FETCH RFC822.TEXT" to - get the message body. A more primitive client could, of course, - simply "FETCH RFC822" a`la POP-type functionality. - - - - -Crispin [Page 7] - -RFC 1176 IMAP2 August 1990 - - - The client can alter certain data (currently only the flags) by a - STORE command. As an example, a message is deleted from a mailbox by - a STORE command that includes the \DELETED flag as a flag being set. - - Other client operations include copying a message to another mailbox - (COPY command), permanently removing deleted messages (EXPUNGE - command), checking for new messages (CHECK command), and searching - for messages that match certain criteria (SEARCH command). - - The client terminates the session with the LOGOUT command. The - server returns a "BYE" followed by an "OK". - - A Typical Scenario - - Client Server - ------ ------ - {Wait for Connection} - {Open Connection} --> - <-- * OK IMAP2 Server Ready - {Wait for command} - A001 LOGIN Fred Secret --> - <-- A001 OK User Fred logged in - {Wait for command} - A002 SELECT INBOX --> - <-- * FLAGS (Meeting Notice \Answered - \Flagged \Deleted \Seen) - <-- * 19 EXISTS - <-- * 2 RECENT - <-- A0002 OK Select complete - {Wait for command} - A003 FETCH 1:19 ALL --> - <-- * 1 Fetch (......) - ... - <-- * 18 Fetch (......) - <-- * 19 Fetch (......) - <-- A003 OK Fetch complete - {Wait for command} - A004 FETCH 8 RFC822.TEXT --> - <-- * 8 Fetch (RFC822.TEXT {893} - ...893 characters of text... - <-- ) - <-- A004 OK Fetch complete - {Wait for command} - - - - - - - - -Crispin [Page 8] - -RFC 1176 IMAP2 August 1990 - - - A005 STORE 8 +Flags \Deleted --> - <-- * 8 Store (Flags (\Deleted - \Seen)) - <-- A005 OK Store complete - {Wait for command} - A006 EXPUNGE --> - <-- * 19 EXISTS - <-- * 8 EXPUNGE - <-- * 18 EXISTS - <-- A006 Expunge complete - {Wait for command} - A007 LOGOUT --> - <-- * BYE IMAP2 server quitting - <-- A007 OK Logout complete - {Close Connection} --><-- {Close connection} - {Go back to start} -Conventions - - The following terms are used in a meta-sense in the syntax - specification below: - - An ASCII-STRING is a sequence of arbitrary ASCII characters. - - An ATOM is a sequence of ASCII characters delimited by SP or CRLF. - - A CHARACTER is any ASCII character except """", "{", CR, LF, "%", - or "\". - - A CRLF is an ASCII carriage-return character followed immediately - by an ASCII linefeed character. - - A NUMBER is a sequence of the ASCII characters that represent - decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or - ":". - - A SP is the ASCII space character. - - A TEXT_LINE is a human-readable sequence of ASCII characters up to - but not including a terminating CRLF. - - A common field in the IMAP2 protocol is a STRING, which may be an - ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), - or a LITERAL. A literal consists of an open brace ("{"), a number, a - close brace ("}"), a CRLF, and then an ASCII-STRING of n characters, - where n is the value of the number inside the brace. In general, a - string should be represented as an ATOM or QUOTED-STRING if at all - possible. The semantics for QUOTED-STRING or LITERAL are checked - before those for ATOM; therefore an ATOM used in a STRING may only - - - -Crispin [Page 9] - -RFC 1176 IMAP2 August 1990 - - - contain CHARACTERs. Literals are most often sent from the server to - the client; in the rare case of a client to server literal there is a - special consideration (see the "+ text" response below). - - Another important field is the SEQUENCE, which identifies a set of - messages by consecutive numbers from 1 to n where n is the number of - messages in the mailbox. A sequence may consist of a single number, - a pair of numbers delimited by colon (equivalent to all numbers - between those two numbers), or a list of single numbers or number - pairs. For example, the sequence 2,4:7,9,12:15 is equivalent to - 2,4,5,6,7,9,12,13,14,15 and identifies all those messages. - -Definitions of Commands and Responses - - Summary of Commands and Responses - - Commands || Responses - -------- || ------- - tag NOOP || tag OK text - tag LOGIN user password || tag NO text - tag LOGOUT || tag BAD text - tag SELECT mailbox || * number message_data - tag BBOARD bulletin_board || * FLAGS flag_list - tag FIND MAILBOXES pattern || * SEARCH sequence - tag FIND BBOARDS pattern || * BBOARD string - tag CHECK || * MAILBOX string - tag EXPUNGE || * BYE text - tag COPY sequence mailbox || * OK text - tag FETCH sequence data || * NO text - tag STORE sequence data value || * BAD text - tag SEARCH search_program || + text - -Commands - - tag NOOP - - The NOOP command returns an OK to the client. By itself, it does - nothing, but certain things may happen as side effects. For - example, server implementations that implicitly check the mailbox - for new mail may do so as a result of this command. The primary - use of this command is to for the client to see if the server is - still alive (and notify the server that the client is still alive, - for those servers that have inactivity autologout timers). - - tag LOGIN user password - - The LOGIN command identifies the user to the server and carries - the password authenticating this user. This information is used - - - -Crispin [Page 10] - -RFC 1176 IMAP2 August 1990 - - - by the server to control access to the mailboxes. - - EXAMPLE: A001 LOGIN SMITH SESAME - logs in as user SMITH with password SESAME. - - tag LOGOUT - - The LOGOUT command informs the server that the client is done with - the session. The server should send an unsolicited BYE response - before the (tagged) OK response, and then close the network - connection. - - tag SELECT mailbox - - The SELECT command selects a particular mailbox. The server must - check that the user is permitted read access to this mailbox. - Before returning an OK to the client, the server must send the - following unsolicited data to the client: - FLAGS mailbox's defined flags - <n> EXISTS the number of messages in the mailbox - <n> RECENT the number of new messages in the mailbox - in order to define the initial state of the mailbox at the client. - - Multiple SELECT commands are permitted in a session, in which case - the previous mailbox is automatically deselected when a new SELECT - is made. - - The default mailbox for the SELECT command is INBOX, which is a - special name reserved to mean "the primary mailbox for this user - on this server". The format of other mailbox names is operating - system dependent (as of this writing, it reflects the filename - path of the mailbox file on the current servers). - - It is customary, although not required, for the text of an OK - response to the SELECT command to begin with either "[READ-ONLY]" - or "[READ-WRITE]" to show the mailbox's access status. - - EXAMPLE: A002 SELECT INBOX - selects the default mailbox. - - tag BBOARD bulletin_board - - The BBOARD command is equivalent to SELECT, and returns the same - output. However, it differs from SELECT in that its argument is a - shared mailbox (bulletin board) name instead of an ordinary - mailbox. The format of a bulletin name is implementation - specific, although it is strongly encouraged to use something that - resembles a name in a generic sense and not a file or mailbox name - - - -Crispin [Page 11] - -RFC 1176 IMAP2 August 1990 - - - on the particular system. There is no requirement that a bulletin - board name be a mailbox name or a file name (in particular, Unix - netnews has a completely different namespace from mailbox or file - names). - - Support for BBOARD is optional. - - tag FIND MAILBOXES pattern - - The FIND MAILBOXES command accepts as an argument a pattern - (including wildcards) that specifies some set of mailbox names - that are usable by the SELECT command. The format of mailboxes is - implementation dependent. The special mailbox name INBOX is not - included in the output. - - Two wildcard characters are defined; "*" specifies any number - (including zero) characters may match at this position and "%" - specifies a single character may match at this position. For - example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, - whereas FOO%BAR will match only FOO.BAR. "*" will match all - mailboxes. - - The FIND MAILBOXES command will return some set of unsolicited - MAILBOX replies that have as their value a single mailbox name. - - EXAMPLE: A002 FIND MAILBOXES * - * MAILBOX FOOBAR - * MAILBOX GENERAL - A002 FIND completed - - Although the use of explicit file or path names for mailboxes is - discouraged by this standard, it may be unavoidable. It is - important that the value returned in the MAILBOX unsolicited reply - be usable in the SELECT command without remembering any path - specification that may have been used in the FIND MAILBOXES - pattern. - - Support for FIND MAILBOXES is optional. If a client's attempt - returns BAD as a response then the client can make no assumptions - about what mailboxes exist on the server other than INBOX. - - tag FIND BBOARDS pattern - - The FIND BBOARDS command accepts as an argument a pattern that - specifies some set of bulletin board names that are usable by the - BBOARD command. Wildcards are permitted as in FIND MAILBOXES. - - The FIND BBOARDS command will return some set of unsolicited - - - -Crispin [Page 12] - -RFC 1176 IMAP2 August 1990 - - - BBOARD replies that have as their value a single bulletin board - name. - - EXAMPLE: A002 FIND BBOARDS * - * BBOARD FOOBAR - * BBOARD GENERAL - A002 FIND completed - - Support for FIND BBOARDS is optional. If a client's attempt - returns BAD as a response then the client can make no assumptions - about what bulletin boards exist on the server, or that they exist - at all. - - tag CHECK - - The CHECK command forces a check for new messages and a rescan of - the mailbox for internal change for those implementations that - allow multiple simultaneous read/write access to the same mailbox. - It is recommend that periodic implicit checks for new mail be done - by servers as well. The server should send unsolicited EXISTS and - RECENT responses with the current status before returning an OK to - the client. - - tag EXPUNGE - - The EXPUNGE command permanently removes all messages with the - \DELETED flag set in its flags from the mailbox. Before returning - an OK to the client, for each message that is removed, an - unsolicited EXPUNGE response is sent. The message number for each - successive message in the mailbox is immediately decremented by 1; - this means that if the last 5 messages in a 9-message mail file - are expunged you will receive 5 unsolicited EXPUNGE responses for - message 5. To ensure mailbox integrity and server/client - synchronization, it is recommended that the server do an implicit - check before commencing the expunge and again when the expunge is - completed. Furthermore, if the server allows multiple - simultaneous access to the same mail file the server must lock the - mail file for exclusive access while an expunge is taking place. - - EXPUNGE is not allowed if the user does not have write access to - this mailbox. - - tag COPY sequence mailbox - - The COPY command copies the specified message(s) to the specified - destination mailbox. If the destination mailbox does not exist, - the server should create it. Before returning an OK to the - client, the server should return an unsolicited <n> COPY response - - - -Crispin [Page 13] - -RFC 1176 IMAP2 August 1990 - - - for each message copied. A copy should set the \SEEN flag for all - messages that were successfully copied (provided, of course, that - the user has write access to this mailbox). - - EXAMPLE: A003 COPY 2:4 MEETING - copies messages 2, 3, and 4 to mailbox "MEETING". - - COPY is not allowed if the user does not have write access to the - destination mailbox. - - tag FETCH sequence data - - The FETCH command retrieves data associated with a message in the - mailbox. The data items to be fetched may be either a single atom - or an S-expression list. The currently defined data items that - can be fetched are: - - ALL Macro equivalent to: - (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) - - ENVELOPE The envelope of the message. The envelope is - computed by the server by parsing the RFC 822 - header into the component parts, defaulting - various fields as necessary. - - FAST Macro equivalent to: - (FLAGS INTERNALDATE RFC822.SIZE) - - FLAGS The flags that are set for this message. - This may include the following system flags: - - \RECENT Message arrived since the - previous time this mailbox - was read - \SEEN Message has been read - \ANSWERED Message has been answered - \FLAGGED Message is "flagged" for - urgent/special attention - \DELETED Message is "deleted" for - removal by later EXPUNGE - - INTERNALDATE The date and time the message was written to - the mailbox. - - - - - - - - -Crispin [Page 14] - -RFC 1176 IMAP2 August 1990 - - - RFC822 The message in RFC 822 format. The \SEEN - flag is implicitly set; if this causes the - flags to change they should be included as - part of the fetch results. This is the - concatenation of RFC822.HEADER and RFC822.TEXT. - - RFC822.HEADER The "raw" RFC 822 format header of the message - as stored on the server. - - RFC822.SIZE The number of characters in the message as - expressed in RFC 822 format. - - RFC822.TEXT The text body of the message, omitting the - RFC 822 header. The \SEEN flag is implicitly - set as with RFC822 above. - - EXAMPLES: - - A003 FETCH 2:4 ALL - fetches the flags, internal date, RFC 822 size, and envelope - for messages 2, 3, and 4. - - A004 FETCH 3 RFC822 - fetches the RFC 822 representation for message 3. - - A005 FETCH 4 (FLAGS RFC822.HEADER) - fetches the flags and RFC 822 format header for message 4. - - Note: An attempt to FETCH already-transmitted data may have no - result. See the Implementation Discussion below. - - tag STORE sequence data value - - The STORE command alters data associated with a message in the - mailbox. The currently defined data items that can be stored are: - - FLAGS Replace the flags for the message with the - argument (in flag list format). - - +FLAGS Add the flags in the argument to the - message's flag list. - - -FLAGS Remove the flags in the argument from the - message's flag list. - - STORE is not allowed if the user does not have write access to - this mailbox. - - - - -Crispin [Page 15] - -RFC 1176 IMAP2 August 1990 - - - EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) - marks messages 2, 3, and 4 for deletion. - - tag SEARCH search_criteria - - The SEARCH command searches the mailbox for messages that match - the given set of criteria. The unsolicited SEARCH <1#number> - response from the server is a list of messages that express the - intersection (AND function) of all the messages which match that - criteria. For example, - A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 - returns the message numbers for all deleted messages from Smith - that were placed in the mail file since October 1, 1987. - - In all search criteria which use strings, a message matches the - criteria if the string is a case-independent substring of that - field. The currently defined criteria are: - - ALL All messages in the mailbox; the default - initial criterion for ANDing. - - ANSWERED Messages with the \ANSWERED flag set. - - BCC string Messages which contain the specified string - in the envelope's BCC field. - - BEFORE date Messages whose internal date is earlier than - the specified date. - - BODY string Messages which contain the specified string - in the body of the message. - - CC string Messages which contain the specified string - in the envelope's CC field. - - DELETED Messages with the \DELETED flag set. - - FLAGGED Messages with the \FLAGGED flag set. - - FROM string Messages which contain the specified string - in the envelope's FROM field. - - KEYWORD flag Messages with the specified flag set. - - NEW Messages which have the \RECENT flag set but - not the \SEEN flag. This is functionally - equivalent to "RECENT UNSEEN". - - - - -Crispin [Page 16] - -RFC 1176 IMAP2 August 1990 - - - OLD Messages which do not have the \RECENT flag - set. - - ON date Messages whose internal date is the same as - the specified date. - - RECENT Messages which have the \RECENT flag set. - - SEEN Messages which have the \SEEN flag set. - - SINCE date Messages whose internal date is later than - the specified date. - - SUBJECT string Messages which contain the specified string - in the envelope's SUBJECT field. - - TEXT string Messages which contain the specified string. - - TO string Messages which contain the specified string in - the envelope's TO field. - - UNANSWERED Messages which do not have the \ANSWERED flag - set. - - UNDELETED Messages which do not have the \DELETED flag - set. - - UNFLAGGED Messages which do not have the \FLAGGED flag - set. - - UNKEYWORD flag Messages which do not have the specified flag - set. - - UNSEEN Messages which do not have the \SEEN flag set. - - - - - - - - - - - - - - - - - -Crispin [Page 17] - -RFC 1176 IMAP2 August 1990 - - -Responses - - tag OK text - - This response identifies successful completion of the command with - that tag. The text is a line of human-readable text that may be - useful in a protocol telemetry log for debugging purposes. - - tag NO text - - This response identifies unsuccessful completion of the command - with that tag. The text is a line of human-readable text that - probably should be displayed to the user in an error report by the - client. - - tag BAD text - - This response identifies faulty protocol received from the client; - The text is a line of human-readable text that should be recorded - in any telemetry as part of a bug report to the maintainer of the - client. - - * number message_data - - This response occurs as a result of several different commands. - The message_data is one of the following: - - EXISTS The specified number of messages exists in the mailbox. - - RECENT The specified number of messages have arrived since the - previous time this mailbox was read. - - EXPUNGE The specified message number has been permanently - removed from the mailbox, and the next message in the - mailbox (if any) becomes that message number. - - STORE data - Obsolete and functionally equivalent to FETCH. - - FETCH data - This is the principle means by which data about a - message is returned to the client. The data is in a - Lisp-like S-expression property list form. The current - properties are: - - ENVELOPE An S-expression format list that describes the - envelope of a message. The envelope is computed - by the server by parsing the RFC 822 header into - - - -Crispin [Page 18] - -RFC 1176 IMAP2 August 1990 - - - the component parts, defaulting various fields - as necessary. - - The fields of the envelope are in the following - order: date, subject, from, sender, reply-to, to, - cc, bcc, in-reply-to, and message-id. The date, - subject, in-reply-to, and message-id fields are - strings. The from, sender, reply-to, to, cc, - and bcc fields are lists of addresses. - - An address is an S-expression format list that - describes an electronic mail address. The fields - of an address are in the following order: - personal name, source-route (a.k.a. the - at-domain-list in SMTP), mailbox name, and - host name. - - Any field of an envelope or address that is - not applicable is presented as the atom NIL. - Note that the server must default the reply-to - and sender fields from the from field; a client is - not expected to know to do this. - - FLAGS An S-expression format list of flags that are set - for this message. This may include the following - system flags: - - \RECENT Message arrived since the - previous time this mailbox - was read - \SEEN Message has been read - \ANSWERED Message has been answered - \FLAGGED Message is "flagged" for - urgent/special attention - \DELETED Message is "deleted" for - removal by later EXPUNGE - - INTERNALDATE A string containing the date and time the - message was written to the mailbox. - - RFC822 A string expressing the message in RFC 822 - format. - - RFC822.HEADER A string expressing the RFC 822 format - header of the message - - RFC822.SIZE A number indicating the number of - characters in the message as expressed - - - -Crispin [Page 19] - -RFC 1176 IMAP2 August 1990 - - - in RFC 822 format. - - RFC822.TEXT A string expressing the text body of the - message, omitting the RFC 822 header. - - * FLAGS flag_list - - This response occurs as a result of a SELECT command. The flag - list are the list of flags (at a minimum, the system-defined - flags) that are applicable for this mailbox. Flags other than the - system flags are a function of the server implementation. - - * SEARCH number(s) - - This response occurs as a result of a SEARCH command. The - number(s) refer to those messages that match the search criteria. - Each number is delimited by a space, e.g., "SEARCH 2 3 6". - - * BBOARD string - - This response occurs as a result of a FIND BBOARDS command. The - string is a bulletin board name that matches the pattern in the - command. - - * MAILBOX string - - This response occurs as a result of a FIND MAILBOXES command. The - string is a mailbox name that matches the pattern in the command. - - * BYE text - - This response identifies that the server is about to close the - connection. The text is a line of human-readable text that should - be displayed to the user in a status report by the client. This - may be sent as part of a normal logout sequence, or as a panic - shutdown announcement by the server. It is also used by some - servers as an announcement of an inactivity autologout. - - * OK text - - This response identifies normal operation on the server. No - special action by the client is called for, however, the text - should be displayed to the user in some fashion. This is - currently only used by servers at startup as a greeting message to - show they are ready to accept the first command. - - - - - - -Crispin [Page 20] - -RFC 1176 IMAP2 August 1990 - - - * NO text - - This response identifies a warning from the server that does not - affect the overall results of any particular request. The text is - a line of human-readable text that should be presented to the user - as a warning of improper operation. - - * BAD text - - This response identifies a serious error at the server; it may - also indicate faulty protocol from the client in which a tag could - not be parsed. The text is a line of human-readable text that - should be presented to the user as a serious or possibly fatal - error. It should also be recorded in any telemetry as part of a - bug report to the maintainer of the client and server. - - + text - - This response identifies that the server is ready to accept the - text of a literal from the client. Normally, a command from the - client is a single text line. If the server detects an error in - the command, it can simply discard the remainder of the line. It - cannot do this for commands that contain literals, since a literal - can be an arbitrarily long amount of text, and the server may not - even be expecting a literal. This mechanism is provided so the - client knows not to send a literal until the server expects it, - preserving client/server synchronization. - - In practice, this condition is rarely encountered. In the current - protocol, the only client command likely to contain a literal is - the LOGIN command. Consider a server that validates the user - before checking the password. If the password contains "funny" - characters and hence is sent as a literal, then if the user is - invalid an error would occur before the password is parsed. - - No such synchronization protection is provided for literals sent - from the server to the client, for performance reasons. Any - synchronization problems in this direction would be caused by a - bug in the client or server. - - - - - - - - - - - - -Crispin [Page 21] - -RFC 1176 IMAP2 August 1990 - - -Sample IMAP2 session - - The following is a transcript of an IMAP2 session. Server output is - identified by "S:" and client output by "U:". In cases where lines - are too long to fit within the boundaries of this document, the line - is continued on the next line. - - S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service - 6.1(349) at Thu, 9 Jun 88 14:58:30 PDT - U: a001 login crispin secret - S: a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76 - U: a002 select inbox - S: * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question - Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen) - S: * 16 EXISTS - S: * 0 RECENT - S: a002 OK Select complete - U: a003 fetch 16 all - S: * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT" - RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT" - "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN" - "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN" - "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN" - "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH" - "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL - "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) - S: a003 OK Fetch completed - U: a004 fetch 16 rfc822 - S: * 16 Fetch (RFC822 {637} - S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43 - S: Mail-From: FAGAN created at 4-Jun-88 13:27:12 - S: Date: Sat, 4 Jun 88 13:27:11 PDT - S: From: Larry Fagan <FAGAN@SUMEX-AIM.Stanford.EDU> - S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU - S: Subject: INFO-MAC Mail Message - S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> - S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT - S: ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU> - S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, - Crispin@SUMEX-AIM.Stanford.EDU - S: ReSent-Message-ID: - <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> - S: - S: The file is <info-mac>usenetv4-55.arc ... - S: Larry - S: ------- - S: ) - S: a004 OK Fetch completed - - - -Crispin [Page 22] - -RFC 1176 IMAP2 August 1990 - - - U: a005 logout - S: * BYE DEC-20 IMAP II server terminating connection - S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol - Service logout - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Crispin [Page 23] - -RFC 1176 IMAP2 August 1990 - - -Implementation Discussion - - There are several advantages to the scheme of tags and unsolicited - responses. First, the infamous synchronization problems of SMTP and - similar protocols do not happen with tagged commands; a command is - not considered satisfied until a response with the same tag is seen. - Tagging allows an arbitrary amount of other responses ("unsolicited" - data) to be sent by the server with no possibility of the client - losing synchronization. Compare this with the problems that FTP or - SMTP clients have with continuation, partial completion, and - commentary reply codes. - - Another advantage is that a non-lockstep client implementation is - possible. The client could send a command, and entrust the handling - of the server responses to a different process that would signal the - client when the tagged response comes in. Under certain - circumstances, the client may have more than one command outstanding. - - It was observed that synchronization problems can occur with literals - if the literal is not recognized as such. Fortunately, the cases in - which this can happen are rare; a mechanism (the special "+" tag - response) was introduced to handle those few cases. The proper way - to address this problem is probably to move towards a record-oriented - architecture instead of the text stream model provided by TCP. - - An IMAP2 client must maintain a local cache of data from the mailbox. - This cache is an incomplete model of the mailbox, and at startup is - empty. A listener processes all unsolicited data, and updates the - cache based on this data. If a tagged response arrives, the listener - unblocks the process that sent the tagged request. - - Unsolicited data needs some discussion. Unlike most protocols, in - which the server merely does the client's bidding, an IMAP2 server - has a semi-autonomous role. By sending "unsolicited data", the - server is in effect sending a command to the client -- to update or - extend the client's cache with new information from the server. In - other words, a "fetch" command is merely a request to the server to - ensure that the client's cache has the most up-to-date version of the - requested information. A server acknowledgement to the "fetch" is a - statement that all the requested data has been sent. - - Although no current server does this, a server is not obliged by the - protocol to send data that it has already sent and is unchanged. An - exception to this is the actual message text fetching operations - (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly - excessive resource consumption of maintaining this data in a cache. - It can not be assumed that a FETCH will transmit any data; only that - an OK to the FETCH means that the client's cache has the most up-to- - - - -Crispin [Page 24] - -RFC 1176 IMAP2 August 1990 - - - date information. - - When a mailbox is selected, the initial unsolicited data from the - server arrives. The first piece of data is the number of messages. - By sending a new EXISTS unsolicited data message the server causes - the client to resize its cache (this is how newly arrived mail is - handled). If the client attempts to access information from the - cache, it will encounter empty spots that will trigger "fetch" - requests. The request would be sent, some unsolicited data including - the answer to the fetch will flow back, and then the "fetch" response - will unblock the client. - - People familiar with demand-paged virtual memory operating system - design will recognize this model as being similar to page-fault - handling on a demand-paged system. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Crispin [Page 25] - -RFC 1176 IMAP2 August 1990 - - -Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in RFC 822 with one exception; the - delimiter used with the "#" construct is a single space (SP) and not - a comma. - - address ::= "(" addr_name SP addr_adl SP addr_mailbox SP - addr_host ")" - - addr_adl ::= nil / string - - addr_host ::= nil / string - - addr_mailbox ::= nil / string - - addr_name ::= nil / string - - bboard ::= "BBOARD" SP string - - check ::= "CHECK" - - copy ::= "COPY" SP sequence SP mailbox - - data ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number / - "BYE" SP text_line / "OK" SP text_line / - "NO" SP text_line / "BAD" SP text_line) - - date ::= string in form "dd-mmm-yy hh:mm:ss-zzz" - - envelope ::= "(" env_date SP env_subject SP env_from SP - env_sender SP env_reply-to SP env_to SP - env_cc SP env_bcc SP env_in-reply-to SP - env_message-id ")" - - env_bcc ::= nil / "(" 1*address ")" - - env_cc ::= nil / "(" 1*address ")" - - env_date ::= string - - env_from ::= nil / "(" 1*address ")" - - env_in-reply-to ::= nil / string - - env_message-id ::= nil / string - - env_reply-to ::= nil / "(" 1*address ")" - - - -Crispin [Page 26] - -RFC 1176 IMAP2 August 1990 - - - env_sender ::= nil / "(" 1*address ")" - - env_subject ::= nil / string - - env_to ::= nil / "(" 1*address ")" - - expunge ::= "EXPUNGE" - - fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / - fetch_att / "(" 1#fetch_att ")") - - fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / - "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / - "RFC822.TEXT" - - find ::= "FIND" SP find_option SP string - - find_option ::= "MAILBOXES" / "BBOARDS" - - flag_list ::= ATOM / "(" 1#ATOM ")" - - literal ::= "{" NUMBER "}" CRLF ASCII-STRING - - login ::= "LOGIN" SP userid SP password - - logout ::= "LOGOUT" - - mailbox ::= "INBOX" / string - - msg_copy ::= "COPY" - - msg_data ::= (msg_exists / msg_recent / msg_expunge / - msg_fetch / msg_copy) - - msg_exists ::= "EXISTS" - - msg_expunge ::= "EXPUNGE" - - msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP - envelope / "FLAGS" SP "(" 1#(recent_flag - flag_list) ")" / "INTERNALDATE" SP date / - "RFC822" SP string / "RFC822.HEADER" SP string / - "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP - string) ")" - - msg_recent ::= "RECENT" - - msg_num ::= NUMBER - - - -Crispin [Page 27] - -RFC 1176 IMAP2 August 1990 - - - nil ::= "NIL" - - noop ::= "NOOP" - - password ::= string - - recent_flag ::= "\RECENT" - - ready ::= "+" SP text_line - - request ::= tag SP (noop / login / logout / select / check / - expunge / copy / fetch / store / search / find / - bboard) CRLF - - response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF - - search ::= "SEARCH" SP 1#("ALL" / "ANSWERED" / - "BCC" SP string / "BEFORE" SP string / - "BODY" SP string / "CC" SP string / "DELETED" / - "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / - "ON" SP string / "RECENT" / "SEEN" / - "SINCE" SP string / "TEXT" SP string / - "TO" SP string / "UNANSWERED" / "UNDELETED" / - "UNFLAGGED" / "UNKEYWORD" / "UNSEEN") - - select ::= "SELECT" SP mailbox - - sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" - sequence) - - store ::= "STORE" SP sequence SP store_att - - store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / - "FLAGS" SP flag_list) - - string ::= atom / """" 1*character """" / literal - - system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP - "\SEEN" - - tag ::= atom - - unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF - - userid ::= string - - - - - - -Crispin [Page 28] - -RFC 1176 IMAP2 August 1990 - - -Implementation Status - - This information is current as of this writing. - - The University of Washington has developed an electronic mail client - library called the "C-Client". It provides complete IMAP2, SMTP, and - local mailbox (both /usr/spool/mail and mail.txt formats) services in - a well-defined way to a user interface main program. Using the C- - Client, the University of Washington has created an operational - client for BSD Unix and two operational clients (one basic, one - advanced) for the NeXT. - - Stanford University/SUMEX has developed operational IMAP2 clients for - Xerox Lisp machines, Texas Instruments Explorers, and the Apple - Macintosh. The core of the Macintosh client is an early version of - the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20 and - BSD Unix. - - All of the above software is in production use, with enthusiastic - local user communities. Active development continues on the - Macintosh and C-Client based clients and the BSD Unix server. This - software is freely available from the University of Washington and - SUMEX. - - IMAP2 software exists for other platforms; for example Nippon - Telephone and Telegraph (NTT) has developed an operational IMAP2 - client for the NTT ELIS. Several organizations are working on a PC - client. - - IMAP2 can be used to access mailboxes at very remote sites, where - echo delays and frequent outages make TELNET and running a local mail - reader intolerable. For example, from a desktop workstation on the - University of Washington local network the author routinely uses - IMAP2 to read and manage mailboxes on various University of - Washington local servers, at two systems at Stanford University, at a - Milnet site, and at a site in Tokyo, Japan. - - This specification does not make any formal definition of size - restrictions, but the DEC-20 server has the following limitations: - - . length of a mailbox: 7,077,888 characters - . maximum number of messages: 18,432 messages - . length of a command line: 10,000 characters - . length of the local host name: 64 characters - . length of a "short" argument: 39 characters - . length of a "long" argument: 491,520 characters - . maximum amount of data output in a single fetch: - 655,360 characters - - - -Crispin [Page 29] - -RFC 1176 IMAP2 August 1990 - - - To date, nobody has run up against any of these limitations, many of - which are substantially larger than most current user mail reading - programs. - -Acknowledgements - - Bill Yeager and Rich Acuff both contributed invaluable suggestions in - the evolution of IMAP2 from the original IMAP. James Rice pointed - out several ambiguities in the previous IMAP2 specification and - otherwise would not allow me to leave bad enough along. Laurence - Lundblade reviewed a draft of this version and made several helpful - suggestions. - - Many dedicated individuals have worked on IMAP2 software, including: - Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno, - Christopher Schmidt, and Bill Yeager. - - Any mistakes, flaws, or sins of omission in this IMAP2 protocol - specification are, however, strictly my own; and the mention of any - name above does not imply an endorsement. - -Security Considerations - - Security issues are not discussed in this memo. - -Author's Address - - Mark R. Crispin - Panda Programming - 6158 Lariat Loop NE - Bainbridge Island, WA 98110-2020 - - Phone: (206) 842-2385 - - EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU - - - - - - - - - - - - - - - - -Crispin [Page 30] -
\ No newline at end of file diff --git a/RFC/rfc1203.txt b/RFC/rfc1203.txt deleted file mode 100644 index a362ca88..00000000 --- a/RFC/rfc1203.txt +++ /dev/null @@ -1,2747 +0,0 @@ - - - - - - -Network Working Group J. Rice -Request for Comments: 1203 Stanford -Obsoletes: RFC 1064 February 1991 - - - INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3 - -Status of this Memo - - This RFC suggests a method for workstations to access mail - dynamically from a mailbox server ("repository"). This RFC specifies - a standard for the SUMEX-AIM community and an Experimental Protocol - for the Internet community. Discussion and suggestions for - improvement are requested. Please refer to the current edition of - the "IAB Official Protocol Standards" for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Scope - - The following document is a modified version of RFC 1064, the - definition of the IMAP2 protocol. This RFC has been written - specifically as a counter proposal to RFC 1176, which itself proposes - modifications to IMAP2. Sadly, RFC 1176 was made without internal - consultation with the IMAP community, so we are in a position of - feeling we have to present a counter proposal to what, if we do not - act, will become a de facto standard. The reasons for this counter - proposal are numerous but fall mostly into the following categories: - - - IMAP2 is insufficiently powerful for a number of server/client - interactions which we believe to be important. RFC 1176 - negligibly enhances the functionality of IMAP2. - - - IMAP2 makes what we believe to be an erroneous definition for - unsolicited vs. solicited data. IMAP3 as specified herein - attempts to correct this. RFC 1176 makes no effort to remedy - these problems. - - - RFC 1176 has explicitly modified the intent of RFC 1064 by - allowing the server to make assumptions about the client's - caching architecture. We believe this to be a grave error - and do not support it in this proposal. - - - RFC 1176 specifies a number of "optional" features in the - protocol without specifying a suitable metaprotocol by which - servers and clients can adequately negotiate over the set of - implemented features. This proposal specifies a mechanism - by which servers and clients can come to an unambiguous - understanding about which features are usable by each party. - - - -Rice [Page 1] - -RFC 1203 IMAP3 February 1991 - - - - - RFC 1176 pays only lip-service to being network protocol - independent and, in fact assumes the use of TCP/IP. Neither - RFC 1064 nor this proposal make any such assumption. - - Although there are numerous other detailed objections to RFC 1176, we - believe that the above will serve to show that we believe strongly in - the importance of mailbox abstraction level mail protocols and, after - a couple of years of use of IMAP2 under RFC 1064 we believe that we - have a good enough understanding of the issues involved to be able to - take the next step. - - It is important to take this next step because of the rapid pace of - both mail system and user interface development. We believe that, - for IMAP not to die in its infancy, IMAP must be ready to respond to - emerging ISO and RFC standards in mail, such as for multi-media mail. - We believe that RFC 1176 not only provides a very small increment in - functionality over RFC 1064 but also adds a number of bugs, which - would be detrimental to the IMAP cause. Thus we propose the - following definition for IMAP3. - -Compatibility notes: - - In revising the IMAP2 protocol it has been our intent, wherever - possible to make upwards compatible changes to produce IMAP3. There - were, however, some places that had to be changed incompatibly in - order to compensate for either ambiguities in the IMAP2 protocol as - defined by RFC 1064 or behavior that proved undesirable in the light - of experience. - - It is our goal, however, that existing IMAP2 clients should still be - supported and that, at least for the foreseeable future, all IMAP3 - servers will support IMAP2 behavior as their default mode. - - The following are the major differences between this proposal, RFC - 1176 and RFC 1064: - - - In this proposal we specify a difference between "solicited" and - "unsolicited" data sent from the server. It is generally the - case that data sent by the server can be sent either in response - to an explicit request by the client or by the server of its own - volition. Any data that the server is required to sent to the - client as the result of a request is said to be solicited and - carries the same tag as the request that provoked it. Any data - sent by the server to the client that is not required by the - protocol is said to be unsolicited and carries the special "*" - tag. RFC 1176 preserves the original RFC 1064 terminology that - calls all such data sent by the server "unsolicited" even when - - - -Rice [Page 2] - -RFC 1203 IMAP3 February 1991 - - - it is, in fact, solicited. - - - This proposal introduces the experimental concept of - distinguishing between Generic, Canonical and Concrete keys, - allowing the mailbox to be viewed as a relational database - indexed by these keys. This should allow the IMAP protocol - to evolve away from its current reliance on RFC 822. RFC 1176 - does not have such a unifying model. - - - The SEARCH command has been changed so as to allow multiple - simultaneous searches to be made and to allow unsolicited - search messages to be sent by the server. Such a change is - essential to allow more sophisticated servers that can process - commands asynchronously, possibly substantially delaying - searches over slow backing storage media, for example. It is - also important to allow servers to be able to send unsolicited - search messages that might inform the client of interesting - patterns of messages, such as new and unseen mail. - - - This proposal introduces a specific protocol for the negotiation - of protocol versions and server features. This is important - because it allows client/server pairs to come to an agreement on - what behavior is really available to it. RFC 1176 introduces a - number of "optional" commands, which are in some way analogous - to "feature-introduced" commands in this proposal. The principle - distinction between these is that in RFC 1176 there is no way - for a client to discover the set of optional commands, nor is - there a way for it to determine whether a specific command - really is supported, since RFC 1176 requires the use of the - "BAD" response if a feature is not supported. There is, - therefore, no way for the client to determine why the attempted - command did not work. This also means that, for example, a - client cannot disable certain user commands or make them - invisible on menus if they are not supported, since there - is no way for the client to discover whether the commands are - indeed supported without trying to execute such a command. - - - This proposal introduces a mechanism for clients to create and - delete user flags (keywords). This is nor supported in either - RFC 1176 or RFC 1064, requiring the user to add keys manually - on the server, generally by editing some form of "init" file. - - - RFC 1064 has no mechanism for determining whether a mailbox is - readonly or not. RFC 1176 introduces a non-enforced convention - of encoding data about the readonly status of a mailbox in the - SELECT message's OK respose comment field. This is not regular - with respect to the rest of the protocol, in which the comment - field is used for no purpose other than documentation. This - - - -Rice [Page 3] - -RFC 1203 IMAP3 February 1991 - - - proposal introduces specific protocol additions for the dynamic - determination and modification of the readonly/readwrite status - of mailboxes. - -Introduction - - The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3) - is to allow a (possibly unreliable) workstation or similar machine to - access electronic mail from a reliable mailbox server in an efficient - manner. - - Although different in many ways from POP2 (RFC 937), IMAP3 may be - thought of as a functional superset of POP2, and the POP2 RFC was - used as a model for this RFC. There was a cognizant reason for this; - RFC 937 deals with an identical problem and it was desirable to offer - a basis for comparison. - - Like POP2, IMAP3 specifies a means of accessing stored mail and not - of posting mail; this function is handled by a mail transfer protocol - such as SMTP (RFC 821). A comparison with the DMSP protocol of - PCMAIL can be found at the end of "System Model and Philosophy" - section. - - This protocol assumes a reliable data stream such as provided by TCP - or any similar protocol. When TCP is used, the IMAP server listens - on port 220. When CHAOS is used the IMAP server listens for the - logical contact name "IMAP3". - - Communication in IMAP is defined to be using the ASCII character - interpretation of data. Communication using other conventions may be - possible by the selection of features on some servers. - -System Model and Philosophy - - Electronic mail is a primary means of communication for the widely - spread SUMEX-AIM community. The advent of distributed workstations - is forcing a significant rethinking of the mechanisms employed to - manage such mail. With mainframes, each user tends to receive and - process mail at the computer he used most of the time, his "primary - host". The first inclination of many users when an independent - workstation is placed in front of them is to begin receiving mail at - the workstation, and, in fact, many vendors have implemented - facilities to do this. However, this approach has several - disadvantages: - - (1) Workstations (especially Lisp workstations) have a software - design that gives full control of all aspects of the system - to the user at the console. As a result, background tasks, - - - -Rice [Page 4] - -RFC 1203 IMAP3 February 1991 - - - like receiving mail, could well be kept from running for - long periods of time either because the user is asking to - use all of the machine's resources, or because, in the course - of working, the user has (perhaps accidentally) manipulated - the environment in such a way as to prevent mail reception. - This could lead to repeated failed delivery attempts by - outside agents. - - (2) The hardware failure of a single workstation could keep its - user "off the air" for a considerable time, since repair of - individual workstation units might be delayed. Given the - growing number of workstations spread throughout office - environments, quick repair would not be assured, whereas a - centralized mainframe is generally repaired very soon after - failure. - - (3) It is more difficult to keep track of mailing addresses when - each person is associated with a distinct machine. Consider - the difficulty in keeping track of a large number of postal - addresses or phone numbers, particularly if there was no - single address or phone number for an organization through - which you could reach any person in that organization. - Traditionally, electronic mail on the ARPANET involved - remembering a name and one of several "hosts" (machines) - whose name reflected the organization in which the - individual worked. This was suitable at a time when most - organizations had only one central host. It is less - satisfactory today unless the concept of a host is changed - to refer to an organizational entity and not a particular - machine. - - (4) It is very difficult to keep a multitude of heterogeneous - workstations working properly with complex mailing protocols, - making it difficult to move forward as progress is made in - electronic communication and as new standards emerge. Each - system has to worry about receiving incoming mail, routing - and delivering outgoing mail, formatting, storing, and - providing for the stability of mailboxes over a variety of - possible filing and mailing protocols. - - Consequently, while the workstation may be viewed as an Internet host - in the sense that it implements IP, it should not be viewed as the - entity which contains the user's mailbox. Rather, a mail server - machine (sometimes called a "repository") should hold the mailbox, - and the workstation (hereafter referred to as a "client") should - access the mailbox via mail transactions. Because the mail server - machine would be isolated from direct user manipulation, it could - achieve high software reliability easily, and, as a shared resource, - - - -Rice [Page 5] - -RFC 1203 IMAP3 February 1991 - - - it could achieve high hardware reliability, perhaps through - redundancy. The mail server could be used from arbitrary locations, - allowing users to read mail across campus, town, or country using - more and more commonly available clients. Furthermore, the same user - may access his mailbox from different clients at different times, and - multiple users may access the same mailbox simultaneously. - - The mail server acts an an interface among users, data storage, and - other mailers. The mail access protocol is used to retrieve - messages, access and change properties of messages, and manage - mailboxes. This differs from some approaches (e.g., Unix mail via - NFS) in that the mail access protocol is used for all message - manipulations, isolating the user and the client from all knowledge - of how the data storage is used. This means that the mail server can - utilize the data storage in whatever way is most efficient to - organize the mail in that particular environment, without having to - worry about storage representation compatibility across different - machines. - - In defining a mail access protocol, it is important to keep in mind - that the client and server form a macrosystem, in which it should be - possible to exploit the strong points of both while compensating for - each other's weaknesses. Furthermore, it's desirable to allow for a - growth path beyond the hoary text-only RFC 822 protocol. Unlike - POP2, IMAP3 has extensive features for remote searching and parsing - of messages on the server. For example, a free text search - (optionally in conjunction with other searching) can be made - throughout the entire mailbox by the server and the results made - available to the client without the client having to transfer the - entire mailbox and searching itself. Since remote parsing of a - message into a structured (and standard format) "envelope" is - available, a client can display envelope information and implement - commands such as REPLY without having any understanding of how to - parse RFC 822, etc., headers. - - Additionally, IMAP3 offers several facilities for managing a mailbox - beyond the simple "delete message" functionality of POP2. - - In spite of this, IMAP3 is a relatively simple protocol. Although - servers should implement the full set of IMAP3 functions, a simple - client can be written which uses IMAP3 in much the way as a POP2 - client. - - IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more - fundamental manner, reflecting the differing architectures of IMAP - and PCMAIL. PCMAIL is either an online ("interactive mode"), or - offline ("batch mode") system. IMAP is primarily an online system in - which real-time and simultaneous mail access were considered - - - -Rice [Page 6] - -RFC 1203 IMAP3 February 1991 - - - important. - - In PCMAIL, there is a long-term client/server relationship in which - some mailbox state is preserved on the client. There is a - registration of clients used by a particular user, and the client - keeps a set of "descriptors" for each message which summarize the - message. The server and client synchronize their states when the - DMSP connection starts up, and, if a client has not accessed the - server for a while, the client does a complete reset (reload) of its - state from the server. - - In IMAP, the client/server relationship lasts only for the duration - of the IMAP3 connection. All mailbox state is maintained on the - server. There is no registration of clients. The function of a - descriptor is handled by a structured representation of the message - "envelope". This structure makes it unnecessary for a client to know - anything about RFC 822 parsing. There is no synchronization since - the client does not remember state between IMAP3 connections. This - is not a problem since in general the client never needs the entire - state of the mailbox in a single session, therefore there isn't much - overhead in fetching the state information that is needed as it is - needed. - - There are also some functional differences between IMAP3 and DMSP. - DMSP has functions for sending messages, printing messages, and - changing passwords, all of which are done outside of IMAP3. DMSP has - 16 binary flags of which 8 are defined by the system. IMAP has flag - names; there are currently 5 defined system flag names and a facility - for some number (29 in the current implementations) of user flag - names. IMAP3 has a sophisticated message search facility in the - server to identify interesting messages based on dates, addresses, - flag status, or textual contents without compelling the client to - fetch this data for every message. - - It was felt that maintaining state on the client is advantageous only - in those cases where the client is only used by a single user, or if - there is some means on the client to restrict access to another - user's data. It can be a serious disadvantage in an environment in - which multiple users routinely use the same client, the same user - routinely uses different clients, and where there are no access - restrictions on the client. It was also observed that most user mail - access is to a relatively small set of "interesting" messages, which - were either "new" mail or mail based upon some user-selected - criteria. Consequently, IMAP3 was designed to easily identify those - "interesting" messages so that the client could fetch the state of - those messages and not those that were not "interesting". - - One crucial philosophical difference between IMAP and other common - - - -Rice [Page 7] - -RFC 1203 IMAP3 February 1991 - - - mail protocols is that IMAP is a mailbox access protocol, not a - protocol for manipulating mail files. In the IMAP model, unlike - other mail system models in which mail is stored in a linear mail - file, no specification is made for the implementation architecture - for mail storage. Servers may choose to implement mailboxes as files - but this is a detail of which the client can be totally unaware. - - What is more, in the IMAP model, mailboxes are viewed as mappings - from keys into values. There are broadly three types of keys, - generic, canonical and concrete. Generic keys are generic, mail - protocol independent keys defined by IMAP which are meaningful across - multiple mail encoding formats. An example of such a generic key - might be "TO", which would be associated with the "To:" field of an - RFC 822 format message. - - Canonical keys represent the way in which the server can associate - values that are generally "about" a certain key concept, possibly - integrating several mail format specific fields, without having to - worry the client with the particular details of any particular - message format. Thus, the canonical TO key (called $TO) could denote - anything that could reasonably be construed as being directed towards - someone. Hence, in an RFC 822 message the server could find the - union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to - be the appropriate value associated with the canonical $TO key. - - Concrete keys allow the client to gain access to certain mail format - specific concepts, that are not pre-specified by the IMAP protocol, - in a well defined manner. For example, If the client asks for the - value associated with the "APPARENTLY-TO" key then, if the message - were to be in RFC 822 format, the server would look for a header - field called "Apparently-To:". If no such field is found or the - field is not implemented or meaningful for the particular message - format then the server will respond with the null value, called NIL, - indicating the non-existence of the field. - - Thus, IMAP servers are at liberty to implement mailboxes as a - relational databases if it seems convenient. Indeed, we anticipate - that future mail systems will tend to use database technology for the - storage and indexing of mailboxes as a result of the pressure caused - by the increasing size of mailboxes. - - Although for historical reasons IMAP is currently somewhat closely - associated with RFC 822, we anticipate that future developments in - IMAP will remove these mail format specific components and will move - towards the generic model mentioned above. This will allow IMAP more - easily to incorporate such things as multi-media mail. - - - - - -Rice [Page 8] - -RFC 1203 IMAP3 February 1991 - - -The Protocol - - The IMAP3 protocol consists of a sequence of client commands and - server responses to those commands, with extra information from the - server data being sent asynchronously to and independent to the - responses to client commands. Unlike most Internet protocols, - commands and responses are tagged. That is, a command begins with a - unique identifier (typically a short alphanumeric sequence such as a - Lisp "gensym" function would generate e.g., A0001, A0002, etc.), - called a tag. The response to this command is given the same tag - from the server. - - We distinguish between data sent by the server as the result of a - client request, which we term "SOLICITED" and data sent by the server - not as the result of a client request, which we term "UNSOLICITED". - The server may send unsolicited data at any time that would not - fragment another piece of data on the same stream rendering it - unintelligible. The server is contractually required, however, to - return all data that is solicited by the client before the return of - the completion signal for that command, i.e., all solicited data must - be returned within the temporal extent of the request/completion - acknowledgement wrapper. This does not, however, preclude the - simultaneous processing of multiple requests by the client, it simply - requires that the client be confident that it has all the requested - data when a request finishes. This allows the implementation of both - synchronous and asynchronous clients. - - Solicited data is identified by the tag of the initial request by the - client. Unsolicited data is identified by the special reserved tag - of "*". There is another special reserved tag, "+", discussed below. - - Note: the tagging of SOLICITED data is only permitted for a selected - server version other than 2.0. - - No assumptions concerning serial or monolithic processing by the - server can be made by a correct client. The server is at liberty to - process multiple requests by the same client in any order. This - allows servers to process costly searches over mailboxes on slow - backing storage media in the background, while still preserving - interactive performance. Clients can, however, assume the - serialization of the request/data/completion behavior mentioned - above. - - When a connection is opened the server sends an unsolicited OK - response as a greeting message and then waits for commands. When - commands are received the server acts on them and responds with - responses, often interspersed with data. - - - - -Rice [Page 9] - -RFC 1203 IMAP3 February 1991 - - - The client opens a connection, waits for the greeting, then sends a - LOGIN command with user name and password arguments to establish - authorization. Following an OK response from the server, the client - then sends a SELECT command to access the desired mailbox. The - user's default mailbox has a special reserved name of "INBOX" which - is independent of the operating system that the server is implemented - on. The server will generally send a list of valid flags, number of - messages, and number of messages arrived since last access for this - mailbox as solicited data, followed by an OK response. The client - may terminate access to this mailbox and access a different one with - another SELECT command. - - Because the SELECT command affects the state of the server in a - fundamental way, the server is required to process all outstanding - commands for any given mailbox before sending the OK tag for the - SELECT command. Thus, the client will always know that all responses - before an OK SELECT response will refer to the old mailbox and all - responses following it will apply to the new mailbox. - - Because, in the real world, local needs or experimental work will - dictate that servers will support both supersets of the defined - behavior and incompatible changes, servers will support a - SELECT.VERSION command and a SELECT.FEATURES command, the purpose of - which is to allow clients to select the overall behavior and specific - features that they want from a server. The default behavior of any - server is to process commands and to have interaction syntax the same - as is specified by IMAP2 in RFC 1064. A server may not behave in any - other manner unless the SELECT.VERSION or SELECT.FEATURES commands - are used to select different behavior. - - Over time, when groups of generally useful changes to the current, - default behavior of the server are found, these will be collected - together and incorporated in such a way that all of the features can - be selected simply by selecting a particular major version number of - the protocol. It should be noted that the version numbers (both - major and minor) selected by the SELECT.VERSION command denote - versions of the IMAP protocol, not versions of the server per se. - Thus, although in general changes to the protocol specification will - be made in such a way that they are upwards compatible, this cannot - be guaranteed. No client should rely on tests of the form "if - major_version > 2 then..." being valid for all protocol versions, - since incompatible changes might be made in the future. - - The client reads mailbox information by means of FETCH commands. The - actual data is transmitted via the solicited data mechanism (that is, - FETCH should be viewed as poking the server to include the desired - data along with any other data it wishes to transmit to the client). - There are three major categories of data which may be fetched. - - - -Rice [Page 10] - -RFC 1203 IMAP3 February 1991 - - - The first category is that data which is associated with a message as - an entity in the mailbox. There are presently three such items of - data: the "internal date", the "RFC 822 size", and the "flags". The - internal date is the date and time that the message was placed in the - mailbox. The RFC 822 size is subject to deletion in the future; it - is the size in bytes of the message, expressed as an RFC 822 text - string. Current clients only use it as part of a status display - line. The flags are a list of status flags associated with the - message (see below). All of the first category data can be fetched - by using the macro-fetch word "FAST"; that is, "FAST" expands to - "(FLAGS INTERNALDATE RFC822.SIZE)". - - The second category is that data which describes the composition and - delivery information of a message; that is, information such as the - message sender, recipient lists, message-ID, subject, etc. This is - the information which is stored in the message header in RFC 822 - format message and is traditionally called the "envelope". [Note: - this should not be confused with the SMTP (RFC 821) envelope, which - is strictly limited to delivery information.] IMAP3 defines a - structured and unambiguous representation for the envelope which is - particularly nice for Lisp-based parsers. A client can use the - envelope for operations such as replying and not worry about RFC 822 - at all. Envelopes are discussed in more detail below. The first and - second category data can be fetched together by using the macro-fetch - word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE - RFC822.SIZE ENVELOPE)". - - The third category is that data which is intended for direct human - viewing. The present RFC 822 based IMAP3 defines three such items: - RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two - former appended together in a single text string). Fetching "RFC822" - is equivalent to typing the RFC 822 representation of the message as - stored on the mailbox without any filtering or processing. - - Typically, a client will "FETCH ALL" for some or all of the messages - in the mailbox for use as a presentation menu, and when the user - wishes to read a particular message will "FETCH RFC822.TEXT" to get - the message body. A more primitive client could, of course, simply - "FETCH RFC822" a la POP2-type functionality. - - The client can alter certain data by means of a STORE command. As an - example, a message is deleted from a mailbox by a STORE command which - includes the \DELETED flag as one of the flags being set. - - Other client operations include copying a message to another mailbox - (COPY command), permanently removing deleted messages (EXPUNGE - command), checking for new messages (CHECK command), and searching - for messages which match certain criteria (SEARCH command). - - - -Rice [Page 11] - -RFC 1203 IMAP3 February 1991 - - - The client terminates the session with the LOGOUT command. The - server returns a "BYE" followed by an "OK". - -A Typical Scenario - - Client Server - ------ ------ - {Wait for Connection} - {Open Connection} --> - <-- * OK IMAP3 Server Ready - {Wait for command} - A001 SUPPORTED.VERSIONS --> - <-- * SUPPORTED.VERSIONS ((2 0 ) - (3 0 EIGHT.BIT.TRANSPARENT - AUTO.SET.SEEN - TAGGED.SOLICITED)) - A001 OK Supported Versions returned. - {Wait for command} - A002 SELECT.VERSION (3 0) --> - <-- A002 OK Version 3.0 Selected. - {Wait for command} - A002 SELECT.FEATURES TAGGED.SOLICITED --> - <-- A002 OK Features selected. - {Wait for command} - A003 LOGIN Fred Secret --> - <-- A003 OK User Fred logged in - {Wait for command} - A004 SELECT INBOX --> - <-- A004 FLAGS (Meeting Notice \Answered - \Flagged \Deleted \Seen) - <-- A004 19 EXISTS - <-- A004 2 RECENT - <-- A004 OK Select complete - {Wait for command} - A005 FETCH 1:19 ALL --> - <-- A005 1 Fetch (......) - ... - <-- A005 18 Fetch (......) - <-- A005 19 Fetch (......) - <-- A005 OK Fetch complete - {Wait for command} - A006 FETCH 8 RFC822.TEXT --> - <-- A006 8 Fetch (RFC822.TEXT {893} - ...893 characters of text... - <-- ) - <-- A006 OK Fetch complete - {Wait for command} - - - - -Rice [Page 12] - -RFC 1203 IMAP3 February 1991 - - - A007 STORE 8 +Flags \Deleted --> - <-- A007 8 Store (Flags (\Deleted - \Seen)) - <-- A007 OK Store complete - {Wait for command} - A008 EXPUNGE --> - <-- A008 19 EXISTS - <-- A008 8 EXPUNGE - <-- A008 18 EXISTS - <-- A008 Expunge complete - {Wait for command} - A009 LOGOUT --> - <-- A009 BYE IMAP3 server quitting - <-- A009 OK Logout complete - {Close Connection} --><-- {Close connection} - {Go back to start} - - A more complex scenario produced by a pipelining multiprocess client. - - Client Server - ------ ------ - {Wait for Connection} - {Open session as above} - <-- A004 19 EXISTS - <-- A004 2 RECENT - <-- A004 OK Select complete - {Wait for command} - A005 SEARCH RECENT --> - <-- A005 SEARCH (18 19) (RECENT) - <---A005 OK Search complete - A006 FETCH 18:19 ALL RFC822.TEXT - A007 STORE 18:19 +FLAGS (\SEEN) - A008 FETCH 1:17 ALL --> - <-- A006 18 Fetch (... RFC822.TEXT ...) - A009 STORE 18 +FLAGS (\DELETED) - <-- A006 19 Fetch (... RFC822.TEXT ...) - <-- A006 OK Fetch complete - <-- A007 18 STORE (Flags (\Seen)) - A010 STORE 19 +FLAGS (\DELETED) - <-- A007 19 STORE (Flags (\Seen)) - <-- A007 OK Store complete - <-- A008 1 Fetch (......) - ... - <-- A008 16 Fetch (......) - <-- A008 17 Fetch (......) - <-- A008 OK Fetch complete - <-- A009 18 STORE (Flags (\Seen - \Deleted)) - - - -Rice [Page 13] - -RFC 1203 IMAP3 February 1991 - - - <-- A009 OK Store complete - <-- A010 19 STORE (Flags (\Seen - \Deleted)) - <-- A010 OK Store complete - {Wait for command} - <-- * EXISTS 23 - <-- * RECENT 4 - <-- * SEARCH (20 21 22 23) (RECENT) - A011 FETCH 20:23 ALL RFC822.TEXT - -Conventions - - The following terms are used in a meta-sense in the syntax - specification below: - - An ASCII-STRING is a sequence of arbitrary ASCII characters. - - An ATOM is a sequence of ASCII characters delimited by SP or CRLF. - - A CHARACTER is any ASCII character except """", "{", CR, LF, "%", - or "\". - - A CRLF is an ASCII carriage-return character followed immediately - by an ASCII linefeed character. - - A NUMBER is a sequence of the ASCII characters which represent - decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or - ":". - - A SP is the ASCII space character. - - A TEXT_LINE is a human-readable sequence of ASCII characters up to - but not including a terminating CRLF. - - One of the most common fields in the IMAP3 protocol is a STRING, - which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside - double-quotes), or a LITERAL. A literal consists of an open brace - ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII- - STRING of n characters, where n is the value of the number inside the - brace. In general, a string should be represented as an ATOM or - QUOTED-STRING if at all possible. The semantics for QUOTED-STRING or - LITERAL are checked before those for ATOM; therefore an ATOM used in - a STRING may only contain CHARACTERs. Literals are most often sent - from the server to the client; in the rare case of a client to server - literal there is a special consideration (see the "+ text" response - below). - - Another important field is the SEQUENCE, which identifies a set of - - - -Rice [Page 14] - -RFC 1203 IMAP3 February 1991 - - - messages by consecutive numbers from 1 to n where n is the number of - messages in the mailbox. A sequence may consist of a single number, - a pair of numbers delimited by colon indicating all numbers between - those two numbers, or a list of single numbers and/or number pairs. - For example, the sequence 2,4:7,9,12:15 is equivalent to - 2,4,5,6,7,9,12,13,14,15 and identifies all of those messages. - -Definitions of Commands and Responses - - Summary of Commands and Responses - -Commands: - tag NOOP - tag LOGIN user password - tag LOGOUT - tag SELECT mailbox - tag CHECK - tag EXPUNGE - tag COPY sequence mailbox - tag FETCH sequence data - tag STORE sequence data value - tag SEARCH criteria - tag BBOARD bboard - tag FIND (BBOARDS / MAILBOXES) pattern - tag READONLY - tag READWRITE - tag SELECT.VERSION (major_version minor_version) - tag SELECT.FEATURES features - tag SUPPORTED.VERSIONS - tag FLAGS - tag SET.FLAGS - -Responses (can be either solicited or unsolicited): - */tag FLAGS flag_list - */tag SEARCH (numbers) (criteria) - */tag EXISTS - */tag RECENT - */tag EXPUNGE - */tag STORE data - */tag FETCH data - */tag BBOARD bboard_name - */tag MAILBOX non_inbox_mailbox_name - */tag SUPPORTED.VERSIONS version_data - */tag READONLY - */tag READWRITE - */tag OK text - */tag NO text - */tag BAD text - - - -Rice [Page 15] - -RFC 1203 IMAP3 February 1991 - - - */tag BYE text - -Responses (can only be solicited): - tag COPY message_number - -Responses (can only be unsolicited): - + text - -Commands - - tag NOOP - - The NOOP command returns an OK to the client. By itself, it does - nothing, but certain things may happen as side effects. For - example, server implementations which implicitly check the mailbox - for new mail may do so as a result of this command. The primary - use of this command is to for the client to see if the server is - still alive (and notify the server that the client is still alive, - for those servers which have inactivity autologout timers). - - tag LOGIN user password - - The LOGIN command identifies the user to the server and carries - the password authenticating this user. This information is used - by the server to control access to the mailboxes. - - EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with - password SESAME. - - tag LOGOUT - - The LOGOUT command indicates the client is done with the session. - The server sends a solicited BYE response before the (tagged) OK - response, and then closes the connection. - - tag SELECT mailbox - - The SELECT command selects a particular mailbox. The server must - check that the user is permitted read access to this mailbox. - Prior to returning an OK to the client, the server must send an - solicited FLAGS and <n> EXISTS response to the client giving the - flags list for this mailbox (simply the system flags if this - mailbox doesn't have any special flags) and the number of messages - in the mailbox. It is also recommended that the server send a <n> - RECENT unsolicited response to the client for the benefit of - clients which make use of the number of new messages in a mailbox. - It is further recommended that servers should send an unsolicited - READONLY message if the mailbox that has been selected is not - - - -Rice [Page 16] - -RFC 1203 IMAP3 February 1991 - - - writable by the user. - - Multiple SELECT commands are permitted in a session, in which case - the prior mailbox is deselected first. - - The default mailbox for the SELECT command is INBOX, which is a - special name reserved to mean "the primary mailbox for this user - on this server". The format of other mailbox names is operating - system dependent (as of this writing, it reflects the path of the - mailbox on the current servers), though it could reflect any - server-specific naming convention for the namespace of mailboxes. - Such a namespace need not and should not be viewed as being - equivalent or linked to the server machine's file system. - - EXAMPLES: A002 SELECT INBOX ;; selects the default mailbox. - A002 197 EXISTS ;; server says 197 messages in INBOX - A002 5 RECENT ;; server says 5 are recent. - A002 OK Select complete. - or - A003 SELECT /usr/fred/my-mail.txt - ;; select a different user specified mailbox. - ... - - tag CHECK - - The CHECK command forces a check for new messages and a rescan of - the mailbox for internal change for those implementations which - allow multiple simultaneous read/write access to the same mailbox - (e.g., TOPS-20). It is recommend that periodic implicit checks - for new mail be done by servers as well. The server must send a - solicited <n> EXISTS response prior to returning an OK to the - client. - - tag EXPUNGE - - The EXPUNGE command permanently removes all messages with the - \DELETED flag set in its flags from the mailbox. Prior to - returning an OK to the client, for each message which is removed, - a solicited <n> EXPUNGE response is sent indicating which message - was removed. The message number of each subsequent message in the - mailbox is immediately decremented by 1; this means that if the - last 5 messages in a 9-message mailbox are expunged you will - receive 5 "5 EXPUNGE" responses for message 5. To ensure mailbox - integrity and server/client synchronization, it is recommended - that the server do an implicit check prior to commencing the - expunge and again when the expunge is completed. Furthermore, if - the server allows multiple simultaneous access to the same mailbox - the server must guarantee both the integrity of the mailbox and - - - -Rice [Page 17] - -RFC 1203 IMAP3 February 1991 - - - the views of it held by the clients. - - EXPUNGE is not allowed if the user does not have write access to - this mailbox. If a user does not have write access to the mailbox - then the server is required to signal this fact by replying with a - NO response with a suitable text string that can be presented to - the user explaining that the mailbox is read-only. It is further - recommended that servers send an unsolicited READONLY message to - clients that attempt an expunge operation on a read only mailbox. - - tag COPY sequence mailbox - - The COPY command copies the specified message(s) to the specified - destination mailbox. If the destination mailbox does not exist, - the server should create it. Prior to returning an OK to the - client, the server must return a solicited <n> COPY response for - each message copied. - - EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4 to - mailbox "MEETING". - - COPY is not allowed if the user does not have write access to the - destination mailbox. If a user does not have write access to the - destination mailbox then the server is required to signal this - fact by replying with a NO response with a suitable text string - that can be presented to the user explaining that the mailbox is - read-only. It is further recommended that servers send an - unsolicited READONLY message to clients that attempt to copy to a - read only mailbox. IMAP3 does not specify "where" the message - will be put in the mailbox to which it has been copied. - - tag FETCH sequence fetch_att - - The FETCH command retrieves data associated with a message in the - mailbox. The data items to be fetched may be either a single atom - or an S-expression list. The attributes that can be fetched are - any of those mentioned specifically below along with any generic, - canonical or concrete key. The set of predefined generic keys is: - {BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}. The set - of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}. The - value returned by the server for a non-existent or non-meaningful - key is defined to be the null value, NIL. - - ALL Equivalent to: - (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) - - ENVELOPE The envelope of the message. The envelope is - computed by the server by parsing the header, - - - -Rice [Page 18] - -RFC 1203 IMAP3 February 1991 - - - i.e., the RFC 822 header for an RFC822 format - message, into the component parts, defaulting - various fields as necessary. - - FAST Macro equivalent to: - (FLAGS INTERNALDATE RFC822.SIZE) - - FLAGS The flags which are set for this message. - This may include the following system flags: - - \RECENT Message arrived since - last read of this mailbox - \SEEN Message has been read - \ANSWERED Message has been answered - \FLAGGED Message is "flagged" for - urgent/special attention - \DELETED Message is "deleted" for - removal by later EXPUNGE - - INTERNALDATE The date and time the message was written to - the mailbox. - - RFC822 The message in RFC 822 format. - - RFC822.HEADER The RFC 822 format header of the message. - - RFC822.SIZE The number of characters in the message as - expressed in RFC 822 format. - - RFC822.TEXT The text body of the message, omitting the - RFC 822 header. - - EXAMPLES: - - A003 FETCH 2:4 ALL - fetches the flags, internal date, RFC 822 size, and envelope - for messages 2, 3, and 4. - - A004 FETCH 3 RFC822 - fetches the RFC 822 representation for message 3. - - A005 FETCH 4 (FLAGS RFC822.HEADER) - fetches the flags and RFC 822 format header for message 4. - - A006 FETCH 42 $SUBJECT - A006 FETCH $SUBJECT "Some subject text..." - A006 OK FETCH completed ok. - fetches the canonical subject field. - - - -Rice [Page 19] - -RFC 1203 IMAP3 February 1991 - - - A007 FETCH 42 APPARENTLY-TO - A007 FETCH APPARENTLY-TO NIL - A007 OK FETCH found no value. - fetches the concrete apparently-to field. - - tag STORE sequence data value - - The STORE command alters the values associated with particular - keys for a message in the mailbox. As is the case for the FETCH - command, any generic, canonical or concrete key may be used to - index the value provided. In addition to these, the following - pre-defined keys are provided. - - FLAGS Replace the flags for the message with the - argument (in flag list format). - The server must respond with a solicited STORE FLAGS - message, showing the new state of the flags after - the store. - - +FLAGS Add the flags in the argument to the - message's flag list. - The server must respond with a solicited STORE FLAGS - message, showing the new state of the flags after - the store. - - -FLAGS Remove the flags in the argument from the - message's flag list. - The server must respond with a solicited STORE FLAGS - message, showing the new state of the flags after - the store. - - RFC822.HEADER Replace the header of the message(s) with that - specified. This allows users to use their mailboxes - as databases with header fields as keys. - The server must respond with solicited - STORE RFC822.HEADER, STORE RFC822.SIZE and - STORE ENVELOPE messages, showing the new state - of the reparsed header after the store. - - RFC822.TEXT Replace the body of the messages with that specified. - The server must respond with solicited - STORE RFC822.TEXT and STORE RFC822.SIZE messages, - showing the new state of the message after the store. - - STORE is not allowed if the user does not have write access to - this mailbox. - - The server is required to send a solicited STORE response for - - - -Rice [Page 20] - -RFC 1203 IMAP3 February 1991 - - - each store operation that results in a format transformation by - the server. For example, the server is required to send a - STORE FLAGS response when the client performs a STORE +FLAGS or - a STORE -FLAGS, since the client may not easily be able to know - what the result of this command will be. Similarly, if the - client emits a STORE FROM command then the server should - respond with a suitable STORE FROM response because the client - would be sending a string value to be stored and the server - should transform this into a set of addresses. In general, - however, although it is legal for the server to send a - solicited STORE response for each STORE operation, this is - discouraged, since it might result in the retransmission of - very large and unnecessary amounts of data that have been - stored. - - EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3, - and 4 for deletion. - - tag SEARCH search_criteria - - The SEARCH command searches the mailbox for messages which match - the given set of criteria. The server response SEARCH (criteria) - (numbers) gives the set of messages which match the conjunction of - the criteria specified. In addition to each of the search - criteria there is its logical inverse. The logical inverse - criterion is denoted by the ~ (tilda) sign. - - Thus, no message that matches the criterion: - FROM crispin - - will match the criterion: - ~FROM crispin - - The criteria for the search can be any generic, canonical or - concrete key. In addition to these, the following pre-defined - keys are also provided: - - ALL All messages in the mailbox; the default - initial criterion for ANDing. - - ANSWERED Messages with the \ANSWERED flag set. - - BCC string Messages which contain the specified string - in the envelope's BCC field. - - BEFORE date Messages whose internal date is earlier than - the specified date. - - - - -Rice [Page 21] - -RFC 1203 IMAP3 February 1991 - - - BODY string Messages which contain the specified string - in the body of the message. - - CC string Messages which contain the specified string - in the envelope's CC field. - - DELETED Messages with the \DELETED flag set. - - FLAGGED Messages with the \FLAGGED flag set. - - FROM string Messages which contain the specified string - in the envelope's FROM field. - - HEADER string Messages which contain the specified string - in the message header. - - KEYWORD flag Messages with the specified flag set. - - NEW Messages which have the \RECENT flag set but - not the \SEEN flag. This is functionally - equivalent to "RECENT UNSEEN". - - OLD Messages which do not have the \RECENT flag - set. - - ON date Messages whose internal date is the same as - the specified date. - - RECENT Messages which have the \RECENT flag set. - - SEEN Messages which have the \SEEN flag set. - - SINCE date Messages whose internal date is later than - the specified date. - - SUBJECT string Messages which contain the specified string - in the envelope's SUBJECT field. - - TEXT string Messages which contain the specified string. - - TO string Messages which contain the specified string in - the envelope's TO field. - - EXAMPLE: A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 - returns the message numbers for all deleted messages from Smith - that were placed in the mailbox since October 1, 1987. - - Implementation note: The UNANSWERED, UNDELETED, UNFLAGGED, - - - -Rice [Page 22] - -RFC 1203 IMAP3 February 1991 - - - UNKEYWORD and UNSEEN criteria, described below, are preserved in - IMAP3 for IMAP2 compatibility. They are, however, considered - obsolete and new Client programs are encouraged to use the ~ - notation for the logical inverses of search criteria with a view - to the dropping of this outmoded syntax in later versions. - - UNANSWERED Messages which do not have the \ANSWERED flag - set. - - UNDELETED Messages which do not have the \DELETED flag - set. - - UNFLAGGED Messages which do not have the \FLAGGED flag - set. - - UNKEYWORD flag Messages which do not have the specified flag - set. - - UNSEEN Messages which do not have the \SEEN flag set. - - tag READONLY - - The READONLY command indicates that the client wishes to make the - mailbox read-only. The server is required to reply with a - solicited READONLY or READWRITE response. - - tag READWRITE - - The READWRITE command indicates that the client wishes to make the - mailbox read-write. The server is required to reply with a - solicited READONLY or READWRITE response. - - tag SUPPORTED.VERSIONS - - The SUPPORTED.VERSIONS solicits from the server a - SUPPORTED.VERSIONS message, which encapsulates information about - which versions and features the server supports. - - tag SELECT.VERSION (major_version minor_version) - - The SELECT.VERSION command indicates that the client wishes to - select certain behavior on the part of the server. The major and - minor versions indicate the specific version of the protocol being - selected. - - EXAMPLE: A002 SELECT.VERSION (3 0) - - A client may not request a server version that is not supported by - - - -Rice [Page 23] - -RFC 1203 IMAP3 February 1991 - - - the server, i.e., which is specifically mentioned in the response - to a SUPPORTED.VERSIONS command. An attempt to do so by a client - will result in a NO response from the server. It is an error for - the SELECT.VERSION command to be used after a mailbox has been - selected. The rationale for this is that for some server - implementations it might be necessary to spawn separate programs - to implement widely divergent protocol versions. Thus, the client - cannot be allowed to expect any server state to be preserved after - the use of the SELECT.VERSION command. The default version of all - servers is 2.0, i.e., IMAP2 as defined by RFC 1064. - - tag SELECT.FEATURES 1#features - - The SELECT.FEATURES command indicates that the client wishes to - select certain specific features on the part of the server. A - client may not request a feature that is not supported by the - server, i.e., one that is explicitly mentioned in the set of - features for the selected version returned by the - SUPPORTED.VERSIONS command. An attempt to do so by a client will - result in a NO response from the server. - - EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED - EIGHT.BIT.TRANSPARENT - - i.e., select the set of features called AUTO.SET.SEEN and - EIGHT.BIT.TRANSPARENT and deselect the feature called - TAGGED.SOLICITED. The use of the SELECT.FEATURES command - completely resets the set of selected features. Note: These are - only example feature names and are not necessarily supported by - any server. See the appendix on features for more information on - features. Note: Some features, when present in the server, will - cause the upwards compatible extension of the grammar, i.e., by - adding extra commands. The server is at liberty not to remove - these upwards compatible extensions to the command tables when a - feature is disabled. Thus, it is an error for a client to rely on - getting a NO or BAD response in any way, for instance to determine - the selectedness or presence of a feature. - - tag BBOARD bboard - - The BBOARD command is equivalent to SELECT, except that its - argument is a bulletin board (BBoard) name. The format of a - BBoard name is implementation specific, although it is strongly - encouraged to use something that resembles a name in a generic - sense and not a file or mailbox name on the particular system. - There is no requirement that a BBoard name be a mailbox name or a - file name (in particular, Unix netnews has a completely different - namespace from mailbox or file names). - - - -Rice [Page 24] - -RFC 1203 IMAP3 February 1991 - - - The result from the BBOARD command is identical from that of the - SELECT command. For example, in the TOPS-20 server - implementation, the command - A0002 BBOARD FOO - is exactly equivalent to the command - A0002 SELECT POBOX:<BBOARD>FOO.TXT - Note: the equivalence in this example is *not* required by the - protocol, and merely reflects the fuzzy distinction between - mailboxes and BBoards on TOPS-20. - - tag FIND (BBOARDS / MAILBOXES) pattern - - The FIND command accepts as arguments the keywords BBOARDS or - MAILBOXES and a pattern which specifies some set of BBoard/mailbox - names which are usable by the BBOARD/SELECT command. Two wildcard - characters are defined; "*" specifies that any number (including - zero) characters may match at this position and "%" specifies that - a single character may match at this position. For example, - FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas - FOO%BAR will match only FOO.BAR; furthermore, "*" will match all - BBoards/mailboxes. The following quoting convention applies to - wildcards: "\*" is the literal "*" character, "\%" is the literal - "%" character and "\\" is the literal "\" character. Notes: The - format of mailboxes is server implementation dependent. The - special mailbox name INBOX is not included in the output to the - FIND MAILBOXES command. - - The FIND command solicits any number of BBOARD or MAILBOX - responses from the server as appropriate. - - Examples: - A0002 FIND BBOARDS * - A0002 BBOARD FOOBAR - A0002 BBOARD GENERAL - A0002 OK FIND completed - or - A0002 FIND MAILBOXES FOO%BA* - A0002 MAILBOX FOO.BAR - A0002 MAILBOX FOO.BAZZAR - A0002 OK FIND completed - - Note: Although the use of explicit file or path names for - mailboxes is discouraged by this standard, it may be unavoidable. - It is important that the value returned in the MAILBOX solicited - reply be usable in the SELECT command without remembering any path - specification which may have been used in the FIND MAILBOXES - pattern. - - - - -Rice [Page 25] - -RFC 1203 IMAP3 February 1991 - - - tag FLAGS - - The FLAGS command solicits a FLAGS response from the server. - - tag SET.FLAGS flag_list - - The SET.FLAGS command defines the user specifiable flags for this - mailbox, i.e., the keywords. If this set does not include flags - formerly sent to the client by the server in a FLAGS message then - this constitutes a request to delete the flag. Any new flags - should be created. This command does not affect the system - defined flags and any system flags that are included in the - flag_list will be ignored. The server must respond to this - command with a solicited FLAGS message. If the deletion of a flag - results in the invalidation of the flag sets of any messages then - the server is required to send solicited STORE FLAGS messages to - the client for each modified message. - -Responses: - - */tag OK text - - In its solicited form this response identifies successful - completion of the command with the indicated tag. The text is a - line of human-readable text which may be useful in a protocol - telemetry log for debugging purposes. - - In its unsolicited form, this response indicates simply that the - server is alive. No special action on the part of the client is - called for. This is presently only used by servers at startup as - a greeting message indicating that they are ready to accept the - first command. This usage, although legal, is by no means - required. The text is a line of human-readable text which may be - logged in protocol telemetry. - - */tag NO text - - In its solicited form this response identifies unsuccessful - completion of the command with the indicated tag. The text is a - line of human-readable text which probably should be displayed to - the user in an error report by the client. - - In its unsolicited form this response indicates some operational - error at the server which cannot be traced to any protocol - command. The text is a line of human-readable text which should - be logged in protocol telemetry for the maintainer of the server - and/or the client. - - - - -Rice [Page 26] - -RFC 1203 IMAP3 February 1991 - - - */tag BAD text - - In its solicited form response indicates faulty protocol received - from the client and indicates a bug. The text is a line of - human-readable text which should be recorded in any telemetry as - part of a bug report to the maintainer of the client. - - In its unsolicited form response indicates some protocol error at - the server which cannot be traced to any protocol command. The - text is a line of human-readable text which should be logged in - protocol telemetry for the maintainer of the server and/or the - client. This generally indicates a protocol synchronization - problem, and examination of the protocol telemetry is advised to - determine the cause of the problem. - - */tag BYE text - - This indicates that the server is about to close the connection. - The text is a line of human-readable text which should be - displayed to the user in a status report by the client. IMAP2 - requires that the server emit a solicited BYE response as part of - a normal logout sequence. This solicited form is not required - under IMAP3, though is still legal for compatibility. In its - unsolicited form the BYE response is used as a panic shutdown - announcement by the server. It is required to be used by any - server which performs autologouts due to inactivity. - - */tag number message_data - - The solicited (tag number message_data) response is generated as - the result of a number of client requests. The server may also - emit any the following at any time as unsolicited data (i.e., * - number message_data). The message_data is one of the following: - - EXISTS The specified number of messages exists in the mailbox. - - RECENT The specified number of messages have arrived since the - last time this mailbox was selected with the SELECT - command or equivalent. - - EXPUNGE The specified message number has been permanently - removed from the mailbox, and the next message in the - mailbox (if any) becomes that message number. - The server must send a solicited EXPUNGE response - for each message that it expunges as the result - of an EXPUNGE command. Note: future versions of the - protocol may allow the use of a message sequence - as a value returned by the EXPUNGE response to allow the - - - -Rice [Page 27] - -RFC 1203 IMAP3 February 1991 - - - more efficient compaction of client representations of - mailboxes. - - STORE data - Functionally equivalent to FETCH, only it is sent by the - server when the state of a mailbox changes. The server - must send solicited STORE responses as the result of - any change caused by a STORE command. - - FETCH data - This is the principle means by which data about a - message is sent to the client. The data is in a - Lisp-like S-expression property list form. Just as the - FETCH request from the client can fetch any generic, - canonical or concrete key, so also the FETCH response - can return values for any of these keys as well as for - the pre-defined attributes mentioned below. Note that - the server is permitted to send any unsolicited FETCH - or STORE messages that it should choose, be they the - values associated with generic, canonical or concrete - keys. Clients are required to ignore any such - FETCH responses that it cannot interpret. For example, - clients are not required to be able to understand, i.e., - use fruitfully, the canonical $TO key, but they are - required to be able to ignore an unsolicited $TO message - correctly. - - ENVELOPE An S-expression format list which describes the - envelope of a message. The envelope is computed - by the server by parsing the RFC 822 header into - the component parts, defaulting various fields - as necessary. - - The fields of the envelope are in the following - order: date, subject, from, sender, reply-to, to, - cc, bcc, in-reply-to, and message-id. The date, - subject, in-reply-to, and message-id fields are - strings. The from, sender, reply-to, to, cc, - and bcc fields are lists of addresses. - - An address is an S-expression format list which - describes an electronic mail address. The fields - of an address are in the following order: - personal name, source-route (i.e., the - at-domain-list in SMTP), mailbox name, host name - and comments. Implementation note: The addition - of the comment field is an incompatible extension - from IMAP2. The server is required not to provide - - - -Rice [Page 28] - -RFC 1203 IMAP3 February 1991 - - - this field when running in IMAP2 mode. - - Any field of an envelope or address which is - not applicable is presented as the atom NIL. - Note that the server must default the reply-to - and sender fields from the from field; a client is - not expected to know to do this. - - FLAGS An S-expression format list of flags which are set - for this message. This may include the following - system flags: - - \RECENT Message arrived since last - read of this mailbox - \SEEN Message has been read - \ANSWERED Message has been answered - \FLAGGED Message is "flagged" for - urgent/special attention - \DELETED Message is "deleted" for - removal by later EXPUNGE - - INTERNALDATE A string containing the date and time the - message was written to the mailbox. - - RFC822 A string expressing the message in RFC 822 - format. - Note: Some implementations of IMAP2 servers - had the (undocumented) behavior of setting - the \SEEN flag as a side effect of fetching - the body of a message. This resulted in - erroneous behavior for clients that prefetch - messages that the user might not get - around to reading. Thus, this behavior is - explicitly disallowed in IMAP3. - Note: this is not a significant performance - restriction because it is always possible for - IMAP3 clients to use an interaction with the - server of the following type: - A001 FETCH 42 RFC822 - A002 STORE 42 +FLAGS (\SEEN) - A001 42 FETCH RFC822 {637} ...... - A001 OK Fetch completed - A002 42 STORE FLAGS (\SEEN \FLAGGED...) - A002 OK Store Completed. - - RFC822.HEADER A string expressing the RFC 822 format - header of the message - - - - -Rice [Page 29] - -RFC 1203 IMAP3 February 1991 - - - RFC822.SIZE A number indicating the number of - characters in the message as expressed - in RFC 822 format. - - RFC822.TEXT A string expressing the text body of the - message, omitting the RFC 822 header. - See also note for RFC822. - - */tag FLAGS flag_list - - A solicited FLAGS response must occur as a result of a SELECT - command. The flag list is the list of flags (at a minimum, the - IMAP defined flags) which are applicable for this mailbox. Flags - other than the system flags are a function of the server - implementation. - - */tag SEARCH (numbers) (search_criteria) - - This response occurs as a result of a SEARCH command. The - number(s) refer to those messages which match the search criteria. - In its solicited form this message allows clients to find - interesting groups of messages, e.g., unseen messages from - Crispin. In its unsolicited form it allows the server to inform - the client of interesting patterns, e.g., when new mail arrives, - recent and from Crispin. Compatibility note: The search_criteria - are sent by the server along with the matching numbers so - unsolicited SEARCH messages may be interpreted. This syntax is - not upwards compatible with IMAP2 and so the new syntax is - intended to make it simple for clients that are not able to take - advantage of unsolicited SEARCH messages still to interpret - solicited SEARCH messages simply by ignoring everything that - follows the list of numbers with minimal parsing. Such clients - may not, however, simply discard the rest of the line because - there might be LITERALs in the search pattern. - - Examples: - A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN) - and - * SEARCH (42) (FROM Crispin RECENT) - - */tag READONLY - - This indicates that the mailbox is read-only. The server is - required to respond to a READONLY or READWRITE command with either - a solicited READONLY or a solicited READWRITE response. Note: If - the client attempts a mutation operation, such as STORE, on a - mailbox to which it does not have write access then the server is - required to reply with a solicited READONLY response on the first - - - -Rice [Page 30] - -RFC 1203 IMAP3 February 1991 - - - such attempted mutation. The server may also choose to send - solicited READONLY responses for each subsequent attempted - mutation. - - */tag READWRITE - - This indicates that the mailbox is read-write. The server is - required to respond to a READONLY or READWRITE command with either - a solicited READONLY or a solicited READWRITE response. - - */tag BBOARD bboard_name - - This message is produced in its solicited form as a response to a - FIND BBOARDS command. In its unsolicited form it represents a - notification by the server that a new BBoard has been added. - Bboard_name must be a name that can be supplied to the BBOARD - command so as to select the appropriate bboard. - - */tag MAILBOX non_inbox_mailbox_name - - This message is produced in its solicited form as a response to a - FIND MAILBOXES command. In its unsolicited form it represents a - notification by the server that a new mailbox has been added, - perhaps as the result of a COPY command creating a new mailbox. - Non_inbox_mailbox_name must be a name that can be supplied to the - SELECT command so as to select the appropriate mailbox. Note: - non_inbox_mailbox_name is never the string "INBOX". - - */tag SUPPORTED.VERSIONS (version_specs) - - This message is used either as a response to the - SUPPORTED.VERSIONS or, in its unsolicited form, to indicate the - dynamic addition or removal of support for features or protocol - versions. Each version_spec is of the form (4 2 - EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN ...), i.e., a major version - number and a minor version number for the protocol and the set of - features supported under the server's implementation of that - protocol version. A server may not dynamically remove support for - any version or feature that has been selected by any currently - logged in client by the use of the VERSION command. - - Example: - A00005 SUPPORTED.VERSIONS ((2 0 ) - (2 2 TAGGED.SOLICITED) - (3 0 EIGHT.BIT.TRANSPARENT TAGGED.SOLICITED)) - - Indicates that two major versions are supported and one minor - version is supported and that tagged solicited messages are - - - -Rice [Page 31] - -RFC 1203 IMAP3 February 1991 - - - supported in versions 2.2 and 3.0 with eight bit characters being - supported under version 3. For each feature mentioned in the list - of features there is also always the negation of that feature. - For example, if the server supports the TAGGED.SOLICITED feature - then it also supports the ~TAGGED.SOLICITED feature, which - disables this feature. Note: These are only example feature - names and are not necessarily supported by any server. See the - appendix on features for more information on features. - - + text - - This response indicates that the server is ready to accept the - text of a literal from the client. Normally, a command from the - client is a single text line. If the server detects an error in - the command, it can simply discard the remainder of the line. It - cannot do this in the case of commands which contain literals, - since a literal can be an arbitrarily long amount of text, and the - server may not even be expecting a literal. This mechanism is - provided so the client knows not to send a literal until the - server definitely expects it, preserving client/server - synchronization. - - In actual practice, this situation is rarely encountered. In the - current protocol, the only client commands likely to contain - literals are the LOGIN command and the STORE RFC822.HEADER or - STORE RFC822.TEXT commands. Consider a situation in which a - server validates the user before checking the password. If the - password contains "funny" characters and hence is sent as a - literal, then if the user is invalid an error would occur before - the password is parsed. - - No such synchronization protection is provided for literals sent - from the server to the client, for performance reasons. Any - synchronization problems in this direction would be due to a bug - in the client or server and not for some operational problem. - -Sample IMAP3 session - - The following is a transcript of an actual IMAP3 session. Server - output is identified by "S:" and client output by "U:". In cases - where lines were too long to fit within the boundaries of this - document, the line was continued on the next line preceded by a tab. - - S: * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol - III Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT - U: a001 SUPPORTED.VERSIONS - S: * SUPPORTED.VERSIONS ((2 0 ) (3 0 EIGHT.BIT.TRANSPARENT - AUTO.SET.SEEN TAGGED.SOLICITED)) - - - -Rice [Page 32] - -RFC 1203 IMAP3 February 1991 - - - S: A001 Supported Versions returned. - U: a002 SELECT.VERSION (3 0) - S: a002 OK Version 3.0 Selected. - U: a003 SELECT.FEATURES TAGGED.SOLICITED - S: a003 OK Features selected. - U: a004 login crispin secret - S: a004 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT, - job 76 - U: a005 select inbox - S: a005 FLAGS (Bugs SF Party Skating Meeting Flames Request AI - Question Note \XXXX \YYYY \Answered \Flagged \Deleted - \Seen) - S: a005 16 EXISTS - S: a005 0 RECENT - S: a006 OK Select complete - U: a006 fetch 16 all - S: a006 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55: - RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT" - "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN" - "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN" - "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN" - "SUMEX-AIM.Stanford.EDU" NIL)) ((NIL NIL "rindflEISCH" - "SUMEX-AIM.Stanford.EDU" NIL)) NIL NIL NIL - "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) - S: a006 OK Fetch completed - U: a007 fetch 16 rfc822 - S: a007 16 Fetch (RFC822 {637} - S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43 - S: Mail-From: FAGAN created at 4-Jun-88 13:27:12 - S: Date: Sat, 4 Jun 88 13:27:11 PDT - S: From: Larry Fagan <FAGAN@SUMEX-AIM.Stanford.EDU> - S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU - S: Subject: INFO-MAC Mail Message - S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> - S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT - S: ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU> - S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, - Crispin@SUMEX-AIM.Stanford.EDU - S: ReSent-Message-ID: - <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> - S: - S: The file is <info-mac>usenetv4-55.arc ... - S: Larry - S: ------- - S: ) - S: a007 OK Fetch completed - U: a008 logout - S: a008 BYE UNIX IMAP III server terminating connection - - - -Rice [Page 33] - -RFC 1203 IMAP3 February 1991 - - - S: a008 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol - Service logout - -Implementation Discussion - - As of this writing, SUMEX has completed an IMAP2 client for Xerox - Lisp machines written in hybrid Interlisp/CommonLisp and is beginning - distribution of a client for TI Explorer Lisp machines. SUMEX has - also completed a portable IMAP2 client protocol library module - written in C. This library, with the addition of a small main - program (primarily user interface) and a TCP/IP driver, became a - rudimentary remote system mail-reading program under Unix. The first - production use of this library is as a part of a MacII client which - has now been under daily use (by real users) at Stanford for quite - some time. - - As of this writing, SUMEX has completed IMAP2 servers for TOPS-20 - written in DEC-20 assembly language and 4.2/3 BSD Unix written in C. - The TOPS-20 server is fully compatible with MM-20, the standard - TOPS-20 mailsystem, and requires no special action or setup on the - part of the user. The INBOX under TOPS-20 is the user's MAIL.TXT. - The TOPS-20 server also supports multiple simultaneous access to the - same mailbox, including simultaneous access between the IMAP3 server - and MM-20. The 4.2/3 BSD Unix server requires that the user use - either Unix Mail format or mail.txt format which is compatible with - SRI MM-32 or Columbia MM-C. The 4.2/3 BSD Unix server allows - simultaneous read access; write access must be exclusive. There is - also an experimental IMAP3 server running on the TI Explorer class of - machine, which uses MM mailbox format and which can communicate over - both TCP and Chaos. - - The Xerox Lisp client and DEC-20 server have been in production use - for over two years; the Unix server was been in production use for - over a year. IMAP3 has been used to access mailboxes at remote sites - from a local workstation via the Internet. For example, from the - Stanford local network one of the authors has read his mailbox at a - Milnet site. - - A number of IMAP clients have now been developed or are being - developed. Amongst these are versions that run on the following - machines: - - . Xerox Lisp machines - . Apple Macintosh - . NeXT - . IBM PC - . TI Explorer Lisp machines - . "Glass teletype" version that runs under Unix - - - -Rice [Page 34] - -RFC 1203 IMAP3 February 1991 - - - . GNU Emacs - . X Windows - . NTT ELIS - - Each of these client programs is carefully tuned to optimize the - performance and user interface in a manner that is consistent with - the the user interface model of the native machine. For example, the - Macintosh client features a "messy-desk" interface that allows the - cutting and pasting of text with the use of the clipboard with a menu - driven interface with keyboard accelerators. - - This specification does not make any formal definition of size - restrictions, but some of the existing servers have the following - limitations: - - DEC-20 - . length of a mailbox: 7,077,888 characters - . maximum number of messages: 18,432 messages - . length of a command line: 10,000 characters - . length of the local host name: 64 characters - . length of a "short" argument: 39 characters - . length of a "long" argument: 491,520 characters - . maximum amount of data output in a single fetch: - 655,360 characters - - TI-Explorer - . length of a mailbox: limited by the Minimum of the size of the - virtual address space and the size of the file system - . maximum number of messages: limited by the the size of the - virtual address space - . length of a command line: limited by the the size of the - virtual address space - . length of the local host name: limited by the the size of the - virtual address space - . length of a "short" argument: limited by the the size of the - virtual address space - . length of a "long" argument: limited by the the size of the - virtual address space - . maximum amount of data output in a single fetch: not limited - - Typical values for these limits are 30Mb for file systems and 128Mb - for virtual address space. - - To date, nobody has run up against any of these limitations, many of - which are substantially larger than most current user mail reading - programs. - - There are several advantages to the scheme of tags and solicited - - - -Rice [Page 35] - -RFC 1203 IMAP3 February 1991 - - - responses and unsolicited data. First, the infamous synchronization - problems of SMTP and similar protocols do not happen with tagged - commands; a command is not considered satisfied until a completion - acknowledgement with the same tag is seen. Tagging allows an - arbitrary amount of other responses ("solicited" data) to be sent by - the server with no possibility of the client losing synchronization. - Compare this with the problems that FTP or SMTP clients have with - continuation, partial completion, and commentary reply codes. - - Another advantage is that a non-lockstep client implementation is - possible. The client could send a command, and entrust the handling - of the server responses to a different process which would signal the - client when the tagged response comes in. Some clients might be - implemented in a thoroughly asynchronous manner, having, perhaps, - multiple outstanding commands at any given time. Note: this does - not require that the server process these commands in anything other - than a lock-step manner. It simply allows clients to take advantage - of servers that are able to do such asynchronous operations. - - It was observed that synchronization problems can occur with literals - if the literal is not recognized as such. Fortunately, the cases in - which this can happen are relatively rare; a mechanism (the special - "+" tag response) was introduced to handle those few cases which - could happen. The proper way to address this problem in all cases is - probably to move towards a record-oriented architecture instead of - the text stream model provided by TCP. - - Unsolicited data needs some discussion. Unlike most protocols, in - which the server merely does the client's bidding, an IMAP3 server - has a semi-autonomous role. By means of sending "unsolicited data", - the server is in effect sending a command to the client -- to update - and/or extend its (incomplete) model of the mailbox with new - information from the server. In this viewpoint, although a "fetch" - command is a request for specific information from the client, the - server is always at liberty to include more than the desired data as - "unsolicited". A server acknowledgement to the "fetch" is a - statement that at least all the requested data has been sent. - - In terms of implementation, a simple lock-step client may have a - local cache of data from the mailbox. This cache is incomplete in - general, and at select time is empty. A listener on the IMAP - connection in the client processes all solicited and unsolicited data - symmetrically, and updates the cache based on this data, i.e., the - client faults on a cache miss and asks the server to fill that cache - slot synchronously. If a tagged completion response arrives, the - listener unblocks the process which sent the tagged request. - - Clearly, given this model it is not strictly necessary to distinguish - - - -Rice [Page 36] - -RFC 1203 IMAP3 February 1991 - - - most solicited from unsolicited data. Doing so, however, apart from - being clearer, also allows such simplistic, lock-step client - implementations that extract the specific value of the response to - command by trapping the tagged response. This allows the client not - to have to block on some complex predicate that involves watching to - see an update in a cache cell. - - For example, perhaps as a result of opening a mailbox, solicited data - from the server arrives. The first piece of data is the number of - messages. This is used to size the cache; note that, if new mail - arrives, by sending a new "number of messages" unsolicited data - message server will cause the cache to be re-sized. If the client - attempts to access information from the cache, it will encounter - empty spots which will trigger "fetch" requests. The request would - be sent, some solicited data including the answer to the fetch will - flow back, and then the "fetch" response will unblock the client. - - People familiar with demand-paged virtual memory design will - recognize this model as being very similar to page-fault handling on - a demand-paged system. - -Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in RFC 822 with one exception; the - delimiter used with the "#" construct is a single space (SP) and not - a comma. - -address ::= "(" addr_name SP addr_adl SP addr_mailbox SP - addr_host addr_comment ")" - -addr_adl ::= nil / string - -addr_comment ::= nil / string - -addr_host ::= nil / string - -addr_mailbox ::= nil / string - -addr_name ::= nil / string - -bboard ::= "BBOARD" SP bboard_name - -bboard_name ::= string - -bboard_notify ::= "BBOARD" sp bboard_name - -canonical_key ::= "$CC" / "$FROM" / "$SUBJECT" / "$TO" - - - -Rice [Page 37] - -RFC 1203 IMAP3 February 1991 - - -check ::= "CHECK" - -concrete_key ::= string - -copy ::= "COPY" SP sequence SP mailbox - -criterion ::= "ALL" / "ANSWERED" / - "BCC" SP string / "BEFORE" SP string / - "BODY" SP string / "CC" SP string / "DELETED" / - "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / - "ON" SP string / "RECENT" / "SEEN" / - "SINCE" SP string / "TEXT" SP string / - "TO" SP string / "UNANSWERED" / "UNDELETED" / - "UNFLAGGED" / "UNKEYWORD" / "UNSEEN" / key SP string - -criteria ::= 1#criterion - -data ::= ("FLAGS" SP flag_list / - search_notify / bboard_notify / mailbox_notify / - supported_versions_notify / "READONLY" / "READWRITE" / - "BYE" SP text_line / "OK" SP text_line / - "NO" SP text_line / "BAD" SP text_line) - -date ::= string in form "dd-mmm-yy hh:mm:ss-zzz" - -envelope ::= "(" env_date SP env_subject SP env_from SP - env_sender SP env_reply-to SP env_to SP - env_cc SP env_bcc SP env_in-reply-to SP - env_message-id ")" - -env_bcc ::= nil / "(" 1*address ")" - -env_cc ::= nil / "(" 1*address ")" - -env_date ::= string - -env_from ::= nil / "(" 1*address ")" - -env_in-reply-to ::= nil / string - -env_length ::= NUMBER - -env_message-id ::= nil / string - -env_reply-to ::= nil / "(" 1*address ")" - -env_sender ::= nil / "(" 1*address ")" - - - - -Rice [Page 38] - -RFC 1203 IMAP3 February 1991 - - -env_subject ::= nil / string - -env_to ::= nil / "(" 1*address ")" - -expunge ::= "EXPUNGE" - -feature ::= ATOM - -fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" / - fetch_att / "(" 1#fetch_att ")") - -fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / - "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / - "RFC822.TEXT" / key - -find ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern - -flag_list ::= ATOM / "(" 1#ATOM ")" - -flags ::= "FLAGS" - -generic_key ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" / - "SUBJECT" / "TEXT" / "TO" - -key ::= generic_key / canonical_key / concrete_key - -literal ::= "{" NUMBER "}" CRLF ASCII-STRING - -login ::= "LOGIN" SP userid SP password - -logout ::= "LOGOUT" - -mailbox ::= "INBOX" / string - -mailbox_notify ::= MAILBOX non_inbox_mailbox_name - -msg_copy ::= "COPY" - -msg_data ::= (msg_exists / msg_recent / msg_expunge / - msg_fetch / msg_copy) - -msg_exists ::= "EXISTS" - -msg_expunge ::= "EXPUNGE" - -msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP - env_length envelope / "FLAGS" SP "(" 1#(recent_flag - flag_list) ")" / "INTERNALDATE" SP date / - - - -Rice [Page 39] - -RFC 1203 IMAP3 February 1991 - - - "RFC822" SP string / "RFC822.HEADER" SP string / - "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP - string / key SP string_list) ")" - -msg_recent ::= "RECENT" - -msg_num ::= NUMBER - -nil ::= "NIL" - -non_inbox_mailbox_name ::= string - -noop ::= "NOOP" - -numbers ::= 1#NUMBER - -password ::= string - -pattern ::= string - -recent_flag ::= "\RECENT" - -read_only ::= "READONLY" - -read_write ::= "READWRITE" - -ready ::= "+" SP text_line - -request ::= tag SP (noop / login / logout / select / check / - expunge / copy / fetch / store / search / - select_version / select_features / - supported_versions / bboard / find / - read_only / read_write / flags / set_flags ) CRLF - -response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF - -search ::= "SEARCH" SP criteria - -search_notify ::= "SEARCH" SP (numbers) SP (criteria) - -select ::= "SELECT" SP mailbox - -select_features ::= "SELECT.FEATURES" 1#feature - -select_version ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")" - -sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" - sequence) - - - -Rice [Page 40] - -RFC 1203 IMAP3 February 1991 - - -set_flags ::= "SET.FLAGS" SP flag_list - -solicited ::= tag SP (msg_num SP msg_data / data / - solicited_only) CRLF - -solicited_only ::= {None currently defined} - -store ::= "STORE" SP sequence SP store_att - -store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / - "FLAGS" SP flag_list / RFC822.TEXT SP string - / RFC822.HEADER SP string / key SP string) - -string ::= atom / """" 1*character """" / literal - -string_list ::= string / ("(" 1#string ")") - -supported_versions ::= "SUPPORTED.VERSIONS" - -supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec - ")" - -system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP - "\SEEN" - -tag ::= atom - -unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF - -userid ::= string - -version_spec ::= "(" NUMBER SP NUMBER SP 1#feature ")" - -Appendix: Features. - - In this section we outline the standard features that are supported - by all IMAP3 servers and identify those features which are - recommended or experimental. For each of these features the default - setting is specified. This means that it is required of any server - that supports a given feature to make the default enabledness of that - feature as is specified below. It is required that for each feature - supported by a server the inverse feature should also be supported. - The inverse feature name shall always be defined as the feature name - preceded by the "~" character. Thus, the AUTO.SET.SEEN feature is - disabled by the ~AUTO.SET.SEEN feature. - - - - - - -Rice [Page 41] - -RFC 1203 IMAP3 February 1991 - - - Required Features: - - AUTO.SET.SEEN - When this features is enabled (default is disabled), - the \\SEEN flag is set for all appropriate messages as a side - effect of any of the following: - FETCH of RFC822 - FETCH of RFC822.TEXT - COPY - Justification: This feature is provided for the use of clients - that are unable to pipeline their commands effectively and - communicate over high latency connections. When disabled, - the server will not perform any such side effects. This feature - is also provided so as to smooth the transition from IMAP2 to - IMAP3. - - - TAGGED.SOLICITED - When this feature is enabled (default is enabled - for IMAP3, disabled for IMAP2 mode), solicited responses from - the server will have the tag specified by the client. - When this feature is disabled, solicited responses from the - server will have the IMAP2 compatible tag "*", not the - tag specified by the client. - Justification: This feature is provided so as to smooth the - transition from IMAP2 to IMAP3. - - Recommended Features. - - EIGHT.BIT.TRANSPARENT - When this feature is enabled - (default is disabled), the server allows the transparent - transmission of eight bit characters. When this feature is - disabled, the value of any bit other than the least significant - 7 bits transmitted by the server is unspecified. If this - feature is enabled, the characters that compose all command - keywords specified in the IMAP3 grammar and all feature names - use only their 7 least significant bits. - Justification: This feature is provided for the purpose of - supporting national character sets within messages, encoded - languages such as Japanese Kanji characters and also of binary - data, such as programs, graphics and sound. - - - NEW.MAIL.NOTIFY - When this feature is enabled (default is - disabled for compatibility with the majority of existing - IMAP2 servers), the server will notify the client of the - arrival of new mail in the currently selected mailbox - using the appropriate RECENT and EXISTS unsolicited messages - without the client needing to send periodic CHECK commands. - Justification: This feature is provided to allow clients to - - - -Rice [Page 42] - -RFC 1203 IMAP3 February 1991 - - - switch off any periodic polling strategy that they may use - to look for new mail. Such polling unnecessarily uses bandwidth - and can cause the interactive performance to degrade because - the user can be kept waiting while some background process - is doing a CHECK. - - - SEND - When this feature is enabled (default is disabled) a new - "SEND" command becomes available to the client. The SEND - command instructs the server to send a message, rather - than requiring the client to use its own, local message - sending capability, for example. An example of of the - send command might be as follows: - tag42 SEND RFC822 {2083} - From: James Rice <Rice@Sumex-Aim.Stanford.Edu> - To:..... - If the server is unable to parse the message being sent then - it is required to issue a suitable NO notification to the client. - If the message cannot be delivered for some reason then the - server should send a suitable message to the FROM: address - of the message detailing the delivery failure. - When the SEND feature is enabled, the "send" production in - the grammar is added and as defined below. The "send" - request is added to the list of requests in the request - production also as shown below: - - message_format ::= RFC822 - - request ::= tag SP (noop / login / logout / select / check / - expunge / copy / fetch / store / search / - select_version / select_features / - supported_versions / bboard / find / - read_only / read_write / flags / - set_flags / send) CRLF - - send ::= SEND SP message_format SP string - - Justification: This feature is provided so that mail can be - sent by the same reliable server that is used for the storage - of mail. This has, amongst others, the following benefits: - - Single process clients need not be delayed by mail - transmission. - - Mail sent by the client will have the server named as the - message's sender. This can be important because there are - a lot of mailers that erroneously cause reply mail to be - sent to the Sender, not the From or Reply-To address. Since - the client in general is not listening for mail being sent - to it directly this can cause mail to be lost. - - - -Rice [Page 43] - -RFC 1203 IMAP3 February 1991 - - - - Clients can be written that do not have any native message - sending capability. - - - ADD.MESSAGE - When this feature is enabled (default is disabled) - a new "ADD.MESSAGE" command becomes available to the client. - The ADD.MESSAGE command instructs the server to add the - specified message to the designated mailbox. This command - can be thought of as being like a COPY command except in - this case the message that is put in the designated mailbox - is specified as a string, rather than as a message number to - be copied from the currently selected mailbox. An example - use of this command might be as follows: - tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083} - From: James Rice <Rice@Sumex-Aim.Stanford.Edu> - To:..... - This will have the effect of adding the message to the mailbox - called OUTGOING-MAIL. - If the server is unable to parse the message being added then - it is required to issue a suitable NO notification to the client. - When the ADD.MESSAGE feature is enabled, the "add_message" - production in the grammar is added and as defined below. - The "add_message" request is added to the list of requests - in the request production also as shown below: - - add_message ::= ADD.MESSAGE SP mailbox SP format SP string - - message_format ::= RFC822 - - request ::= tag SP (noop / login / logout / select / check / - expunge / copy / fetch / store / search / - select_version / select_features / - supported_versions / bboard / find / - read_only / read_write / flags / set_flags / - add_message) CRLF - - Justification: This feature is provided so that clients can - easily add mail to specific mailboxes. This allows clients - to implement such behavior as outgoing mail storage (BCC) - without the need to resort to mailing to special BCC mailboxes. - - - RENUMBER - When this feature is enabled (default is disabled) - the RENUMBER command becomes available to the client. - The RENUMBER command will reorder the assignment of message - numbers to the messages in the mailbox. If this results in a - change to the association of any message number with any - message then the server is required to send solicited RESET - - - -Rice [Page 44] - -RFC 1203 IMAP3 February 1991 - - - responses to the client. The intent of this command is - to allow users to view mailboxes in user-meaningful order - efficiently. While the client could do the ordering, - it would be less efficient in general. Note that the - server may or may not change the actual storage of the - messages and the ordering may or may not remain in effect - after another mailbox is selected or the IMAP session is - terminated. Informally, the syntax for the RENUMBER - command is: - - tag RENUMBER field_name ordering_type - - this has the effect of changing the IMAP grammar to be - as follows: - - ordering_type ::= DATE / NUMERIC / ALPHA - - renumber ::= RENUMBER SP field_name SP ordering_type - - request ::= tag SP (noop / login / logout / select / check / - expunge / copy / fetch / store / search / - select_version / select_features / - supported_versions / bboard / find / - read_only / read_write / flags / set_flags / - renumber) CRLF - - For example: - tag42 RENUMBER FROM ALPHA - ;;;RENUMBER alphabetically by the from field - tag42 RESET 10:20,49 - ;;;Messages 10 to 20 and 49 have changed - tag42 OK RENUMBER finished. Sequence has changed - tag43 FETCH ALL 10:20,49 - ;;;Client chooses to fetch the changed msgs. - - To support this the RESET message is defined as follows: - - */tag RESET message_sequence - This solicited of unsolicited message from the server informs the - client that it should flush any information that it has - retained for the specified messages. - - Justification: This feature is provided so that clients can - view mailboxes in an order that is convenient to the user. - This is particularly important in the context of mailboxes - that the user copies messages to from other mailboxes. This - user-controlled filing process often does not happen in any - well-defined order. Because messages in a mailbox are - - - -Rice [Page 45] - -RFC 1203 IMAP3 February 1991 - - - implicitly ordered (usually by arrival date, though this is - not a required ordering predicate), the user can be confused - by the apparent order of messages in the mailbox. The - addition of the RENUMBER command makes it unnecessary - for the user to leave IMAP and use some other mail system to - sort mailboxes. - - - ENCODING - When this feature is enabled (default is disabled) a new - generic key named ENCODING is defined. The value associated - with the generic ENCODING key is a list of (tag encoding-type - options...) lists that represent the ordered, possibly encoded - body of the message. Each such list represents a segment of - the body of the message and the way in which it is encoded. - Any options that follow the encoding_type are further - qualifiers that describe the format of the segment. Each tag - is created by the server and is unique with respect to the - other tags allocated for the other elements in the ENCODING - list. The client may use the tags returned by the server as - concrete keys to access a field which is encoded using the - encoding type and options mentioned in the appropriate list. - Thus: - - tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196. - tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded. - tag41 OK Fetch completed. - tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197. - tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies. - tag42 OK Fetch completed. - tag43 FETCH 197 G002 ; Client asks for field named G002 - tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field. - tag43 OK Fetch completed. - - or - - tag44 STORE 197 G002 "0A 00 FF 31 24......." - ; Store back the segment with nibbles swapped - - Note: As a side-effect of enabling this feature, the generic key - TEXT will be redefined so as to return only those body parts of a - message that are of type TEXT. The concrete key RFC822.TEXT, on - the other hand, would still return everything in the body of the - message, even if it was full of strange, binary character - sequences. - - When the client STOREs to a field denoted by one of the above tags - the server will interpret the value being passed as being in the - same format as is currently specified in the ENCODING field. The - - - -Rice [Page 46] - -RFC 1203 IMAP3 February 1991 - - - server is not required to be able to reformat the data associated - with the ENCODING tags if the client STOREs a new value for the - ENCODING field. The interpretability of a message in the context - of its ENCODING field is undefined if the client side-effects that - ENCODING field, unless the client also STOREs new, reformatted - values for the fields that have had their encoding changed. - - If the client stores a new value for the ENCODING field then the - tags in the new value will be used to index the parts of the body. - All tags in a client-STOREd ENCODING that are the same as those - originally generated by the server in response to a FETCH ENCODING - command are said still to denote the fields that they originally - denoted, though possibly reordered. Any tags not originally - defined by the server will denote new message parts, in the - appropriate format, in the relative position specified. The - exclusion of any tags that the server originally defined in a - FETCH of the ENCODING field will indicate the deletion of that - part of the message. Newly created message parts are undefined by - default, so if the client fails to follow the STOREing of the - ENCODING field with suitable STORE commands for the values - associated with any newly created tags, these fields will contain - the null value NIL. - - Justification: This feature is supplied so as to allow support - for emergent multi-part and multi-media mail standards. - - INDEXABLE.FIELDS - When this feature is enabled (default is - disabled) the grammar of fetch commands is changed to allow the - client to select a specific subsequence from the field in - question. For example: - - tag42 FETCH 197 BODY 2000:3999 - - would fetch the second two thousand bytes of the body of message - 197. This feature allows resource limited clients to access - small parts of large messages. The formal syntax for this is: - - fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / - fetch_key / (fetch_key SP NUMBER ":" NUMBER) - - fetch_key ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / - "RFC822.TEXT" / key - - If the lower bound number (the number to the left of the colon) - exceeds the maximum size of the field then the empty string is - returned. If the upper bound exceeds the maximum size of the - field but the lower bound does not then the server will return the - remaining substring of the field after the lower bound. The - - - -Rice [Page 47] - -RFC 1203 IMAP3 February 1991 - - - bounds specified are zero indexed into the fields and the bounds - index fields by 8-bit bytes. - - Justification: This feature is provided so as to allow resource- - limited clients to read very large messages and also to allow - clients to improve interactive response for the reading of large - messages by fetching the first "screen full" of data to display - immediately and fetching the rest of the message in the - background. - - SET.EOL - When enabled (default is disabled), this feature - allows the new command SET.EOL to be available, changing the - grammar as follows: - - character ::= "CR" / "LF" / number - - request ::= tag SP (noop / login / logout / select / check / - expunge / copy / fetch / store / search / - select_version / select_features / - supported_versions / bboard / find / - read_only / read_write / flags / set_flags / - set_eol) CRLF - - set_eol ::= "SET.EOL" 1#character - - This has the effect of changing the end of line character sequence - generated by the server for newlines within strings to the - sequence of characters specified. The characters in the sequence - can be either the specified symbolically named characters or a - numerical value, specifying the decimal value of the character to - use. Thus, if the client would like newlines in strings to be - indicated by a carriage return followed by a control-d, the client - would issue the following command: - - tag42 SET.EOL CR 4 - - If the server is unable to support the combination of characters - requested by the client as its end-of-line pattern it will reply - with a NO response. This might be the case, for example, if a - server is only able to generate its own native line feed pattern - and the CRLF required by IMAP by default. - - The server is required to change any length denoting values, such - as envelope byte counts for all future transactions to reflect the - new eol setting. This change in reported sizes should apply to - all generic size fetching keys, but not to concrete ones such as - RFC822.SIZE, which by their very nature require a size measurement - in RFC822 format, i.e., with CRLF as the end-of-line convention. - - - -Rice [Page 48] - -RFC 1203 IMAP3 February 1991 - - - Justification: This feature is provided because frequently clients - and servers might have end-of-line conventions other than the CRLF - specified by RFC822. It is undesirable that the IMAP be linked - too closely to RFC822 and selecting a different convention might - allow substantial performance improvements in both clients and - servers by saving either client, server or both from having to - shuffle text around so as to add or remove non-local end-of-line - sequences. - -Acknowledgements: - - This text is based on RFC 1064 by Mark Crispin. - - The following have made major contributions to this proposed update - to the IMAP2 protocol: - - James Rice <Rice@sumex-aim.stanford.edu> - Richard Acuff <acuff@sumex-aim.stanford.edu> - Bill Yeager <yeager@sumex-aim.stanford.edu> - Christopher Lane <lane@sumex-aim.stanford.edu> - Bjorn Victor <Bjorn.Victor@docs.uu.se> - - Additional input was also received from: - - Andrew Sweer <sweer@sumex-aim.stanford.edu> - Tom Gruber <Gruber@sumex-aim.stanford.edu> - Kevin Brock <Brock@Sumex-Aim.Stanford.Edu> - Mark Crispin <MRC@cac.washington.edu> - -Security Considerations - - Security issues are not discussed in this memo. - -Author's Address - - James Rice - Stanford University - Knowledge Systems Laboratory - 701 Welch Road - Building C - Palo Alto, CA 94304 - - Phone: (415) 723-8405 - EMail: RICE@SUMEX-AIM.STANFORD.EDU - - - - - - - -Rice [Page 49] -
\ No newline at end of file diff --git a/RFC/rfc1225.txt b/RFC/rfc1225.txt deleted file mode 100644 index 8d7e0029..00000000 --- a/RFC/rfc1225.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group M. Rose -Request for Comments: 1225 Performance Systems International -Obsoletes: RFC 1081 May 1991 - - - Post Office Protocol - Version 3 - -Status of this Memo - - This memo suggests a simple method for workstations to dynamically - access mail from a mailbox server. This RFC specifies an IAB - standards track protocol for the Internet community, and requests - discussion and suggestions for improvements. Please refer to the - current edition of the "IAB Official Protocol Standards" for the - standardization state and status of this protocol. Distribution of - this memo is unlimited. - -Overview - - This memo is a republication of RFC 1081 which was based on RFC 918 - (since revised as RFC 937). Although similar in form to the original - Post Office Protocol (POP) proposed for the Internet community, the - protocol discussed in this memo is similar in spirit to the ideas - investigated by the MZnet project at the University of California, - Irvine. - - Further, substantial work was done on examining POP in a PC-based - environment. This work, which resulted in additional functionality - in this protocol, was performed by the ACIS Networking Systems Group - at Stanford University. The author gratefully acknowledges their - interest. - -Introduction - - On certain types of smaller nodes in the Internet it is often - impractical to maintain a message transport system (MTS). For - example, a workstation may not have sufficient resources (cycles, - disk space) in order to permit a SMTP server and associated local - mail delivery system to be kept resident and continuously running. - Similarly, it may be expensive (or impossible) to keep a personal - computer interconnected to an IP-style network for long amounts of - time (the node is lacking the resource known as "connectivity"). - - Despite this, it is often very useful to be able to manage mail on - these smaller nodes, and they often support a user agent (UA) to aid - the tasks of mail handling. To solve this problem, a node which can - support an MTS entity offers a maildrop service to these less endowed - nodes. The Post Office Protocol - Version 3 (POP3) is intended to - - - -Rose [Page 1] - -RFC 1225 POP3 May 1991 - - - permit a workstation to dynamically access a maildrop on a server - host in a useful fashion. Usually, this means that the POP3 is used - to allow a workstation to retrieve mail that the server is holding - for it. - - For the remainder of this memo, the term "client host" refers to a - host making use of the POP3 service, while the term "server host" - refers to a host which offers the POP3 service. - -A Short Digression - - This memo does not specify how a client host enters mail into the - transport system, although a method consistent with the philosophy of - this memo is presented here: - - When the user agent on a client host wishes to enter a message - into the transport system, it establishes an SMTP connection to - its relay host (this relay host could be, but need not be, the - POP3 server host for the client host). - - If this method is followed, then the client host appears to the MTS - as a user agent, and should NOT be regarded as a "trusted" MTS entity - in any sense whatsoever. This concept, along with the role of the - POP3 as a part of a split-UA model is discussed later in this memo. - - Initially, the server host starts the POP3 service by listening on - TCP port 110. When a client host wishes to make use of the service, - it establishes a TCP connection with the server host. When the - connection is established, the POP3 server sends a greeting. The - client and POP3 server then exchange commands and responses - (respectively) until the connection is closed or aborted. - - Commands in the POP3 consist of a keyword possibly followed by an - argument. All commands are terminated by a CRLF pair. - - Responses in the POP3 consist of a success indicator and a keyword - possibly followed by additional information. All responses are - terminated by a CRLF pair. There are currently two success - indicators: positive ("+OK") and negative ("-ERR"). - - Responses to certain commands are multi-line. In these cases, which - are clearly indicated below, after sending the first line of the - response and a CRLF, any additional lines are sent, each terminated - by a CRLF pair. When all lines of the response have been sent, a - final line is sent, consisting of a termination octet (decimal code - 046, ".") and a CRLF pair. If any line of the multi-line response - begins with the termination octet, the line is "byte-stuffed" by - pre-pending the termination octet to that line of the response. - - - -Rose [Page 2] - -RFC 1225 POP3 May 1991 - - - Hence a multi-line response is terminated with the five octets - "CRLF.CRLF". When examining a multi-line response, the client checks - to see if the line begins with the termination octet. If so and if - octets other than CRLF follow, the the first octet of the line (the - termination octet) is stripped away. If so and if CRLF immediately - follows the termination character, then the response from the POP - server is ended and the line containing ".CRLF" is not considered - part of the multi-line response. - - A POP3 session progresses through a number of states during its - lifetime. Once the TCP connection has been opened and the POP3 - server has sent the greeting, the session enters the AUTHORIZATION - state. In this state, the client must identify itself to the POP3 - server. Once the client has successfully done this, the server - acquires resources associated with the client's maildrop, and the - session enters the TRANSACTION state. In this state, the client - requests actions on the part of the POP3 server. When the client has - finished its transactions, the session enters the UPDATE state. In - this state, the POP3 server releases any resources acquired during - the TRANSACTION state and says goodbye. The TCP connection is then - closed. - -The AUTHORIZATION State - - Once the TCP connection has been opened by a POP3 client, the POP3 - server issues a one line greeting. This can be any string terminated - by CRLF. An example might be: - - S. +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) - - Note that this greeting is a POP3 reply. The POP3 server should - always give a positive response as the greeting. - - The POP3 session is now in the AUTHORIZATION state. The client must - now issue the USER command. If the POP3 server responds with a - positive success indicator ("+OK"), then the client may issue either - the PASS command to complete the authorization, or the QUIT command - to terminate the POP3 session. If the POP3 server responds with a - negative success indicator ("-ERR") to the USER command, then the - client may either issue a new USER command or may issue the QUIT - command. - - When the client issues the PASS command, the POP3 server uses the - argument pair from the USER and PASS commands to determine if the - client should be given access to the appropriate maildrop. If so, - the POP3 server then acquires an exclusive-access lock on the - maildrop. If the lock is successfully acquired, the POP3 server - parses the maildrop into individual messages (read note below), - - - -Rose [Page 3] - -RFC 1225 POP3 May 1991 - - - determines the last message (if any) present in the maildrop that was - referenced by the RETR command, and responds with a positive success - indicator. The POP3 session now enters the TRANSACTION state. If - the lock can not be acquired or the client should is denied access to - the appropriate maildrop or the maildrop can't be parsed for some - reason, the POP3 server responds with a negative success indicator. - (If a lock was acquired but the POP3 server intends to respond with a - negative success indicator, the POP3 server must release the lock - prior to rejecting the command.) At this point, the client may - either issue a new USER command and start again, or the client may - issue the QUIT command. - - NOTE: Minimal implementations of the POP3 need only be - able to break a maildrop into its component messages; - they need NOT be able to parse individual messages. - More advanced implementations may wish to have this - capability, for reasons discussed later. - - After the POP3 server has parsed the maildrop into individual - messages, it assigns a message-id to each message, and notes the size - of the message in octets. The first message in the maildrop is - assigned a message-id of "1", the second is assigned "2", and so on, - so that the n'th message in a maildrop is assigned a message-id of - "n". In POP3 commands and responses, all message-id's and message - sizes are expressed in base-10 (i.e., decimal). - - It sets the "highest number accessed" to be that of the last message - referenced by the RETR command. - - Here are summaries for the three POP3 commands discussed thus far: - - USER name - Arguments: a server specific user-id (required) - Restrictions: may only be given in the AUTHORIZATION - state after the POP3 greeting or after an - unsuccessful USER or PASS command - Possible Responses: - +OK name is welcome here - -ERR never heard of name - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - ... - C: USER frated - S: -ERR sorry, frated doesn't get his mail here - - PASS string - Arguments: a server/user-id specific password (required) - - - -Rose [Page 4] - -RFC 1225 POP3 May 1991 - - - Restrictions: may only be given in the AUTHORIZATION - state after a successful USER command - Possible Responses: - +OK maildrop locked and ready - -ERR invalid password - -ERR unable to lock maildrop - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: +OK mrose's maildrop has 2 messages - (320 octets) - ... - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: -ERR unable to lock mrose's maildrop, file - already locked - - QUIT - Arguments: none - Restrictions: none - Possible Responses: - +OK - Examples: - C: QUIT - S: +OK dewey POP3 server signing off - - -The TRANSACTION State - - Once the client has successfully identified itself to the POP3 server - and the POP3 server has locked and burst the appropriate maildrop, - the POP3 session is now in the TRANSACTION state. The client may now - issue any of the following POP3 commands repeatedly. After each - command, the POP3 server issues a response. Eventually, the client - issues the QUIT command and the POP3 session enters the UPDATE state. - - Here are the POP3 commands valid in the TRANSACTION state: - - STAT - Arguments: none - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - The POP3 server issues a positive response with a line - containing information for the maildrop. This line is - called a "drop listing" for that maildrop. - - - -Rose [Page 5] - -RFC 1225 POP3 May 1991 - - - In order to simplify parsing, all POP3 servers are - required to use a certain format for drop listings. - The first octets present must indicate the number of - messages in the maildrop. Following this is the size - of the maildrop in octets. This memo makes no - requirement on what follows the maildrop size. - Minimal implementations should just end that line of - the response with a CRLF pair. More advanced - implementations may include other information. - - NOTE: This memo STRONGLY discourages - implementations from supplying additional - information in the drop listing. Other, - optional, facilities are discussed later on - which permit the client to parse the messages - in the maildrop. - - Note that messages marked as deleted are not counted in - either total. - - Possible Responses: - +OK nn mm - Examples: - C: STAT - S: +OK 2 320 - - LIST [msg] - Arguments: a message-id (optionally) If a message-id is - given, it may NOT refer to a message marked as - deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If an argument was given and the POP3 server issues a - positive response with a line containing information - for that message. This line is called a "scan listing" - for that message. - - If no argument was given and the POP3 server issues a - positive response, then the response given is - multi-line. After the initial +OK, for each message - in the maildrop, the POP3 server responds with a line - containing information for that message. This line - is called a "scan listing" for that message. - - In order to simplify parsing, all POP3 servers are - required to use a certain format for scan listings. - The first octets present must be the message-id of - - - -Rose [Page 6] - -RFC 1225 POP3 May 1991 - - - the message. Following the message-id is the size of - the message in octets. This memo makes no requirement - on what follows the message size in the scan listing. - Minimal implementations should just end that line of - the response with a CRLF pair. More advanced - implementations may include other information, as - parsed from the message. - - NOTE: This memo STRONGLY discourages - implementations from supplying additional - information in the scan listing. Other, optional, - facilities are discussed later on which permit - the client to parse the messages in the maildrop. - - Note that messages marked as deleted are not listed. - - Possible Responses: - +OK scan listing follows - -ERR no such message - Examples: - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - ... - C: LIST 2 - S: +OK 2 200 - ... - C: LIST 3 - S: -ERR no such message, only 2 messages in - maildrop - - RETR msg - Arguments: a message-id (required) This message-id may - NOT refer to a message marked as deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If the POP3 server issues a positive response, then the - response given is multi-line. After the initial +OK, - the POP3 server sends the message corresponding to the - given message-id, being careful to byte-stuff the - termination character (as with all multi-line - responses). - - If the number associated with this message is higher - than the "highest number accessed" in the maildrop, the - - - -Rose [Page 7] - -RFC 1225 POP3 May 1991 - - - POP3 server updates the "highest number accessed" to - the number associated with this message. - - Possible Responses: - +OK message follows - -ERR no such message - Examples: - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends the entire message here> - S: . - - DELE msg - Arguments: a message-id (required) This message-id - may NOT refer to a message marked as deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - The POP3 server marks the message as deleted. Any - future reference to the message-id associated with the - message in a POP3 command generates an error. The POP3 - server does not actually delete the message until the - POP3 session enters the UPDATE state. - - If the number associated with this message is higher - than the "highest number accessed" in the maildrop, - the POP3 server updates the "highest number accessed" - to the number associated with this message. - - Possible Responses: - +OK message deleted - -ERR no such message - Examples: - C: DELE 1 - S: +OK message 1 deleted - ... - C: DELE 2 - S: -ERR message 2 already deleted - - NOOP - Arguments: none - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - The POP3 server does nothing, it merely replies with a - positive response. - - Possible Responses: - - - -Rose [Page 8] - -RFC 1225 POP3 May 1991 - - - +OK - Examples: - C: NOOP - S: +OK - - LAST - Arguments: none - Restrictions: may only be issued in the TRANSACTION state. - Discussion: - - The POP3 server issues a positive response with a line - containing the highest message number which accessed. - Zero is returned in case no message in the maildrop has - been accessed during previous transactions. A client - may thereafter infer that messages, if any, numbered - greater than the response to the LAST command are - messages not yet accessed by the client. - - Possible Response: - +OK nn - - Examples: - C: STAT - S: +OK 4 320 - C: LAST - S: +OK 1 - C: RETR 3 - S: +OK 120 octets - S: <the POP3 server sends the entire message - here> - S: . - C: LAST - S: +OK 3 - C: DELE 2 - S: +OK message 2 deleted - C: LAST - S: +OK 3 - C: RSET - S: +OK - C: LAST - S: +OK 1 - - RSET - Arguments: none - Restrictions: may only be given in the TRANSACTION - state. - Discussion: - - - - -Rose [Page 9] - -RFC 1225 POP3 May 1991 - - - If any messages have been marked as deleted by the POP3 - server, they are unmarked. The POP3 server then - replies with a positive response. In addition, the - "highest number accessed" is also reset to the value - determined at the beginning of the POP3 session. - - Possible Responses: - +OK - Examples: - C: RSET - S: +OK maildrop has 2 messages (320 octets) - - - -The UPDATE State - - When the client issues the QUIT command from the TRANSACTION state, - the POP3 session enters the UPDATE state. (Note that if the client - issues the QUIT command from the AUTHORIZATION state, the POP3 - session terminates but does NOT enter the UPDATE state.) - - QUIT - Arguments: none - Restrictions: none - Discussion: - - The POP3 server removes all messages marked as deleted - from the maildrop. It then releases the - exclusive-access lock on the maildrop and replies as - to the success of - these operations. The TCP connection is then closed. - - Possible Responses: - +OK - Examples: - C: QUIT - S: +OK dewey POP3 server signing off (maildrop - empty) - ... - C: QUIT - S: +OK dewey POP3 server signing off (2 messages - left) - ... - - -Optional POP3 Commands - - The POP3 commands discussed above must be supported by all minimal - - - -Rose [Page 10] - -RFC 1225 POP3 May 1991 - - - implementations of POP3 servers. - - The optional POP3 commands described below permit a POP3 client - greater freedom in message handling, while preserving a simple POP3 - server implementation. - - NOTE: This memo STRONGLY encourages implementations to - support these commands in lieu of developing augmented - drop and scan listings. In short, the philosophy of - this memo is to put intelligence in the part of the - POP3 client and not the POP3 server. - - TOP msg n - Arguments: a message-id (required) and a number. This - message-id may NOT refer to a message marked as - deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If the POP3 server issues a positive response, then - the response given is multi-line. After the initial - +OK, the POP3 server sends the headers of the message, - the blank line separating the headers from the body, - and then the number of lines indicated message's body, - being careful to byte-stuff the termination character - (as with all multi-line responses). - - Note that if the number of lines requested by the POP3 - client is greater than than the number of lines in the - body, then the POP3 server sends the entire message. - - Possible Responses: - +OK top of message follows - -ERR no such message - Examples: - C: TOP 10 - S: +OK - S: <the POP3 server sends the headers of the - message, a blank line, and the first 10 lines - of the body of the message> - S: . - ... - C: TOP 100 - S: -ERR no such message - - RPOP user - Arguments: a client specific user-id (required) - Restrictions: may only be given in the AUTHORIZATION - - - -Rose [Page 11] - -RFC 1225 POP3 May 1991 - - - state after a successful USER command; in addition, - may only be given if the client used a reserved - (privileged) TCP port to connect to the server. - Discussion: - - The RPOP command may be used instead of the PASS - command to authenticate access to the maildrop. In - order for this command to be successful, the POP3 - client must use a reserved TCP port (port < 1024) to - connect tothe server. The POP3 server uses the - argument pair from the USER and RPOP commands to - determine if the client should be given access to - the appropriate maildrop. Unlike the PASS command - however, the POP3 server considers if the remote user - specified by the RPOP command who resides on the POP3 - client host is allowed to access the maildrop for the - user specified by the USER command (e.g., on Berkeley - UNIX, the .rhosts mechanism is used). With the - exception of this differing in authentication, this - command is identical to the PASS command. - - Note that the use of this feature has allowed much wider - penetration into numerous hosts on local networks (and - sometimes remote networks) by those who gain illegal - access to computers by guessing passwords or otherwise - breaking into the system. - - Possible Responses: - +OK maildrop locked and ready - -ERR permission denied - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - C: RPOP mrose - S: +OK mrose's maildrop has 2 messages (320 - octets) - - Minimal POP3 Commands: - USER name valid in the AUTHORIZATION state - PASS string - QUIT - - STAT valid in the TRANSACTION state - LIST [msg] - RETR msg - DELE msg - NOOP - LAST - - - -Rose [Page 12] - -RFC 1225 POP3 May 1991 - - - RSET - - QUIT valid in the UPDATE state - - Optional POP3 Commands: - RPOP user valid in the AUTHORIZATION state - - TOP msg n valid in the TRANSACTION state - - POP3 Replies: - +OK - -ERR - - Note that with the exception of the STAT command, the reply given - by the POP3 server to any command is significant only to "+OK" - and "-ERR". Any text occurring after this reply may be ignored - by the client. - -Example POP3 Session - - S: <wait for connection on TCP port 110> - ... - C: <open connection> - S: +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU) - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: +OK mrose's maildrop has 2 messages (320 octets) - C: STAT - S: +OK 2 320 - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends message 1> - S: . - C: DELE 1 - S: +OK message 1 deleted - C: RETR 2 - S: +OK 200 octets - S: <the POP3 server sends message 2> - S: . - C: DELE 2 - S: +OK message 2 deleted - C: QUIT - - - -Rose [Page 13] - -RFC 1225 POP3 May 1991 - - - S: +OK dewey POP3 server signing off (maildrop empty) - C: <close connection> - S: <wait for next connection> - -Message Format - - All messages transmitted during a POP3 session are assumed to conform - to the standard for the format of Internet text messages [RFC822]. - - It is important to note that the byte count for a message on the - server host may differ from the octet count assigned to that message - due to local conventions for designating end-of-line. Usually, - during the AUTHORIZATION state of the POP3 session, the POP3 client - can calculate the size of each message in octets when it parses the - maildrop into messages. For example, if the POP3 server host - internally represents end-of-line as a single character, then the - POP3 server simply counts each occurrence of this character in a - message as two octets. Note that lines in the message which start - with the termination octet need not be counted twice, since the POP3 - client will remove all byte-stuffed termination characters when it - receives a multi-line response. - -The POP and the Split-UA model - - The underlying paradigm in which the POP3 functions is that of a - split-UA model. The POP3 client host, being a remote PC based - workstation, acts solely as a client to the message transport system. - It does not provide delivery/authentication services to others. - Hence, it is acting as a UA, on behalf of the person using the - workstation. Furthermore, the workstation uses SMTP to enter mail - into the MTS. - - In this sense, we have two UA functions which interface to the - message transport system: Posting (SMTP) and Retrieval (POP3). The - entity which supports this type of environment is called a split-UA - (since the user agent is split between two hosts which must - interoperate to provide these functions). - - ASIDE: Others might term this a remote-UA instead. - There are arguments supporting the use of both terms. - - This memo has explicitly referenced TCP as the underlying transport - agent for the POP3. This need not be the case. In the MZnet split- - UA, for example, personal micro-computer systems are used which do - not have IP-style networking capability. To connect to the POP3 - server host, a PC establishes a terminal connection using some simple - protocol (PhoneNet). A program on the PC drives the connection, - first establishing a login session as a normal user. The login shell - - - -Rose [Page 14] - -RFC 1225 POP3 May 1991 - - - for this pseudo-user is a program which drives the other half of the - terminal protocol and communicates with one of two servers. Although - MZnet can support several PCs, a single pseudo-user login is present - on the server host. The user-id and password for this pseudo-user - login is known to all members of MZnet. Hence, the first action of - the login shell, after starting the terminal protocol, is to demand a - USER/PASS authorization pair from the PC. This second level of - authorization is used to ascertain who is interacting with the MTS. - Although the server host is deemed to support a "trusted" MTS entity, - PCs in MZnet are not. Naturally, the USER/PASS authorization pair - for a PC is known only to the owner of the PC (in theory, at least). - - After successfully verifying the identity of the client, a modified - SMTP server is started, and the PC posts mail with the server host. - After the QUIT command is given to the SMTP server and it terminates, - a modified POP3 server is started, and the PC retrieves mail from the - server host. After the QUIT command is given to the POP3 server and - it terminates, the login shell for the pseudo-user terminates the - terminal protocol and logs the job out. The PC then closes the - terminal connection to the server host. - - The SMTP server used by MZnet is modified in the sense that it knows - that it's talking to a user agent and not a "trusted" entity in the - message transport system. Hence, it does performs the validation - activities normally performed by an entity in the MTS when it accepts - a message from a UA. - - The POP3 server used by MZnet is modified in the sense that it does - not require a USER/PASS combination before entering the TRANSACTION - state. The reason for this (of course) is that the PC has already - identified itself during the second-level authorization step - described above. - - NOTE: Truth in advertising laws require that the author - of this memo state that MZnet has not actually been - fully implemented. The concepts presented and proven - by the project led to the notion of the MZnet - split-slot model. This notion has inspired the - split-UA concept described in this memo, led to the - author's interest in the POP, and heavily influenced - the the description of the POP3 herein. - - In fact, some UAs present in the Internet already support the notion - of posting directly to an SMTP server and retrieving mail directly - from a POP server, even if the POP server and client resided on the - same host! - - ASIDE: this discussion raises an issue which this memo - - - -Rose [Page 15] - -RFC 1225 POP3 May 1991 - - - purposedly avoids: how does SMTP know that it's talking - to a "trusted" MTS entity? - -References - - [MZnet] Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail - Service for Personal Micro-Computer Systems", - Proceedings, IFIP 6.5 International Conference on - Computer Message Systems, Nottingham, U.K., May 1984. - - [RFC821] Postel, J., "Simple Mail Transfer Protocol", - USC/Information Sciences Institute, August 1982. - - [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet - Text Messages", University of Delaware, August 1982. - - [RFC937] Butler, M., J. Postel, D. Chase, J. Goldberger, and J. - Reynolds, "Post Office Protocol - Version 2", RFC 937, - USC/Information Sciences Institute, February 1985. - - [RFC1060] Reynolds, J., and J. Postel, "Assigned Numbers", RFC - 1060, USC/Information Sciences Institute, March 1990. - -Security Considerations - - Security issues are not discussed in this memo. - -Author's Address: - - Marshall T. Rose - Performance Systems International - 5201 Great America Parkway - Suite 3106 - Santa Clara, CA 95054 - - Phone: +1 408 562 6222 - - EMail: mrose@psi.com - X.500: rose, psi, us - - - - - - - - - - - - -Rose [Page 16] -
\ No newline at end of file diff --git a/RFC/rfc1460.txt b/RFC/rfc1460.txt deleted file mode 100644 index d6177599..00000000 --- a/RFC/rfc1460.txt +++ /dev/null @@ -1,955 +0,0 @@ - - - - - - -Network Working Group M. Rose -Request for Comments: 1460 Dover Beach Consulting, Inc. -Obsoletes: 1225 June 1993 - - - Post Office Protocol - Version 3 - - -Status of this Memo - - This RFC specifies an IAB standards track protocol for the Internet - community, and requests discussion and suggestions for improvements. - Please refer to the current edition of the "IAB Official Protocol - Standards" for the standardization state and status of this protocol. - Distribution of this memo is unlimited. - -Overview - - This memo is a revision to RFC 1225, a Draft Standard. It makes the - following changes from that document: - - - the RPOP facility is removed; - - - the optional APOP facility is added (which is in interoperable, - operational use in at least three implementations); - - - a typo was corrected with respect to the interaction of LAST - and RSET; - - - section numbers were added; and, - - - an acknowledgements section was added. - -1. Introduction - - On certain types of smaller nodes in the Internet it is often - impractical to maintain a message transport system (MTS). For - example, a workstation may not have sufficient resources (cycles, - disk space) in order to permit a SMTP server [RFC821] and associated - local mail delivery system to be kept resident and continuously - running. - - Similarly, it may be expensive (or impossible) to keep a personal - computer interconnected to an IP-style network for long amounts of - time (the node is lacking the resource known as "connectivity"). - - Despite this, it is often very useful to be able to manage mail on - these smaller nodes, and they often support a user agent (UA) to aid - - - -Rose [Page 1] - -RFC 1460 POP3 June 1993 - - - the tasks of mail handling. To solve this problem, a node which can - support an MTS entity offers a maildrop service to these less endowed - nodes. The Post Office Protocol - Version 3 (POP3) is intended to - permit a workstation to dynamically access a maildrop on a server - host in a useful fashion. Usually, this means that the POP3 is used - to allow a workstation to retrieve mail that the server is holding - for it. - - For the remainder of this memo, the term "client host" refers to a - host making use of the POP3 service, while the term "server host" - refers to a host which offers the POP3 service. - -2. A Short Digression - - This memo does not specify how a client host enters mail into the - transport system, although a method consistent with the philosophy of - this memo is presented here: - - When the user agent on a client host wishes to enter a message - into the transport system, it establishes an SMTP connection to - its relay host (this relay host could be, but need not be, the - POP3 server host for the client host). - - If this method is followed, then the client host appears to the MTS - as a user agent, and should NOT be regarded as a "trusted" MTS entity - in any sense whatsoever. This concept, along with the role of the - POP3 as a part of a split-UA model is discussed later in this memo. - -3. Basic Operation - - Initially, the server host starts the POP3 service by listening on - TCP port 110. When a client host wishes to make use of the service, - it establishes a TCP connection with the server host. When the - connection is established, the POP3 server sends a greeting. The - client and POP3 server then exchange commands and responses - (respectively) until the connection is closed or aborted. - - Commands in the POP3 consist of a keyword possibly followed by an - argument. All commands are terminated by a CRLF pair. - - Responses in the POP3 consist of a success indicator and a keyword - possibly followed by additional information. All responses are - terminated by a CRLF pair. There are currently two success - indicators: positive ("+OK") and negative ("-ERR"). - - Responses to certain commands are multi-line. In these cases, which - are clearly indicated below, after sending the first line of the - response and a CRLF, any additional lines are sent, each terminated - - - -Rose [Page 2] - -RFC 1460 POP3 June 1993 - - - by a CRLF pair. When all lines of the response have been sent, a - final line is sent, consisting of a termination octet (decimal code - 046, ".") and a CRLF pair. If any line of the multi-line response - begins with the termination octet, the line is "byte-stuffed" by - pre-pending the termination octet to that line of the response. - - Hence a multi-line response is terminated with the five octets - "CRLF.CRLF". When examining a multi-line response, the client checks - to see if the line begins with the termination octet. If so and if - octets other than CRLF follow, the the first octet of the line (the - termination octet) is stripped away. If so and if CRLF immediately - follows the termination character, then the response from the POP - server is ended and the line containing ".CRLF" is not considered - part of the multi-line response. - - A POP3 session progresses through a number of states during its - lifetime. Once the TCP connection has been opened and the POP3 - server has sent the greeting, the session enters the AUTHORIZATION - state. In this state, the client must identify itself to the POP3 - server. Once the client has successfully done this, the server - acquires resources associated with the client's maildrop, and the - session enters the TRANSACTION state. In this state, the client - requests actions on the part of the POP3 server. When the client has - finished its transactions, the session enters the UPDATE state. In - this state, the POP3 server releases any resources acquired during - the TRANSACTION state and says goodbye. The TCP connection is then - closed. - -4. The AUTHORIZATION State - - Once the TCP connection has been opened by a POP3 client, the POP3 - server issues a one line greeting. This can be any string terminated - by CRLF. An example might be: - - S. +OK POP3 server ready - - Note that this greeting is a POP3 reply. The POP3 server should - always give a positive response as the greeting. - - The POP3 session is now in the AUTHORIZATION state. The client must - now issue the USER command. If the POP3 server responds with a - positive success indicator ("+OK"), then the client may issue either - the PASS command to complete the authorization, or the QUIT command - to terminate the POP3 session. If the POP3 server responds with a - negative success indicator ("-ERR") to the USER command, then the - client may either issue a new USER command or may issue the QUIT - command. - - - - -Rose [Page 3] - -RFC 1460 POP3 June 1993 - - - When the client issues the PASS command, the POP3 server uses the - argument pair from the USER and PASS commands to determine if the - client should be given access to the appropriate maildrop. If so, - the POP3 server then acquires an exclusive-access lock on the - maildrop. If the lock is successfully acquired, the POP3 server - parses the maildrop into individual messages (read note below), - determines the last message (if any) present in the maildrop that was - referenced by the RETR command, and responds with a positive success - indicator. The POP3 session now enters the TRANSACTION state. If - the lock can not be acquired or the client should is denied access to - the appropriate maildrop or the maildrop can't be parsed for some - reason, the POP3 server responds with a negative success indicator. - (If a lock was acquired but the POP3 server intends to respond with a - negative success indicator, the POP3 server must release the lock - prior to rejecting the command.) At this point, the client may - either issue a new USER command and start again, or the client may - issue the QUIT command. - - NOTE: Minimal implementations of the POP3 need only be - able to break a maildrop into its component messages; - they need NOT be able to parse individual messages. - More advanced implementations may wish to have this - capability, for reasons discussed later. - - After the POP3 server has parsed the maildrop into individual - messages, it assigns a message-id to each message, and notes the size - of the message in octets. The first message in the maildrop is - assigned a message-id of "1", the second is assigned "2", and so on, - so that the n'th message in a maildrop is assigned a message-id of - "n". In POP3 commands and responses, all message-id's and message - sizes are expressed in base-10 (i.e., decimal). - - It sets the "highest number accessed" to be that of the last message - referenced by the RETR command. - - Here are summaries for the three POP3 commands discussed thus far: - - USER name - Arguments: a server specific user-id (required) - Restrictions: may only be given in the AUTHORIZATION - state after the POP3 greeting or after an - unsuccessful USER or PASS command - Possible Responses: - +OK name is welcome here - -ERR never heard of name - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - - - -Rose [Page 4] - -RFC 1460 POP3 June 1993 - - - ... - C: USER frated - S: -ERR sorry, frated doesn't get his mail here - - PASS string - Arguments: a server/user-id specific password (required) - Restrictions: may only be given in the AUTHORIZATION - state after a successful USER command - Possible Responses: - +OK maildrop locked and ready - -ERR invalid password - -ERR unable to lock maildrop - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: +OK mrose's maildrop has 2 messages - (320 octets) - ... - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: -ERR unable to lock mrose's maildrop, file - already locked - - QUIT - Arguments: none - Restrictions: none - Possible Responses: - +OK - Examples: - C: QUIT - S: +OK dewey POP3 server signing off - -5. The TRANSACTION State - - Once the client has successfully identified itself to the POP3 server - and the POP3 server has locked and burst the appropriate maildrop, - the POP3 session is now in the TRANSACTION state. The client may now - issue any of the following POP3 commands repeatedly. After each - command, the POP3 server issues a response. Eventually, the client - issues the QUIT command and the POP3 session enters the UPDATE state. - - Here are the POP3 commands valid in the TRANSACTION state: - - STAT - Arguments: none - Restrictions: may only be given in the TRANSACTION state. - - - -Rose [Page 5] - -RFC 1460 POP3 June 1993 - - - Discussion: - - The POP3 server issues a positive response with a line - containing information for the maildrop. This line is - called a "drop listing" for that maildrop. - - In order to simplify parsing, all POP3 servers are - required to use a certain format for drop listings. - The first octets present must indicate the number of - messages in the maildrop. Following this is the size - of the maildrop in octets. This memo makes no - requirement on what follows the maildrop size. - Minimal implementations should just end that line of - the response with a CRLF pair. More advanced - implementations may include other information. - - NOTE: This memo STRONGLY discourages - implementations from supplying additional - information in the drop listing. Other, - optional, facilities are discussed later on - which permit the client to parse the messages - in the maildrop. - - Note that messages marked as deleted are not counted in - either total. - - Possible Responses: - +OK nn mm - Examples: - C: STAT - S: +OK 2 320 - - LIST [msg] - Arguments: a message-id (optionally) If a message-id is - given, it may NOT refer to a message marked as - deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If an argument was given and the POP3 server issues a - positive response with a line containing information - for that message. This line is called a "scan listing" - for that message. - - If no argument was given and the POP3 server issues a - positive response, then the response given is - multi-line. After the initial +OK, for each message - in the maildrop, the POP3 server responds with a line - - - -Rose [Page 6] - -RFC 1460 POP3 June 1993 - - - containing information for that message. This line - is called a "scan listing" for that message. - - In order to simplify parsing, all POP3 servers are - required to use a certain format for scan listings. - The first octets present must be the message-id of - the message. Following the message-id is the size of - the message in octets. This memo makes no requirement - on what follows the message size in the scan listing. - Minimal implementations should just end that line of - the response with a CRLF pair. More advanced - implementations may include other information, as - parsed from the message. - - NOTE: This memo STRONGLY discourages - implementations from supplying additional - information in the scan listing. Other, optional, - facilities are discussed later on which permit - the client to parse the messages in the maildrop. - - Note that messages marked as deleted are not listed. - - Possible Responses: - +OK scan listing follows - -ERR no such message - Examples: - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - ... - C: LIST 2 - S: +OK 2 200 - ... - C: LIST 3 - S: -ERR no such message, only 2 messages in - maildrop - - RETR msg - Arguments: a message-id (required) This message-id may - NOT refer to a message marked as deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If the POP3 server issues a positive response, then the - response given is multi-line. After the initial +OK, - the POP3 server sends the message corresponding to the - - - -Rose [Page 7] - -RFC 1460 POP3 June 1993 - - - given message-id, being careful to byte-stuff the - termination character (as with all multi-line - responses). - - If the number associated with this message is higher - than the "highest number accessed" in the maildrop, the - POP3 server updates the "highest number accessed" to - the number associated with this message. - - Possible Responses: - +OK message follows - -ERR no such message - Examples: - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends the entire message here> - S: . - - DELE msg - Arguments: a message-id (required) This message-id - may NOT refer to a message marked as deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - The POP3 server marks the message as deleted. Any - future reference to the message-id associated with the - message in a POP3 command generates an error. The POP3 - server does not actually delete the message until the - POP3 session enters the UPDATE state. - - If the number associated with this message is higher - than the "highest number accessed" in the maildrop, - the POP3 server updates the "highest number accessed" - to the number associated with this message. - - Possible Responses: - +OK message deleted - -ERR no such message - Examples: - C: DELE 1 - S: +OK message 1 deleted - ... - C: DELE 2 - S: -ERR message 2 already deleted - - NOOP - Arguments: none - Restrictions: may only be given in the TRANSACTION state. - - - -Rose [Page 8] - -RFC 1460 POP3 June 1993 - - - Discussion: - - The POP3 server does nothing, it merely replies with a - positive response. - - Possible Responses: - +OK - Examples: - C: NOOP - S: +OK - - LAST - Arguments: none - Restrictions: may only be issued in the TRANSACTION state. - Discussion: - - The POP3 server issues a positive response with a line - containing the highest message number which accessed. - Zero is returned in case no message in the maildrop has - been accessed during previous transactions. A client - may thereafter infer that messages, if any, numbered - greater than the response to the LAST command are - messages not yet accessed by the client. - - Possible Response: - +OK nn - - Examples: - C: STAT - S: +OK 4 320 - C: LAST - S: +OK 1 - C: RETR 3 - S: +OK 120 octets - S: <the POP3 server sends the entire message - here> - S: . - C: LAST - S: +OK 3 - C: DELE 2 - S: +OK message 2 deleted - C: LAST - S: +OK 3 - C: RSET - S: +OK - C: LAST - S: +OK 0 - - - - -Rose [Page 9] - -RFC 1460 POP3 June 1993 - - - RSET - Arguments: none - Restrictions: may only be given in the TRANSACTION - state. - Discussion: - - If any messages have been marked as deleted by the POP3 - server, they are unmarked. The POP3 server then - replies with a positive response. In addition, the - "highest number accessed" is also reset to zero. - - Possible Responses: - +OK - Examples: - C: RSET - S: +OK maildrop has 2 messages (320 octets) - -6. The UPDATE State - - When the client issues the QUIT command from the TRANSACTION state, - the POP3 session enters the UPDATE state. (Note that if the client - issues the QUIT command from the AUTHORIZATION state, the POP3 - session terminates but does NOT enter the UPDATE state.) - - QUIT - Arguments: none - Restrictions: none - Discussion: - - The POP3 server removes all messages marked as deleted - from the maildrop. It then releases the - exclusive-access lock on the maildrop and replies as - to the success of these operations. The TCP - connection is then closed. - - Possible Responses: - +OK - Examples: - C: QUIT - S: +OK dewey POP3 server signing off (maildrop - empty) - ... - C: QUIT - S: +OK dewey POP3 server signing off (2 messages - left) - ... - - - - - -Rose [Page 10] - -RFC 1460 POP3 June 1993 - - -7. Optional POP3 Commands - - The POP3 commands discussed above must be supported by all minimal - implementations of POP3 servers. - - The optional POP3 commands described below permit a POP3 client - greater freedom in message handling, while preserving a simple POP3 - server implementation. - - NOTE: This memo STRONGLY encourages implementations to - support these commands in lieu of developing augmented - drop and scan listings. In short, the philosophy of - this memo is to put intelligence in the part of the - POP3 client and not the POP3 server. - - TOP msg n - Arguments: a message-id (required) and a number. This - message-id may NOT refer to a message marked as - deleted. - Restrictions: may only be given in the TRANSACTION state. - Discussion: - - If the POP3 server issues a positive response, then - the response given is multi-line. After the initial - +OK, the POP3 server sends the headers of the message, - the blank line separating the headers from the body, - and then the number of lines indicated message's body, - being careful to byte-stuff the termination character - (as with all multi-line responses). - - Note that if the number of lines requested by the POP3 - client is greater than than the number of lines in the - body, then the POP3 server sends the entire message. - - Possible Responses: - +OK top of message follows - -ERR no such message - Examples: - C: TOP 10 - S: +OK - S: <the POP3 server sends the headers of the - message, a blank line, and the first 10 lines - of the body of the message> - S: . - ... - C: TOP 100 - S: -ERR no such message - - - - -Rose [Page 11] - -RFC 1460 POP3 June 1993 - - - APOP name digest - Arguments: a server specific user-id and a digest string - (both required). - Restrictions: may only be given in the AUTHORIZATION - state after the POP3 greeting - Discussion: - - Normally, each POP3 session starts with a USER/PASS - exchange. This results in a server/user-id specific - password being sent in the clear on the network. For - intermittent use of POP3, this may not introduce a - sizable risk. However, many POP3 client - implementations connect to the POP3 server on a - regular basis -- to check for new mail. Further the - interval of session initiation may be on the order of - five minutes. Hence, the risk of password capture is - greatly enhanced. - - An alternate method of authentication is required - which provides for both origin authentication and - replay protection, but which does not involve sending - a password in the clear over the network. The APOP - command provides this functionality. - - A POP3 server which implements the APOP command will - include a timestamp in its banner greeting. The - syntax of the timestamp corresponds to the "msg-id" - in [RFC822], and MUST be different each time the POP3 - server issues a banner greeting. For example, on a - UNIX implementation in which a separate UNIX process - is used for each instance of a POP3 server, the - syntax of the timestamp might be: - - <process-ID.clock@hostname> - - where "process-ID" is the decimal value of the - process's PID, clock is the decimal value of the - system clock, and hostname is the fully-qualified - domain-name corresponding to the host where the POP3 - server is running. - - The POP3 client makes note of this timestamp, and - then issues the APOP command. The "name" parameter - has identical semantics to the "name" parameter of - the USER command. The "digest" parameter is - calculated by applying the MD5 algorithm [RFC1321] to - a string consisting of the timestamp (including - angle-brackets) followed by a shared secret. This - - - -Rose [Page 12] - -RFC 1460 POP3 June 1993 - - - shared secret is a string known only to the POP3 - client and server. Great care should be taken to - prevent unauthorized disclosure of the secret, as - knowledge of the secret will allow any entity to - successfully masquerade as the named user. The - "digest" parameter itself is a 16-octet value which - is sent in hexadecimal format, using lower-case ASCII - characters. - - When the POP3 server receives the APOP command, it - verifies the digest provided. If the digest is - correct, the POP3 server issues a positive response, - and the POP3 session enters the TRANSACTION state. - Otherwise, a negative response is issued and the POP3 - session remains in the AUTHORIZATION state. - - Possible Responses: - +OK maildrop locked and ready - -ERR permission denied - Examples: - S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> - C: APOP mrose c4c9334bac560ecc979e58001b3e22fb - S: +OK maildrop has 1 message (369 octets) - - In this example, the shared secret is the string "tanstaaf". - Hence, the MD5 algorithm is applied to the string - - <1896.697170952@dbc.mtview.ca.us>tanstaaf - - which produces a digest value of - - c4c9334bac560ecc979e58001b3e22fb - -8. POP3 Command Summary - - Minimal POP3 Commands: - USER name valid in the AUTHORIZATION state - PASS string - QUIT - - STAT valid in the TRANSACTION state - LIST [msg] - RETR msg - DELE msg - NOOP - LAST - RSET - - - - -Rose [Page 13] - -RFC 1460 POP3 June 1993 - - - QUIT valid in the UPDATE state - - Optional POP3 Commands: - APOP name digest valid in the AUTHORIZATION state - - TOP msg n valid in the TRANSACTION state - - POP3 Replies: - +OK - -ERR - - Note that with the exception of the STAT command, the reply given - by the POP3 server to any command is significant only to "+OK" - and "-ERR". Any text occurring after this reply may be ignored - by the client. - -9. Example POP3 Session - - S: <wait for connection on TCP port 110> - ... - C: <open connection> - S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> - C: APOP mrose c4c9334bac560ecc979e58001b3e22fb - S: +OK mrose's maildrop has 2 messages (320 octets) - C: STAT - S: +OK 2 320 - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends message 1> - S: . - C: DELE 1 - S: +OK message 1 deleted - C: RETR 2 - S: +OK 200 octets - S: <the POP3 server sends message 2> - S: . - C: DELE 2 - S: +OK message 2 deleted - C: QUIT - S: +OK dewey POP3 server signing off (maildrop empty) - C: <close connection> - S: <wait for next connection> - - - - -Rose [Page 14] - -RFC 1460 POP3 June 1993 - - -10. Message Format - - All messages transmitted during a POP3 session are assumed to conform - to the standard for the format of Internet text messages [RFC822]. - - It is important to note that the byte count for a message on the - server host may differ from the octet count assigned to that message - due to local conventions for designating end-of-line. Usually, - during the AUTHORIZATION state of the POP3 session, the POP3 client - can calculate the size of each message in octets when it parses the - maildrop into messages. For example, if the POP3 server host - internally represents end-of-line as a single character, then the - POP3 server simply counts each occurrence of this character in a - message as two octets. Note that lines in the message which start - with the termination octet need not be counted twice, since the POP3 - client will remove all byte-stuffed termination characters when it - receives a multi-line response. - -11. The POP and the Split-UA model - - The underlying paradigm in which the POP3 functions is that of a - split-UA model. The POP3 client host, being a remote PC based - workstation, acts solely as a client to the message transport system. - It does not provide delivery/authentication services to others. - Hence, it is acting as a UA, on behalf of the person using the - workstation. Furthermore, the workstation uses SMTP to enter mail - into the MTS. - - In this sense, we have two UA functions which interface to the - message transport system: Posting (SMTP) and Retrieval (POP3). The - entity which supports this type of environment is called a split-UA - (since the user agent is split between two hosts which must - interoperate to provide these functions). - - ASIDE: Others might term this a remote-UA instead. - There are arguments supporting the use of both terms. - - This memo has explicitly referenced TCP as the underlying transport - agent for the POP3. This need not be the case. In the MZnet split- - UA, for example, personal micro-computer systems are used which do - not have IP-style networking capability [MZnet]. To connect to the - POP3 server host, a PC establishes a terminal connection using some - simple protocol (PhoneNet). A program on the PC drives the - connection, first establishing a login session as a normal user. The - login shell for this pseudo-user is a program which drives the other - half of the terminal protocol and communicates with one of two - servers. Although MZnet can support several PCs, a single pseudo- - user login is present on the server host. The user-id and password - - - -Rose [Page 15] - -RFC 1460 POP3 June 1993 - - - for this pseudo-user login is known to all members of MZnet. Hence, - the first action of the login shell, after starting the terminal - protocol, is to demand a USER/PASS authorization pair from the PC. - This second level of authorization is used to ascertain who is - interacting with the MTS. Although the server host is deemed to - support a "trusted" MTS entity, PCs in MZnet are not. Naturally, the - USER/PASS authorization pair for a PC is known only to the owner of - the PC (in theory, at least). - - After successfully verifying the identity of the client, a modified - SMTP server is started, and the PC posts mail with the server host. - After the QUIT command is given to the SMTP server and it terminates, - a modified POP3 server is started, and the PC retrieves mail from the - server host. After the QUIT command is given to the POP3 server and - it terminates, the login shell for the pseudo-user terminates the - terminal protocol and logs the job out. The PC then closes the - terminal connection to the server host. - - The SMTP server used by MZnet is modified in the sense that it knows - that it's talking to a user agent and not a "trusted" entity in the - message transport system. Hence, it does performs the validation - activities normally performed by an entity in the MTS when it accepts - a message from a UA. - - The POP3 server used by MZnet is modified in the sense that it does - not require a USER/PASS combination before entering the TRANSACTION - state. The reason for this (of course) is that the PC has already - identified itself during the second-level authorization step - described above. - - NOTE: Truth in advertising laws require that the author - of this memo state that MZnet has not actually been - fully implemented. The concepts presented and proven - by the project led to the notion of the MZnet - split-slot model. This notion has inspired the - split-UA concept described in this memo, led to the - author's interest in the POP, and heavily influenced - the the description of the POP3 herein. - - In fact, some UAs present in the Internet already support the notion - of posting directly to an SMTP server and retrieving mail directly - from a POP3 server, even if the POP3 server and client resided on the - same host! - - ASIDE: this discussion raises an issue which this memo - purposedly avoids: how does SMTP know that it's talking - to a "trusted" MTS entity? - - - - -Rose [Page 16] - -RFC 1460 POP3 June 1993 - - -12. References - - [MZnet] Stefferud, E., Sweet, J., and T. Domae, "MZnet: Mail - Service for Personal Micro-Computer Systems,: - Proceedings, IFIP 6.5 International Conference on - Computer Message Systems, Nottingham, U.K., May 1984. - - [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, - RFC 821, USC/Information Sciences Institute, August 1982. - - [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet - Text Messages", STD 11, RFC 822, University of Delaware, - August 1982. - - [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT - Laboratory for Computer Science, April 1992. - -13. Security Considerations - - It is conjectured that use of the APOP command provides origin - identification and replay protection for a POP3 session. - Accordingly, a POP3 server which implements both the PASS and APOP - commands must not allow both methods of access for a given user; that - is, for a given "USER name" either the PASS or APOP command is - allowed, but not both. - - Otherwise, security issues are not discussed in this memo. - -14. Acknowledgements - - The POP family has a long and checkered history. Although primarily - a minor revision to [RFC1225], POP3 is based on the ideas presented - in RFCs 918, 937, and 1081. - - In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff - provided significant comments on the APOP command. - -15. Author's Address - - Marshall T. Rose - Dover Beach Consulting, Inc. - Mountain View, CA 94043-2186 - - Phone: +1 415 968 1052 - Fax: +1 415 968 2510 - - EMail: mrose@dbc.mtview.ca.us - X.500: rose, dbc, us - - - -Rose [Page 17] -
\ No newline at end of file diff --git a/RFC/rfc1521.txt b/RFC/rfc1521.txt deleted file mode 100644 index cb4ee75a..00000000 --- a/RFC/rfc1521.txt +++ /dev/null @@ -1,4539 +0,0 @@ -
-
-
-
-
-
-Network Working Group N. Borenstein
-Request for Comments: 1521 Bellcore
-Obsoletes: 1341 N. Freed
-Category: Standards Track Innosoft
- September 1993
-
-
- MIME (Multipurpose Internet Mail Extensions) Part One:
- Mechanisms for Specifying and Describing
- the Format of Internet Message Bodies
-
-Status of this Memo
-
- This RFC specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" for the standardization state and status
- of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- STD 11, RFC 822 defines a message representation protocol which
- specifies considerable detail about message headers, but which leaves
- the message content, or message body, as flat ASCII text. This
- document redefines the format of message bodies to allow multi-part
- textual and non-textual message bodies to be represented and
- exchanged without loss of information. This is based on earlier work
- documented in RFC 934 and STD 11, RFC 1049, but extends and revises
- that work. Because RFC 822 said so little about message bodies, this
- document is largely orthogonal to (rather than a revision of) RFC
- 822.
-
- In particular, this document is designed to provide facilities to
- include multiple objects in a single message, to represent body text
- in character sets other than US-ASCII, to represent formatted multi-
- font text messages, to represent non-textual material such as images
- and audio fragments, and generally to facilitate later extensions
- defining new types of Internet mail for use by cooperating mail
- agents.
-
- This document does NOT extend Internet mail header fields to permit
- anything other than US-ASCII text data. Such extensions are the
- subject of a companion document [RFC-1522].
-
- This document is a revision of RFC 1341. Significant differences
- from RFC 1341 are summarized in Appendix H.
-
-
-
-
-
-Borenstein & Freed [Page 1]
-
-RFC 1521 MIME September 1993
-
-
-Table of Contents
-
- 1. Introduction....................................... 3
- 2. Notations, Conventions, and Generic BNF Grammar.... 6
- 3. The MIME-Version Header Field...................... 7
- 4. The Content-Type Header Field...................... 9
- 5. The Content-Transfer-Encoding Header Field......... 13
- 5.1. Quoted-Printable Content-Transfer-Encoding......... 18
- 5.2. Base64 Content-Transfer-Encoding................... 21
- 6. Additional Content-Header Fields................... 23
- 6.1. Optional Content-ID Header Field................... 23
- 6.2. Optional Content-Description Header Field.......... 24
- 7. The Predefined Content-Type Values................. 24
- 7.1. The Text Content-Type.............................. 24
- 7.1.1. The charset parameter.............................. 25
- 7.1.2. The Text/plain subtype............................. 28
- 7.2. The Multipart Content-Type......................... 28
- 7.2.1. Multipart: The common syntax...................... 29
- 7.2.2. The Multipart/mixed (primary) subtype.............. 34
- 7.2.3. The Multipart/alternative subtype.................. 34
- 7.2.4. The Multipart/digest subtype....................... 36
- 7.2.5. The Multipart/parallel subtype..................... 37
- 7.2.6. Other Multipart subtypes........................... 37
- 7.3. The Message Content-Type........................... 38
- 7.3.1. The Message/rfc822 (primary) subtype............... 38
- 7.3.2. The Message/Partial subtype........................ 39
- 7.3.3. The Message/External-Body subtype.................. 42
- 7.3.3.1. The "ftp" and "tftp" access-types............... 44
- 7.3.3.2. The "anon-ftp" access-type...................... 45
- 7.3.3.3. The "local-file" and "afs" access-types......... 45
- 7.3.3.4. The "mail-server" access-type................... 45
- 7.3.3.5. Examples and Further Explanations............... 46
- 7.4. The Application Content-Type....................... 49
- 7.4.1. The Application/Octet-Stream (primary) subtype..... 50
- 7.4.2. The Application/PostScript subtype................. 50
- 7.4.3. Other Application subtypes......................... 53
- 7.5. The Image Content-Type............................. 53
- 7.6. The Audio Content-Type............................. 54
- 7.7. The Video Content-Type............................. 54
- 7.8. Experimental Content-Type Values................... 54
- 8. Summary............................................ 56
- 9. Security Considerations............................ 56
- 10. Authors' Addresses................................. 57
- 11. Acknowledgements................................... 58
- Appendix A -- Minimal MIME-Conformance.................... 60
- Appendix B -- General Guidelines For Sending Email Data... 63
- Appendix C -- A Complex Multipart Example................. 66
- Appendix D -- Collected Grammar........................... 68
-
-
-
-Borenstein & Freed [Page 2]
-
-RFC 1521 MIME September 1993
-
-
- Appendix E -- IANA Registration Procedures................ 72
- E.1 Registration of New Content-type/subtype Values...... 72
- E.2 Registration of New Access-type Values
- for Message/external-body............................ 73
- Appendix F -- Summary of the Seven Content-types.......... 74
- Appendix G -- Canonical Encoding Model.................... 76
- Appendix H -- Changes from RFC 1341....................... 78
- References................................................ 80
-
-1. Introduction
-
- Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined
- the standard format of textual mail messages on the Internet. Its
- success has been such that the RFC 822 format has been adopted,
- wholly or partially, well beyond the confines of the Internet and the
- Internet SMTP transport defined by STD 10, RFC 821 [RFC-821]. As the
- format has seen wider use, a number of limitations have proven
- increasingly restrictive for the user community.
-
- RFC 822 was intended to specify a format for text messages. As such,
- non-text messages, such as multimedia messages that might include
- audio or images, are simply not mentioned. Even in the case of text,
- however, RFC 822 is inadequate for the needs of mail users whose
- languages require the use of character sets richer than US ASCII
- [US-ASCII]. Since RFC 822 does not specify mechanisms for mail
- containing audio, video, Asian language text, or even text in most
- European languages, additional specifications are needed.
-
- One of the notable limitations of RFC 821/822 based mail systems is
- the fact that they limit the contents of electronic mail messages to
- relatively short lines of seven-bit ASCII. This forces users to
- convert any non-textual data that they may wish to send into seven-
- bit bytes representable as printable ASCII characters before invoking
- a local mail UA (User Agent, a program with which human users send
- and receive mail). Examples of such encodings currently used in the
- Internet include pure hexadecimal, uuencode, the 3-in-4 base 64
- scheme specified in RFC 1421, the Andrew Toolkit Representation
- [ATK], and many others.
-
- The limitations of RFC 822 mail become even more apparent as gateways
- are designed to allow for the exchange of mail messages between RFC
- 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
- inclusion of non-textual body parts within electronic mail messages.
- The current standards for the mapping of X.400 messages to RFC 822
- messages specify either that X.400 non-textual body parts must be
- converted to (not encoded in) an ASCII format, or that they must be
- discarded, notifying the RFC 822 user that discarding has occurred.
- This is clearly undesirable, as information that a user may wish to
-
-
-
-Borenstein & Freed [Page 3]
-
-RFC 1521 MIME September 1993
-
-
- receive is lost. Even though a user's UA may not have the capability
- of dealing with the non-textual body part, the user might have some
- mechanism external to the UA that can extract useful information from
- the body part. Moreover, it does not allow for the fact that the
- message may eventually be gatewayed back into an X.400 message
- handling system (i.e., the X.400 message is "tunneled" through
- Internet mail), where the non-textual information would definitely
- become useful again.
-
- This document describes several mechanisms that combine to solve most
- of these problems without introducing any serious incompatibilities
- with the existing world of RFC 822 mail. In particular, it
- describes:
-
- 1. A MIME-Version header field, which uses a version number to
- declare a message to be conformant with this specification and
- allows mail processing agents to distinguish between such
- messages and those generated by older or non-conformant software,
- which is presumed to lack such a field.
-
- 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],
- which can be used to specify the type and subtype of data in the
- body of a message and to fully specify the native representation
- (encoding) of such data.
-
- 2.a. A "text" Content-Type value, which can be used to represent
- textual information in a number of character sets and
- formatted text description languages in a standardized
- manner.
-
- 2.b. A "multipart" Content-Type value, which can be used to
- combine several body parts, possibly of differing types of
- data, into a single message.
-
- 2.c. An "application" Content-Type value, which can be used to
- transmit application data or binary data, and hence, among
- other uses, to implement an electronic mail file transfer
- service.
-
- 2.d. A "message" Content-Type value, for encapsulating another
- mail message.
-
- 2.e An "image" Content-Type value, for transmitting still image
- (picture) data.
-
- 2.f. An "audio" Content-Type value, for transmitting audio or
- voice data.
-
-
-
-
-Borenstein & Freed [Page 4]
-
-RFC 1521 MIME September 1993
-
-
- 2.g. A "video" Content-Type value, for transmitting video or
- moving image data, possibly with audio as part of the
- composite video data format.
-
- 3. A Content-Transfer-Encoding header field, which can be used to
- specify an auxiliary encoding that was applied to the data in
- order to allow it to pass through mail transport mechanisms which
- may have data or character set limitations.
-
- 4. Two additional header fields that can be used to further describe
- the data in a message body, the Content-ID and Content-
- Description header fields.
-
- MIME has been carefully designed as an extensible mechanism, and it
- is expected that the set of content-type/subtype pairs and their
- associated parameters will grow significantly with time. Several
- other MIME fields, notably including character set names, are likely
- to have new values defined over time. In order to ensure that the
- set of such values is developed in an orderly, well-specified, and
- public manner, MIME defines a registration process which uses the
- Internet Assigned Numbers Authority (IANA) as a central registry for
- such values. Appendix E provides details about how IANA registration
- is accomplished.
-
- Finally, to specify and promote interoperability, Appendix A of this
- document provides a basic applicability statement for a subset of the
- above mechanisms that defines a minimal level of "conformance" with
- this document.
-
- HISTORICAL NOTE: Several of the mechanisms described in this
- document may seem somewhat strange or even baroque at first
- reading. It is important to note that compatibility with existing
- standards AND robustness across existing practice were two of the
- highest priorities of the working group that developed this
- document. In particular, compatibility was always favored over
- elegance.
-
- MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]
- [RFC-1342]. This document is a relatively minor updating of RFC
- 1341, and is intended to supersede it. The differences between this
- document and RFC 1341 are summarized in Appendix H. Please refer to
- the current edition of the "IAB Official Protocol Standards" for the
- standardization state and status of this protocol. Several other RFC
- documents will be of interest to the MIME implementor, in particular
- [RFC 1343], [RFC-1344], and [RFC-1345].
-
-
-
-
-
-
-Borenstein & Freed [Page 5]
-
-RFC 1521 MIME September 1993
-
-
-2. Notations, Conventions, and Generic BNF Grammar
-
- This document is being published in two versions, one as plain ASCII
- text and one as PostScript (PostScript is a trademark of Adobe
- Systems Incorporated.). While the text version is the official
- specification, some will find the PostScript version easier to read.
- The textual contents are identical. An Andrew-format copy of this
- document is also available from the first author (Borenstein).
-
- Although the mechanisms specified in this document are all described
- in prose, most are also described formally in the modified BNF
- notation of RFC 822. Implementors will need to be familiar with this
- notation in order to understand this specification, and are referred
- to RFC 822 for a complete explanation of the modified BNF notation.
-
- Some of the modified BNF in this document makes reference to
- syntactic entities that are defined in RFC 822 and not in this
- document. A complete formal grammar, then, is obtained by combining
- the collected grammar appendix of this document with that of RFC 822
- plus the modifications to RFC 822 defined in RFC 1123, which
- specifically changes the syntax for `return', `date' and `mailbox'.
-
- The term CRLF, in this document, refers to the sequence of the two
- ASCII characters CR (13) and LF (10) which, taken together, in this
- order, denote a line break in RFC 822 mail.
-
- The term "character set" is used in this document to refer to a
- method used with one or more tables to convert encoded text to a
- series of octets. This definition is intended to allow various kinds
- of text encodings, from simple single-table mappings such as ASCII to
- complex table switching methods such as those that use ISO 2022's
- techniques. However, a MIME character set name must fully specify
- the mapping to be performed.
-
- The term "message", when not further qualified, means either the
- (complete or "top-level") message being transferred on a network, or
- a message encapsulated in a body of type "message".
-
- The term "body part", in this document, means one of the parts of the
- body of a multipart entity. A body part has a header and a body, so
- it makes sense to speak about the body of a body part.
-
- The term "entity", in this document, means either a message or a body
- part. All kinds of entities share the property that they have a
- header and a body.
-
- The term "body", when not further qualified, means the body of an
- entity, that is the body of either a message or of a body part.
-
-
-
-Borenstein & Freed [Page 6]
-
-RFC 1521 MIME September 1993
-
-
- NOTE: The previous four definitions are clearly circular. This is
- unavoidable, since the overall structure of a MIME message is
- indeed recursive.
-
- In this document, all numeric and octet values are given in decimal
- notation.
-
- It must be noted that Content-Type values, subtypes, and parameter
- names as defined in this document are case-insensitive. However,
- parameter values are case-sensitive unless otherwise specified for
- the specific parameter.
-
- FORMATTING NOTE: This document has been carefully formatted for
- ease of reading. The PostScript version of this document, in
- particular, places notes like this one, which may be skipped by
- the reader, in a smaller, italicized, font, and indents it as
- well. In the text version, only the indentation is preserved, so
- if you are reading the text version of this you might consider
- using the PostScript version instead. However, all such notes will
- be indented and preceded by "NOTE:" or some similar introduction,
- even in the text version.
-
- The primary purpose of these non-essential notes is to convey
- information about the rationale of this document, or to place this
- document in the proper historical or evolutionary context. Such
- information may be skipped by those who are focused entirely on
- building a conformant implementation, but may be of use to those
- who wish to understand why this document is written as it is.
-
- For ease of recognition, all BNF definitions have been placed in a
- fixed-width font in the PostScript version of this document.
-
-3. The MIME-Version Header Field
-
- Since RFC 822 was published in 1982, there has really been only one
- format standard for Internet messages, and there has been little
- perceived need to declare the format standard in use. This document
- is an independent document that complements RFC 822. Although the
- extensions in this document have been defined in such a way as to be
- compatible with RFC 822, there are still circumstances in which it
- might be desirable for a mail-processing agent to know whether a
- message was composed with the new standard in mind.
-
- Therefore, this document defines a new header field, "MIME-Version",
- which is to be used to declare the version of the Internet message
- body format standard in use.
-
- Messages composed in accordance with this document MUST include such
-
-
-
-Borenstein & Freed [Page 7]
-
-RFC 1521 MIME September 1993
-
-
- a header field, with the following verbatim text:
-
- MIME-Version: 1.0
-
- The presence of this header field is an assertion that the message
- has been composed in compliance with this document.
-
- Since it is possible that a future document might extend the message
- format standard again, a formal BNF is given for the content of the
- MIME-Version field:
-
- version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
-
- Thus, future format specifiers, which might replace or extend "1.0",
- are constrained to be two integer fields, separated by a period. If
- a message is received with a MIME-version value other than "1.0", it
- cannot be assumed to conform with this specification.
-
- Note that the MIME-Version header field is required at the top level
- of a message. It is not required for each body part of a multipart
- entity. It is required for the embedded headers of a body of type
- "message" if and only if the embedded message is itself claimed to be
- MIME-conformant.
-
- It is not possible to fully specify how a mail reader that conforms
- with MIME as defined in this document should treat a message that
- might arrive in the future with some value of MIME-Version other than
- "1.0". However, conformant software is encouraged to check the
- version number and at least warn the user if an unrecognized MIME-
- version is encountered.
-
- It is also worth noting that version control for specific content-
- types is not accomplished using the MIME-Version mechanism. In
- particular, some formats (such as application/postscript) have
- version numbering conventions that are internal to the document
- format. Where such conventions exist, MIME does nothing to supersede
- them. Where no such conventions exist, a MIME type might use a
- "version" parameter in the content-type field if necessary.
-
- NOTE TO IMPLEMENTORS: All header fields defined in this document,
- including MIME-Version, Content-type, etc., are subject to the
- general syntactic rules for header fields specified in RFC 822. In
- particular, all can include comments, which means that the following
- two MIME-Version fields are equivalent:
-
- MIME-Version: 1.0
- MIME-Version: 1.0 (Generated by GBD-killer 3.7)
-
-
-
-
-Borenstein & Freed [Page 8]
-
-RFC 1521 MIME September 1993
-
-
-4. The Content-Type Header Field
-
- The purpose of the Content-Type field is to describe the data
- contained in the body fully enough that the receiving user agent can
- pick an appropriate agent or mechanism to present the data to the
- user, or otherwise deal with the data in an appropriate manner.
-
- HISTORICAL NOTE: The Content-Type header field was first defined in
- RFC 1049. RFC 1049 Content-types used a simpler and less powerful
- syntax, but one that is largely compatible with the mechanism given
- here.
-
- The Content-Type header field is used to specify the nature of the
- data in the body of an entity, by giving type and subtype
- identifiers, and by providing auxiliary information that may be
- required for certain types. After the type and subtype names, the
- remainder of the header field is simply a set of parameters,
- specified in an attribute/value notation. The set of meaningful
- parameters differs for the different types. In particular, there are
- NO globally-meaningful parameters that apply to all content-types.
- Global mechanisms are best addressed, in the MIME model, by the
- definition of additional Content-* header fields. The ordering of
- parameters is not significant. Among the defined parameters is a
- "charset" parameter by which the character set used in the body may
- be declared. Comments are allowed in accordance with RFC 822 rules
- for structured header fields.
-
- In general, the top-level Content-Type is used to declare the general
- type of data, while the subtype specifies a specific format for that
- type of data. Thus, a Content-Type of "image/xyz" is enough to tell
- a user agent that the data is an image, even if the user agent has no
- knowledge of the specific image format "xyz". Such information can
- be used, for example, to decide whether or not to show a user the raw
- data from an unrecognized subtype -- such an action might be
- reasonable for unrecognized subtypes of text, but not for
- unrecognized subtypes of image or audio. For this reason, registered
- subtypes of audio, image, text, and video, should not contain
- embedded information that is really of a different type. Such
- compound types should be represented using the "multipart" or
- "application" types.
-
- Parameters are modifiers of the content-subtype, and do not
- fundamentally affect the requirements of the host system. Although
- most parameters make sense only with certain content-types, others
- are "global" in the sense that they might apply to any subtype. For
- example, the "boundary" parameter makes sense only for the
- "multipart" content-type, but the "charset" parameter might make
- sense with several content-types.
-
-
-
-Borenstein & Freed [Page 9]
-
-RFC 1521 MIME September 1993
-
-
- An initial set of seven Content-Types is defined by this document.
- This set of top-level names is intended to be substantially complete.
- It is expected that additions to the larger set of supported types
- can generally be accomplished by the creation of new subtypes of
- these initial types. In the future, more top-level types may be
- defined only by an extension to this standard. If another primary
- type is to be used for any reason, it must be given a name starting
- with "X-" to indicate its non-standard status and to avoid a
- potential conflict with a future official name.
-
- In the Augmented BNF notation of RFC 822, a Content-Type header field
- value is defined as follows:
-
- content := "Content-Type" ":" type "/" subtype *(";"
- parameter)
- ; case-insensitive matching of type and subtype
-
- type := "application" / "audio"
- / "image" / "message"
- / "multipart" / "text"
- / "video" / extension-token
- ; All values case-insensitive
-
- extension-token := x-token / iana-token
-
- iana-token := <a publicly-defined extension token,
- registered with IANA, as specified in
- appendix E>
-
- x-token := <The two characters "X-" or "x-" followed, with
- no intervening white space, by any token>
-
- subtype := token ; case-insensitive
-
- parameter := attribute "=" value
-
- attribute := token ; case-insensitive
-
- value := token / quoted-string
-
- token := 1*<any (ASCII) CHAR except SPACE, CTLs,
- or tspecials>
-
- tspecials := "(" / ")" / "<" / ">" / "@"
- / "," / ";" / ":" / "\" / <">
- / "/" / "[" / "]" / "?" / "="
- ; Must be in quoted-string,
- ; to use within parameter values
-
-
-
-Borenstein & Freed [Page 10]
-
-RFC 1521 MIME September 1993
-
-
- Note that the definition of "tspecials" is the same as the RFC 822
- definition of "specials" with the addition of the three characters
- "/", "?", and "=", and the removal of ".".
-
- Note also that a subtype specification is MANDATORY. There are no
- default subtypes.
-
- The type, subtype, and parameter names are not case sensitive. For
- example, TEXT, Text, and TeXt are all equivalent. Parameter values
- are normally case sensitive, but certain parameters are interpreted
- to be case-insensitive, depending on the intended use. (For example,
- multipart boundaries are case-sensitive, but the "access-type" for
- message/External-body is not case-sensitive.)
-
- Beyond this syntax, the only constraint on the definition of subtype
- names is the desire that their uses must not conflict. That is, it
- would be undesirable to have two different communities using
- "Content-Type: application/foobar" to mean two different things. The
- process of defining new content-subtypes, then, is not intended to be
- a mechanism for imposing restrictions, but simply a mechanism for
- publicizing the usages. There are, therefore, two acceptable
- mechanisms for defining new Content-Type subtypes:
-
- 1. Private values (starting with "X-") may be
- defined bilaterally between two cooperating
- agents without outside registration or
- standardization.
-
- 2. New standard values must be documented,
- registered with, and approved by IANA, as
- described in Appendix E. Where intended for
- public use, the formats they refer to must
- also be defined by a published specification,
- and possibly offered for standardization.
-
- The seven standard initial predefined Content-Types are detailed in
- the bulk of this document. They are:
-
- text -- textual information. The primary subtype,
- "plain", indicates plain (unformatted) text. No
- special software is required to get the full
- meaning of the text, aside from support for the
- indicated character set. Subtypes are to be used
- for enriched text in forms where application
- software may enhance the appearance of the text,
- but such software must not be required in order to
- get the general idea of the content. Possible
- subtypes thus include any readable word processor
-
-
-
-Borenstein & Freed [Page 11]
-
-RFC 1521 MIME September 1993
-
-
- format. A very simple and portable subtype,
- richtext, was defined in RFC 1341, with a future
- revision expected.
-
- multipart -- data consisting of multiple parts of
- independent data types. Four initial subtypes
- are defined, including the primary "mixed"
- subtype, "alternative" for representing the same
- data in multiple formats, "parallel" for parts
- intended to be viewed simultaneously, and "digest"
- for multipart entities in which each part is of
- type "message".
-
- message -- an encapsulated message. A body of
- Content-Type "message" is itself all or part of a
- fully formatted RFC 822 conformant message which
- may contain its own different Content-Type header
- field. The primary subtype is "rfc822". The
- "partial" subtype is defined for partial messages,
- to permit the fragmented transmission of bodies
- that are thought to be too large to be passed
- through mail transport facilities. Another
- subtype, "External-body", is defined for
- specifying large bodies by reference to an
- external data source.
-
- image -- image data. Image requires a display device
- (such as a graphical display, a printer, or a FAX
- machine) to view the information. Initial
- subtypes are defined for two widely-used image
- formats, jpeg and gif.
-
- audio -- audio data, with initial subtype "basic".
- Audio requires an audio output device (such as a
- speaker or a telephone) to "display" the contents.
-
- video -- video data. Video requires the capability to
- display moving images, typically including
- specialized hardware and software. The initial
- subtype is "mpeg".
-
- application -- some other kind of data, typically
- either uninterpreted binary data or information to
- be processed by a mail-based application. The
- primary subtype, "octet-stream", is to be used in
- the case of uninterpreted binary data, in which
- case the simplest recommended action is to offer
- to write the information into a file for the user.
-
-
-
-Borenstein & Freed [Page 12]
-
-RFC 1521 MIME September 1993
-
-
- An additional subtype, "PostScript", is defined
- for transporting PostScript documents in bodies.
- Other expected uses for "application" include
- spreadsheets, data for mail-based scheduling
- systems, and languages for "active"
- (computational) email. (Note that active email
- and other application data may entail several
- security considerations, which are discussed later
- in this memo, particularly in the context of
- application/PostScript.)
-
- Default RFC 822 messages are typed by this protocol as plain text in
- the US-ASCII character set, which can be explicitly specified as
- "Content-type: text/plain; charset=us-ascii". If no Content-Type is
- specified, this default is assumed. In the presence of a MIME-
- Version header field, a receiving User Agent can also assume that
- plain US-ASCII text was the sender's intent. In the absence of a
- MIME-Version specification, plain US-ASCII text must still be
- assumed, but the sender's intent might have been otherwise.
-
- RATIONALE: In the absence of any Content-Type header field or
- MIME-Version header field, it is impossible to be certain that a
- message is actually text in the US-ASCII character set, since it
- might well be a message that, using the conventions that predate
- this document, includes text in another character set or non-
- textual data in a manner that cannot be automatically recognized
- (e.g., a uuencoded compressed UNIX tar file). Although there is
- no fully acceptable alternative to treating such untyped messages
- as "text/plain; charset=us-ascii", implementors should remain
- aware that if a message lacks both the MIME-Version and the
- Content-Type header fields, it may in practice contain almost
- anything.
-
- It should be noted that the list of Content-Type values given here
- may be augmented in time, via the mechanisms described above, and
- that the set of subtypes is expected to grow substantially.
-
- When a mail reader encounters mail with an unknown Content-type
- value, it should generally treat it as equivalent to
- "application/octet-stream", as described later in this document.
-
-5. The Content-Transfer-Encoding Header Field
-
- Many Content-Types which could usefully be transported via email are
- represented, in their "natural" format, as 8-bit character or binary
- data. Such data cannot be transmitted over some transport protocols.
- For example, RFC 821 restricts mail messages to 7-bit US-ASCII data
- with lines no longer than 1000 characters.
-
-
-
-Borenstein & Freed [Page 13]
-
-RFC 1521 MIME September 1993
-
-
- It is necessary, therefore, to define a standard mechanism for re-
- encoding such data into a 7-bit short-line format. This document
- specifies that such encodings will be indicated by a new "Content-
- Transfer-Encoding" header field. The Content-Transfer-Encoding field
- is used to indicate the type of transformation that has been used in
- order to represent the body in an acceptable manner for transport.
-
- Unlike Content-Types, a proliferation of Content-Transfer-Encoding
- values is undesirable and unnecessary. However, establishing only a
- single Content-Transfer-Encoding mechanism does not seem possible.
- There is a tradeoff between the desire for a compact and efficient
- encoding of largely-binary data and the desire for a readable
- encoding of data that is mostly, but not entirely, 7-bit data. For
- this reason, at least two encoding mechanisms are necessary: a
- "readable" encoding and a "dense" encoding.
-
- The Content-Transfer-Encoding field is designed to specify an
- invertible mapping between the "native" representation of a type of
- data and a representation that can be readily exchanged using 7 bit
- mail transport protocols, such as those defined by RFC 821 (SMTP).
- This field has not been defined by any previous standard. The field's
- value is a single token specifying the type of encoding, as
- enumerated below. Formally:
-
- encoding := "Content-Transfer-Encoding" ":" mechanism
-
- mechanism := "7bit" ; case-insensitive
- / "quoted-printable"
- / "base64"
- / "8bit"
- / "binary"
- / x-token
-
- These values are not case sensitive. That is, Base64 and BASE64 and
- bAsE64 are all equivalent. An encoding type of 7BIT requires that
- the body is already in a seven-bit mail-ready representation. This
- is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is
- assumed if the Content-Transfer-Encoding header field is not present.
-
- The values "8bit", "7bit", and "binary" all mean that NO encoding has
- been performed. However, they are potentially useful as indications
- of the kind of data contained in the object, and therefore of the
- kind of encoding that might need to be performed for transmission in
- a given transport system. In particular:
-
- "7bit" means that the data is all represented as short
- lines of US-ASCII data.
-
-
-
-
-Borenstein & Freed [Page 14]
-
-RFC 1521 MIME September 1993
-
-
- "8bit" means that the lines are short, but there may be
- non-ASCII characters (octets with the high-order
- bit set).
-
- "Binary" means that not only may non-ASCII characters
- be present, but also that the lines are not
- necessarily short enough for SMTP transport.
-
- The difference between "8bit" (or any other conceivable bit-width
- token) and the "binary" token is that "binary" does not require
- adherence to any limits on line length or to the SMTP CRLF semantics,
- while the bit-width tokens do require such adherence. If the body
- contains data in any bit-width other than 7-bit, the appropriate
- bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"
- for unencoded 8 bit wide data). If the body contains binary data,
- the "binary" Content-Transfer-Encoding token must be used.
-
- NOTE: The distinction between the Content-Transfer-Encoding values
- of "binary", "8bit", etc. may seem unimportant, in that all of
- them really mean "none" -- that is, there has been no encoding of
- the data for transport. However, clear labeling will be of
- enormous value to gateways between future mail transport systems
- with differing capabilities in transporting data that do not meet
- the restrictions of RFC 821 transport.
-
- Mail transport for unencoded 8-bit data is defined in RFC-1426
- [RFC-1426]. As of the publication of this document, there are no
- standardized Internet mail transports for which it is legitimate
- to include unencoded binary data in mail bodies. Thus there are
- no circumstances in which the "binary" Content-Transfer-Encoding
- is actually legal on the Internet. However, in the event that
- binary mail transport becomes a reality in Internet mail, or when
- this document is used in conjunction with any other binary-capable
- transport mechanism, binary bodies should be labeled as such using
- this mechanism.
-
- NOTE: The five values defined for the Content-Transfer-Encoding
- field imply nothing about the Content-Type other than the
- algorithm by which it was encoded or the transport system
- requirements if unencoded.
-
- Implementors may, if necessary, define new Content-Transfer-Encoding
- values, but must use an x-token, which is a name prefixed by "X-" to
- indicate its non-standard status, e.g., "Content-Transfer-Encoding:
- x-my-new-encoding". However, unlike Content-Types and subtypes, the
- creation of new Content-Transfer-Encoding values is explicitly and
- strongly discouraged, as it seems likely to hinder interoperability
- with little potential benefit. Their use is allowed only as the
-
-
-
-Borenstein & Freed [Page 15]
-
-RFC 1521 MIME September 1993
-
-
- result of an agreement between cooperating user agents.
-
- If a Content-Transfer-Encoding header field appears as part of a
- message header, it applies to the entire body of that message. If a
- Content-Transfer-Encoding header field appears as part of a body
- part's headers, it applies only to the body of that body part. If an
- entity is of type "multipart" or "message", the Content-Transfer-
- Encoding is not permitted to have any value other than a bit width
- (e.g., "7bit", "8bit", etc.) or "binary".
-
- It should be noted that email is character-oriented, so that the
- mechanisms described here are mechanisms for encoding arbitrary octet
- streams, not bit streams. If a bit stream is to be encoded via one
- of these mechanisms, it must first be converted to an 8-bit byte
- stream using the network standard bit order ("big-endian"), in which
- the earlier bits in a stream become the higher-order bits in a byte.
- A bit stream not ending at an 8-bit boundary must be padded with
- zeroes. This document provides a mechanism for noting the addition
- of such padding in the case of the application Content-Type, which
- has a "padding" parameter.
-
- The encoding mechanisms defined here explicitly encode all data in
- ASCII. Thus, for example, suppose an entity has header fields such
- as:
-
- Content-Type: text/plain; charset=ISO-8859-1
- Content-transfer-encoding: base64
-
- This must be interpreted to mean that the body is a base64 ASCII
- encoding of data that was originally in ISO-8859-1, and will be in
- that character set again after decoding.
-
- The following sections will define the two standard encoding
- mechanisms. The definition of new content-transfer-encodings is
- explicitly discouraged and should only occur when absolutely
- necessary. All content-transfer-encoding namespace except that
- beginning with "X-" is explicitly reserved to the IANA for future
- use. Private agreements about content-transfer-encodings are also
- explicitly discouraged.
-
- Certain Content-Transfer-Encoding values may only be used on certain
- Content-Types. In particular, it is expressly forbidden to use any
- encodings other than "7bit", "8bit", or "binary" with any Content-
- Type that recursively includes other Content-Type fields, notably the
- "multipart" and "message" Content-Types. All encodings that are
- desired for bodies of type multipart or message must be done at the
- innermost level, by encoding the actual body that needs to be
- encoded.
-
-
-
-Borenstein & Freed [Page 16]
-
-RFC 1521 MIME September 1993
-
-
- NOTE ON ENCODING RESTRICTIONS: Though the prohibition against
- using content-transfer-encodings on data of type multipart or
- message may seem overly restrictive, it is necessary to prevent
- nested encodings, in which data are passed through an encoding
- algorithm multiple times, and must be decoded multiple times in
- order to be properly viewed. Nested encodings add considerable
- complexity to user agents: aside from the obvious efficiency
- problems with such multiple encodings, they can obscure the basic
- structure of a message. In particular, they can imply that
- several decoding operations are necessary simply to find out what
- types of objects a message contains. Banning nested encodings may
- complicate the job of certain mail gateways, but this seems less
- of a problem than the effect of nested encodings on user agents.
-
- NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-
- TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding
- could be inferred from the characteristics of the Content-Type
- that is to be encoded, or, at the very least, that certain
- Content-Transfer-Encodings could be mandated for use with specific
- Content-Types. There are several reasons why this is not the case.
- First, given the varying types of transports used for mail, some
- encodings may be appropriate for some Content-Type/transport
- combinations and not for others. (For example, in an 8-bit
- transport, no encoding would be required for text in certain
- character sets, while such encodings are clearly required for 7-
- bit SMTP.) Second, certain Content-Types may require different
- types of transfer encoding under different circumstances. For
- example, many PostScript bodies might consist entirely of short
- lines of 7-bit data and hence require little or no encoding.
- Other PostScript bodies (especially those using Level 2
- PostScript's binary encoding mechanism) may only be reasonably
- represented using a binary transport encoding. Finally, since
- Content-Type is intended to be an open-ended specification
- mechanism, strict specification of an association between
- Content-Types and encodings effectively couples the specification
- of an application protocol with a specific lower-level transport.
- This is not desirable since the developers of a Content-Type
- should not have to be aware of all the transports in use and what
- their limitations are.
-
- NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64
- encodings are designed so that conversion between them is
- possible. The only issue that arises in such a conversion is the
- handling of line breaks. When converting from quoted-printable to
- base64 a line break must be converted into a CRLF sequence.
- Similarly, a CRLF sequence in base64 data must be converted to a
- quoted-printable line break, but ONLY when converting text data.
-
-
-
-
-Borenstein & Freed [Page 17]
-
-RFC 1521 MIME September 1993
-
-
- NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in
- earlier drafts of this memo, regarding the model for when email
- data was to be converted to canonical form and encoded, and in
- particular how this process would affect the treatment of CRLFs,
- given that the representation of newlines varies greatly from
- system to system, and the relationship between content-transfer-
- encodings and character sets. For this reason, a canonical model
- for encoding is presented as Appendix G.
-
-5.1. Quoted-Printable Content-Transfer-Encoding
-
- The Quoted-Printable encoding is intended to represent data that
- largely consists of octets that correspond to printable characters in
- the ASCII character set. It encodes the data in such a way that the
- resulting octets are unlikely to be modified by mail transport. If
- the data being encoded are mostly ASCII text, the encoded form of the
- data remains largely recognizable by humans. A body which is
- entirely ASCII may also be encoded in Quoted-Printable to ensure the
- integrity of the data should the message pass through a character-
- translating, and/or line-wrapping gateway.
-
- In this encoding, octets are to be represented as determined by the
- following rules:
-
- Rule #1: (General 8-bit representation) Any octet, except those
- indicating a line break according to the newline convention of the
- canonical (standard) form of the data being encoded, may be
- represented by an "=" followed by a two digit hexadecimal
- representation of the octet's value. The digits of the
- hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".
- Uppercase letters must be used when sending hexadecimal data,
- though a robust implementation may choose to recognize lowercase
- letters on receipt. Thus, for example, the value 12 (ASCII form
- feed) can be represented by "=0C", and the value 61 (ASCII EQUAL
- SIGN) can be represented by "=3D". Except when the following
- rules allow an alternative encoding, this rule is mandatory.
-
- Rule #2: (Literal representation) Octets with decimal values of 33
- through 60 inclusive, and 62 through 126, inclusive, MAY be
- represented as the ASCII characters which correspond to those
- octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN
- through TILDE, respectively).
-
- Rule #3: (White Space): Octets with values of 9 and 32 MAY be
- represented as ASCII TAB (HT) and SPACE characters, respectively,
- but MUST NOT be so represented at the end of an encoded line. Any
- TAB (HT) or SPACE characters on an encoded line MUST thus be
- followed on that line by a printable character. In particular, an
-
-
-
-Borenstein & Freed [Page 18]
-
-RFC 1521 MIME September 1993
-
-
- "=" at the end of an encoded line, indicating a soft line break
- (see rule #5) may follow one or more TAB (HT) or SPACE characters.
- It follows that an octet with value 9 or 32 appearing at the end
- of an encoded line must be represented according to Rule #1. This
- rule is necessary because some MTAs (Message Transport Agents,
- programs which transport messages from one user to another, or
- perform a part of such transfers) are known to pad lines of text
- with SPACEs, and others are known to remove "white space"
- characters from the end of a line. Therefore, when decoding a
- Quoted-Printable body, any trailing white space on a line must be
- deleted, as it will necessarily have been added by intermediate
- transport agents.
-
- Rule #4 (Line Breaks): A line break in a text body, independent of
- what its representation is following the canonical representation
- of the data being encoded, must be represented by a (RFC 822) line
- break, which is a CRLF sequence, in the Quoted-Printable encoding.
- Since the canonical representation of types other than text do not
- generally include the representation of line breaks, no hard line
- breaks (i.e. line breaks that are intended to be meaningful and
- to be displayed to the user) should occur in the quoted-printable
- encoding of such types. Of course, occurrences of "=0D", "=0A",
- "0A=0D" and "=0D=0A" will eventually be encountered. In general,
- however, base64 is preferred over quoted-printable for binary
- data.
-
- Note that many implementations may elect to encode the local
- representation of various content types directly, as described in
- Appendix G. In particular, this may apply to plain text material
- on systems that use newline conventions other than CRLF
- delimiters. Such an implementation is permissible, but the
- generation of line breaks must be generalized to account for the
- case where alternate representations of newline sequences are
- used.
-
- Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES
- that encoded lines be no more than 76 characters long. If longer
- lines are to be encoded with the Quoted-Printable encoding, 'soft'
- line breaks must be used. An equal sign as the last character on a
- encoded line indicates such a non-significant ('soft') line break
- in the encoded text. Thus if the "raw" form of the line is a
- single unencoded line that says:
-
- Now's the time for all folk to come to the aid of
- their country.
-
- This can be represented, in the Quoted-Printable encoding, as
-
-
-
-
-Borenstein & Freed [Page 19]
-
-RFC 1521 MIME September 1993
-
-
- Now's the time =
- for all folk to come=
- to the aid of their country.
-
- This provides a mechanism with which long lines are encoded in
- such a way as to be restored by the user agent. The 76 character
- limit does not count the trailing CRLF, but counts all other
- characters, including any equal signs.
-
- Since the hyphen character ("-") is represented as itself in the
- Quoted-Printable encoding, care must be taken, when encapsulating a
- quoted-printable encoded body in a multipart entity, to ensure that
- the encapsulation boundary does not appear anywhere in the encoded
- body. (A good strategy is to choose a boundary that includes a
- character sequence such as "=_" which can never appear in a quoted-
- printable body. See the definition of multipart messages later in
- this document.)
-
- NOTE: The quoted-printable encoding represents something of a
- compromise between readability and reliability in transport.
- Bodies encoded with the quoted-printable encoding will work
- reliably over most mail gateways, but may not work perfectly over
- a few gateways, notably those involving translation into EBCDIC.
- (In theory, an EBCDIC gateway could decode a quoted-printable body
- and re-encode it using base64, but such gateways do not yet
- exist.) A higher level of confidence is offered by the base64
- Content-Transfer-Encoding. A way to get reasonably reliable
- transport through EBCDIC gateways is to also quote the ASCII
- characters
-
- !"#$@[\]^`{|}~
-
- according to rule #1. See Appendix B for more information.
-
- Because quoted-printable data is generally assumed to be line-
- oriented, it is to be expected that the representation of the breaks
- between the lines of quoted printable data may be altered in
- transport, in the same manner that plain text mail has always been
- altered in Internet mail when passing between systems with differing
- newline conventions. If such alterations are likely to constitute a
- corruption of the data, it is probably more sensible to use the
- base64 encoding rather than the quoted-printable encoding.
-
- WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-
- printable, care must be taken to encode CR and LF characters as "=0D"
- and "=0A", respectively. In particular, a CRLF sequence in binary
- data should be encoded as "=0D=0A". Otherwise, if CRLF were
- represented as a hard line break, it might be incorrectly decoded on
-
-
-
-Borenstein & Freed [Page 20]
-
-RFC 1521 MIME September 1993
-
-
- platforms with different line break conventions.
-
- For formalists, the syntax of quoted-printable data is described by
- the following grammar:
-
- quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
- ; Maximum line length of 76 characters excluding CRLF
-
- ptext := octet /<any ASCII character except "=", SPACE, or TAB>
- ; characters not listed as "mail-safe" in Appendix B
- ; are also not recommended.
-
- octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
- ; octet must be used for characters > 127, =, SPACE, or TAB,
- ; and is recommended for any characters not listed in
- ; Appendix B as "mail-safe".
-
-5.2. Base64 Content-Transfer-Encoding
-
- The Base64 Content-Transfer-Encoding is designed to represent
- arbitrary sequences of octets in a form that need not be humanly
- readable. The encoding and decoding algorithms are simple, but the
- encoded data are consistently only about 33 percent larger than the
- unencoded data. This encoding is virtually identical to the one used
- in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.
- The base64 encoding is adapted from RFC 1421, with one change: base64
- eliminates the "*" mechanism for embedded clear text.
-
- A 65-character subset of US-ASCII is used, enabling 6 bits to be
- represented per printable character. (The extra 65th character, "=",
- is used to signify a special processing function.)
-
- NOTE: This subset has the important property that it is
- represented identically in all versions of ISO 646, including US
- ASCII, and all characters in the subset are also represented
- identically in all versions of EBCDIC. Other popular encodings,
- such as the encoding used by the uuencode utility and the base85
- encoding specified as part of Level 2 PostScript, do not share
- these properties, and thus do not fulfill the portability
- requirements a binary transport encoding for mail must meet.
-
- The encoding process represents 24-bit groups of input bits as output
- strings of 4 encoded characters. Proceeding from left to right, a
- 24-bit input group is formed by concatenating 3 8-bit input groups.
- These 24 bits are then treated as 4 concatenated 6-bit groups, each
- of which is translated into a single digit in the base64 alphabet.
- When encoding a bit stream via the base64 encoding, the bit stream
- must be presumed to be ordered with the most-significant-bit first.
-
-
-
-Borenstein & Freed [Page 21]
-
-RFC 1521 MIME September 1993
-
-
- That is, the first bit in the stream will be the high-order bit in
- the first byte, and the eighth bit will be the low-order bit in the
- first byte, and so on.
-
- Each 6-bit group is used as an index into an array of 64 printable
- characters. The character referenced by the index is placed in the
- output string. These characters, identified in Table 1, below, are
- selected so as to be universally representable, and the set excludes
- characters with particular significance to SMTP (e.g., ".", CR, LF)
- and to the encapsulation boundaries defined in this document (e.g.,
- "-").
-
- Table 1: The Base64 Alphabet
-
- Value Encoding Value Encoding Value Encoding Value Encoding
- 0 A 17 R 34 i 51 z
- 1 B 18 S 35 j 52 0
- 2 C 19 T 36 k 53 1
- 3 D 20 U 37 l 54 2
- 4 E 21 V 38 m 55 3
- 5 F 22 W 39 n 56 4
- 6 G 23 X 40 o 57 5
- 7 H 24 Y 41 p 58 6
- 8 I 25 Z 42 q 59 7
- 9 J 26 a 43 r 60 8
- 10 K 27 b 44 s 61 9
- 11 L 28 c 45 t 62 +
- 12 M 29 d 46 u 63 /
- 13 N 30 e 47 v
- 14 O 31 f 48 w (pad) =
- 15 P 32 g 49 x
- 16 Q 33 h 50 y
-
- The output stream (encoded bytes) must be represented in lines of no
- more than 76 characters each. All line breaks or other characters
- not found in Table 1 must be ignored by decoding software. In base64
- data, characters other than those in Table 1, line breaks, and other
- white space probably indicate a transmission error, about which a
- warning message or even a message rejection might be appropriate
- under some circumstances.
-
- Special processing is performed if fewer than 24 bits are available
- at the end of the data being encoded. A full encoding quantum is
- always completed at the end of a body. When fewer than 24 input bits
- are available in an input group, zero bits are added (on the right)
- to form an integral number of 6-bit groups. Padding at the end of
- the data is performed using the '=' character. Since all base64
- input is an integral number of octets, only the following cases can
-
-
-
-Borenstein & Freed [Page 22]
-
-RFC 1521 MIME September 1993
-
-
- arise: (1) the final quantum of encoding input is an integral
- multiple of 24 bits; here, the final unit of encoded output will be
- an integral multiple of 4 characters with no "=" padding, (2) the
- final quantum of encoding input is exactly 8 bits; here, the final
- unit of encoded output will be two characters followed by two "="
- padding characters, or (3) the final quantum of encoding input is
- exactly 16 bits; here, the final unit of encoded output will be three
- characters followed by one "=" padding character.
-
- Because it is used only for padding at the end of the data, the
- occurrence of any '=' characters may be taken as evidence that the
- end of the data has been reached (without truncation in transit). No
- such assurance is possible, however, when the number of octets
- transmitted was a multiple of three.
-
- Any characters outside of the base64 alphabet are to be ignored in
- base64-encoded data. The same applies to any illegal sequence of
- characters in the base64 encoding, such as "====="
-
- Care must be taken to use the proper octets for line breaks if base64
- encoding is applied directly to text material that has not been
- converted to canonical form. In particular, text line breaks must be
- converted into CRLF sequences prior to base64 encoding. The important
- thing to note is that this may be done directly by the encoder rather
- than in a prior canonicalization step in some implementations.
-
- NOTE: There is no need to worry about quoting apparent
- encapsulation boundaries within base64-encoded parts of multipart
- entities because no hyphen characters are used in the base64
- encoding.
-
-6. Additional Content-Header Fields
-
-6.1. Optional Content-ID Header Field
-
- In constructing a high-level user agent, it may be desirable to allow
- one body to make reference to another. Accordingly, bodies may be
- labeled using the "Content-ID" header field, which is syntactically
- identical to the "Message-ID" header field:
-
- id := "Content-ID" ":" msg-id
- Like the Message-ID values, Content-ID values must be generated to be
- world-unique.
-
- The Content-ID value may be used for uniquely identifying MIME
- entities in several contexts, particularly for cacheing data
- referenced by the message/external-body mechanism. Although the
- Content-ID header is generally optional, its use is mandatory in
-
-
-
-Borenstein & Freed [Page 23]
-
-RFC 1521 MIME September 1993
-
-
- implementations which generate data of the optional MIME Content-type
- "message/external-body". That is, each message/external-body entity
- must have a Content-ID field to permit cacheing of such data.
-
- It is also worth noting that the Content-ID value has special
- semantics in the case of the multipart/alternative content-type.
- This is explained in the section of this document dealing with
- multipart/alternative.
-
-6.2. Optional Content-Description Header Field
-
- The ability to associate some descriptive information with a given
- body is often desirable. For example, it may be useful to mark an
- "image" body as "a picture of the Space Shuttle Endeavor." Such text
- may be placed in the Content-Description header field.
-
- description := "Content-Description" ":" *text
-
- The description is presumed to be given in the US-ASCII character
- set, although the mechanism specified in [RFC-1522] may be used for
- non-US-ASCII Content-Description values.
-
-7. The Predefined Content-Type Values
-
- This document defines seven initial Content-Type values and an
- extension mechanism for private or experimental types. Further
- standard types must be defined by new published specifications. It
- is expected that most innovation in new types of mail will take place
- as subtypes of the seven types defined here. The most essential
- characteristics of the seven content-types are summarized in Appendix
- F.
-
-7.1 The Text Content-Type
-
- The text Content-Type is intended for sending material which is
- principally textual in form. It is the default Content-Type. A
- "charset" parameter may be used to indicate the character set of the
- body text for some text subtypes, notably including the primary
- subtype, "text/plain", which indicates plain (unformatted) text. The
- default Content-Type for Internet mail is "text/plain; charset=us-
- ascii".
-
- Beyond plain text, there are many formats for representing what might
- be known as "extended text" -- text with embedded formatting and
- presentation information. An interesting characteristic of many such
- representations is that they are to some extent readable even without
- the software that interprets them. It is useful, then, to
- distinguish them, at the highest level, from such unreadable data as
-
-
-
-Borenstein & Freed [Page 24]
-
-RFC 1521 MIME September 1993
-
-
- images, audio, or text represented in an unreadable form. In the
- absence of appropriate interpretation software, it is reasonable to
- show subtypes of text to the user, while it is not reasonable to do
- so with most nontextual data.
-
- Such formatted textual data should be represented using subtypes of
- text. Plausible subtypes of text are typically given by the common
- name of the representation format, e.g., "text/richtext" [RFC-1341].
-
-7.1.1. The charset parameter
-
- A critical parameter that may be specified in the Content-Type field
- for text/plain data is the character set. This is specified with a
- "charset" parameter, as in:
-
- Content-type: text/plain; charset=us-ascii
-
- Unlike some other parameter values, the values of the charset
- parameter are NOT case sensitive. The default character set, which
- must be assumed in the absence of a charset parameter, is US-ASCII.
-
- The specification for any future subtypes of "text" must specify
- whether or not they will also utilize a "charset" parameter, and may
- possibly restrict its values as well. When used with a particular
- body, the semantics of the "charset" parameter should be identical to
- those specified here for "text/plain", i.e., the body consists
- entirely of characters in the given charset. In particular, definers
- of future text subtypes should pay close attention the the
- implications of multibyte character sets for their subtype
- definitions.
-
- This RFC specifies the definition of the charset parameter for the
- purposes of MIME to be a unique mapping of a byte stream to glyphs, a
- mapping which does not require external profiling information.
-
- An initial list of predefined character set names can be found at the
- end of this section. Additional character sets may be registered
- with IANA, although the standardization of their use requires the
- usual IESG [RFC-1340] review and approval. Note that if the
- specified character set includes 8-bit data, a Content-Transfer-
- Encoding header field and a corresponding encoding on the data are
- required in order to transmit the body via some mail transfer
- protocols, such as SMTP.
-
- The default character set, US-ASCII, has been the subject of some
- confusion and ambiguity in the past. Not only were there some
- ambiguities in the definition, there have been wide variations in
- practice. In order to eliminate such ambiguity and variations in the
-
-
-
-Borenstein & Freed [Page 25]
-
-RFC 1521 MIME September 1993
-
-
- future, it is strongly recommended that new user agents explicitly
- specify a character set via the Content-Type header field. "US-
- ASCII" does not indicate an arbitrary seven-bit character code, but
- specifies that the body uses character coding that uses the exact
- correspondence of codes to characters specified in ASCII. National
- use variations of ISO 646 [ISO-646] are NOT ASCII and their use in
- Internet mail is explicitly discouraged. The omission of the ISO 646
- character set is deliberate in this regard. The character set name
- of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.
- The character set name "ASCII" is reserved and must not be used for
- any purpose.
-
- NOTE: RFC 821 explicitly specifies "ASCII", and references an
- earlier version of the American Standard. Insofar as one of the
- purposes of specifying a Content-Type and character set is to
- permit the receiver to unambiguously determine how the sender
- intended the coded message to be interpreted, assuming anything
- other than "strict ASCII" as the default would risk unintentional
- and incompatible changes to the semantics of messages now being
- transmitted. This also implies that messages containing
- characters coded according to national variations on ISO 646, or
- using code-switching procedures (e.g., those of ISO 2022), as well
- as 8-bit or multiple octet character encodings MUST use an
- appropriate character set specification to be consistent with this
- specification.
-
- The complete US-ASCII character set is listed in [US-ASCII]. Note
- that the control characters including DEL (0-31, 127) have no defined
- meaning apart from the combination CRLF (ASCII values 13 and 10)
- indicating a new line. Two of the characters have de facto meanings
- in wide use: FF (12) often means "start subsequent text on the
- beginning of a new page"; and TAB or HT (9) often (though not always)
- means "move the cursor to the next available column after the current
- position where the column number is a multiple of 8 (counting the
- first column as column 0)." Apart from this, any use of the control
- characters or DEL in a body must be part of a private agreement
- between the sender and recipient. Such private agreements are
- discouraged and should be replaced by the other capabilities of this
- document.
-
- NOTE: Beyond US-ASCII, an enormous proliferation of character sets
- is possible. It is the opinion of the IETF working group that a
- large number of character sets is NOT a good thing. We would
- prefer to specify a single character set that can be used
- universally for representing all of the world's languages in
- electronic mail. Unfortunately, existing practice in several
- communities seems to point to the continued use of multiple
- character sets in the near future. For this reason, we define
-
-
-
-Borenstein & Freed [Page 26]
-
-RFC 1521 MIME September 1993
-
-
- names for a small number of character sets for which a strong
- constituent base exists.
-
- The defined charset values are:
-
- US-ASCII -- as defined in [US-ASCII].
-
- ISO-8859-X -- where "X" is to be replaced, as necessary, for the
- parts of ISO-8859 [ISO-8859]. Note that the ISO 646
- character sets have deliberately been omitted in favor of
- their 8859 replacements, which are the designated character
- sets for Internet mail. As of the publication of this
- document, the legitimate values for "X" are the digits 1
- through 9.
-
- The character sets specified above are the ones that were relatively
- uncontroversial during the drafting of MIME. This document does not
- endorse the use of any particular character set other than US-ASCII,
- and recognizes that the future evolution of world character sets
- remains unclear. It is expected that in the future, additional
- character sets will be registered for use in MIME.
-
- Note that the character set used, if anything other than US-ASCII,
- must always be explicitly specified in the Content-Type field.
-
- No other character set name may be used in Internet mail without the
- publication of a formal specification and its registration with IANA,
- or by private agreement, in which case the character set name must
- begin with "X-".
-
- Implementors are discouraged from defining new character sets for
- mail use unless absolutely necessary.
-
- The "charset" parameter has been defined primarily for the purpose of
- textual data, and is described in this section for that reason.
- However, it is conceivable that non-textual data might also wish to
- specify a charset value for some purpose, in which case the same
- syntax and values should be used.
-
- In general, mail-sending software must always use the "lowest common
- denominator" character set possible. For example, if a body contains
- only US-ASCII characters, it must be marked as being in the US-ASCII
- character set, not ISO-8859-1, which, like all the ISO-8859 family of
- character sets, is a superset of US-ASCII. More generally, if a
- widely-used character set is a subset of another character set, and a
- body contains only characters in the widely-used subset, it must be
- labeled as being in that subset. This will increase the chances that
- the recipient will be able to view the mail correctly.
-
-
-
-Borenstein & Freed [Page 27]
-
-RFC 1521 MIME September 1993
-
-
-7.1.2. The Text/plain subtype
-
- The primary subtype of text is "plain". This indicates plain
- (unformatted) text. The default Content-Type for Internet mail,
- "text/plain; charset=us-ascii", describes existing Internet practice.
- That is, it is the type of body defined by RFC 822.
-
- No other text subtype is defined by this document.
-
- The formal grammar for the content-type header field for text is as
- follows:
-
- text-type := "text" "/" text-subtype [";" "charset" "=" charset]
-
- text-subtype := "plain" / extension-token
-
- charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"
- / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"
- / "iso-8859-8" / "iso-8859-9" / extension-token
- ; case insensitive
-
-7.2. The Multipart Content-Type
-
- In the case of multiple part entities, in which one or more different
- sets of data are combined in a single body, a "multipart" Content-
- Type field must appear in the entity's header. The body must then
- contain one or more "body parts," each preceded by an encapsulation
- boundary, and the last one followed by a closing boundary. Each part
- starts with an encapsulation boundary, and then contains a body part
- consisting of header area, a blank line, and a body area. Thus a
- body part is similar to an RFC 822 message in syntax, but different
- in meaning.
-
- A body part is NOT to be interpreted as actually being an RFC 822
- message. To begin with, NO header fields are actually required in
- body parts. A body part that starts with a blank line, therefore, is
- allowed and is a body part for which all default values are to be
- assumed. In such a case, the absence of a Content-Type header field
- implies that the corresponding body is plain US-ASCII text. The only
- header fields that have defined meaning for body parts are those the
- names of which begin with "Content-". All other header fields are
- generally to be ignored in body parts. Although they should
- generally be retained in mail processing, they may be discarded by
- gateways if necessary. Such other fields are permitted to appear in
- body parts but must not be depended on. "X-" fields may be created
- for experimental or private purposes, with the recognition that the
- information they contain may be lost at some gateways.
-
-
-
-
-Borenstein & Freed [Page 28]
-
-RFC 1521 MIME September 1993
-
-
- NOTE: The distinction between an RFC 822 message and a body part
- is subtle, but important. A gateway between Internet and X.400
- mail, for example, must be able to tell the difference between a
- body part that contains an image and a body part that contains an
- encapsulated message, the body of which is an image. In order to
- represent the latter, the body part must have "Content-Type:
- message", and its body (after the blank line) must be the
- encapsulated message, with its own "Content-Type: image" header
- field. The use of similar syntax facilitates the conversion of
- messages to body parts, and vice versa, but the distinction
- between the two must be understood by implementors. (For the
- special case in which all parts actually are messages, a "digest"
- subtype is also defined.)
-
- As stated previously, each body part is preceded by an encapsulation
- boundary. The encapsulation boundary MUST NOT appear inside any of
- the encapsulated parts. Thus, it is crucial that the composing agent
- be able to choose and specify the unique boundary that will separate
- the parts.
-
- All present and future subtypes of the "multipart" type must use an
- identical syntax. Subtypes may differ in their semantics, and may
- impose additional restrictions on syntax, but must conform to the
- required syntax for the multipart type. This requirement ensures
- that all conformant user agents will at least be able to recognize
- and separate the parts of any multipart entity, even of an
- unrecognized subtype.
-
- As stated in the definition of the Content-Transfer-Encoding field,
- no encoding other than "7bit", "8bit", or "binary" is permitted for
- entities of type "multipart". The multipart delimiters and header
- fields are always represented as 7-bit ASCII in any case (though the
- header fields may encode non-ASCII header text as per [RFC-1522]),
- and data within the body parts can be encoded on a part-by-part
- basis, with Content-Transfer-Encoding fields for each appropriate
- body part.
-
- Mail gateways, relays, and other mail handling agents are commonly
- known to alter the top-level header of an RFC 822 message. In
- particular, they frequently add, remove, or reorder header fields.
- Such alterations are explicitly forbidden for the body part headers
- embedded in the bodies of messages of type "multipart."
-
-7.2.1. Multipart: The common syntax
-
- All subtypes of "multipart" share a common syntax, defined in this
- section. A simple example of a multipart message also appears in
- this section. An example of a more complex multipart message is
-
-
-
-Borenstein & Freed [Page 29]
-
-RFC 1521 MIME September 1993
-
-
- given in Appendix C.
-
- The Content-Type field for multipart entities requires one parameter,
- "boundary", which is used to specify the encapsulation boundary. The
- encapsulation boundary is defined as a line consisting entirely of
- two hyphen characters ("-", decimal code 45) followed by the boundary
- parameter value from the Content-Type header field.
-
- NOTE: The hyphens are for rough compatibility with the earlier RFC
- 934 method of message encapsulation, and for ease of searching for
- the boundaries in some implementations. However, it should be
- noted that multipart messages are NOT completely compatible with
- RFC 934 encapsulations; in particular, they do not obey RFC 934
- quoting conventions for embedded lines that begin with hyphens.
- This mechanism was chosen over the RFC 934 mechanism because the
- latter causes lines to grow with each level of quoting. The
- combination of this growth with the fact that SMTP implementations
- sometimes wrap long lines made the RFC 934 mechanism unsuitable
- for use in the event that deeply-nested multipart structuring is
- ever desired.
-
- WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-
- type field is such that it is often necessary to enclose the
- boundaries in quotes on the Content-type line. This is not always
- necessary, but never hurts. Implementors should be sure to study the
- grammar carefully in order to avoid producing illegal Content-type
- fields. Thus, a typical multipart Content-Type header field might
- look like this:
-
- Content-Type: multipart/mixed;
- boundary=gc0p4Jq0M2Yt08jU534c0p
-
- But the following is illegal:
-
- Content-Type: multipart/mixed;
- boundary=gc0p4Jq0M:2Yt08jU534c0p
-
- (because of the colon) and must instead be represented as
-
- Content-Type: multipart/mixed;
- boundary="gc0p4Jq0M:2Yt08jU534c0p"
-
- This indicates that the entity consists of several parts, each itself
- with a structure that is syntactically identical to an RFC 822
- message, except that the header area might be completely empty, and
- that the parts are each preceded by the line
-
- --gc0p4Jq0M:2Yt08jU534c0p
-
-
-
-Borenstein & Freed [Page 30]
-
-RFC 1521 MIME September 1993
-
-
- Note that the encapsulation boundary must occur at the beginning of a
- line, i.e., following a CRLF, and that the initial CRLF is considered
- to be attached to the encapsulation boundary rather than part of the
- preceding part. The boundary must be followed immediately either by
- another CRLF and the header fields for the next part, or by two
- CRLFs, in which case there are no header fields for the next part
- (and it is therefore assumed to be of Content-Type text/plain).
-
- NOTE: The CRLF preceding the encapsulation line is conceptually
- attached to the boundary so that it is possible to have a part
- that does not end with a CRLF (line break). Body parts that must
- be considered to end with line breaks, therefore, must have two
- CRLFs preceding the encapsulation line, the first of which is part
- of the preceding body part, and the second of which is part of the
- encapsulation boundary.
-
- Encapsulation boundaries must not appear within the encapsulations,
- and must be no longer than 70 characters, not counting the two
- leading hyphens.
-
- The encapsulation boundary following the last body part is a
- distinguished delimiter that indicates that no further body parts
- will follow. Such a delimiter is identical to the previous
- delimiters, with the addition of two more hyphens at the end of the
- line:
-
- --gc0p4Jq0M2Yt08jU534c0p--
-
- There appears to be room for additional information prior to the
- first encapsulation boundary and following the final boundary. These
- areas should generally be left blank, and implementations must ignore
- anything that appears before the first boundary or after the last
- one.
-
- NOTE: These "preamble" and "epilogue" areas are generally not used
- because of the lack of proper typing of these parts and the lack
- of clear semantics for handling these areas at gateways,
- particularly X.400 gateways. However, rather than leaving the
- preamble area blank, many MIME implementations have found this to
- be a convenient place to insert an explanatory note for recipients
- who read the message with pre-MIME software, since such notes will
- be ignored by MIME-compliant software.
-
- NOTE: Because encapsulation boundaries must not appear in the body
- parts being encapsulated, a user agent must exercise care to
- choose a unique boundary. The boundary in the example above could
- have been the result of an algorithm designed to produce
- boundaries with a very low probability of already existing in the
-
-
-
-Borenstein & Freed [Page 31]
-
-RFC 1521 MIME September 1993
-
-
- data to be encapsulated without having to prescan the data.
- Alternate algorithms might result in more 'readable' boundaries
- for a recipient with an old user agent, but would require more
- attention to the possibility that the boundary might appear in the
- encapsulated part. The simplest boundary possible is something
- like "---", with a closing boundary of "-----".
-
- As a very simple example, the following multipart message has two
- parts, both of them plain text, one of them explicitly typed and one
- of them implicitly typed:
-
- From: Nathaniel Borenstein <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- Subject: Sample message
- MIME-Version: 1.0
- Content-type: multipart/mixed; boundary="simple
- boundary"
-
- This is the preamble. It is to be ignored, though it
- is a handy place for mail composers to include an
- explanatory note to non-MIME conformant readers.
- --simple boundary
-
- This is implicitly typed plain ASCII text.
- It does NOT end with a linebreak.
- --simple boundary
- Content-type: text/plain; charset=us-ascii
-
- This is explicitly typed plain ASCII text.
- It DOES end with a linebreak.
-
- --simple boundary--
- This is the epilogue. It is also to be ignored.
-
- The use of a Content-Type of multipart in a body part within another
- multipart entity is explicitly allowed. In such cases, for obvious
- reasons, care must be taken to ensure that each nested multipart
- entity must use a different boundary delimiter. See Appendix C for an
- example of nested multipart entities.
-
- The use of the multipart Content-Type with only a single body part
- may be useful in certain contexts, and is explicitly permitted.
-
- The only mandatory parameter for the multipart Content-Type is the
- boundary parameter, which consists of 1 to 70 characters from a set
- of characters known to be very robust through email gateways, and NOT
- ending with white space. (If a boundary appears to end with white
- space, the white space must be presumed to have been added by a
-
-
-
-Borenstein & Freed [Page 32]
-
-RFC 1521 MIME September 1993
-
-
- gateway, and must be deleted.) It is formally specified by the
- following BNF:
-
- boundary := 0*69<bchars> bcharsnospace
-
- bchars := bcharsnospace / " "
-
- bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"
- / "," / "-" / "." / "/" / ":" / "=" / "?"
-
- Overall, the body of a multipart entity may be specified as
- follows:
-
- multipart-body := preamble 1*encapsulation
- close-delimiter epilogue
-
- encapsulation := delimiter body-part CRLF
-
- delimiter := "--" boundary CRLF ; taken from Content-Type field.
- ; There must be no space
- ; between "--" and boundary.
-
- close-delimiter := "--" boundary "--" CRLF ; Again, no space
- by "--",
-
- preamble := discard-text ; to be ignored upon receipt.
-
- epilogue := discard-text ; to be ignored upon receipt.
-
- discard-text := *(*text CRLF)
-
- body-part := <"message" as defined in RFC 822,
- with all header fields optional, and with the
- specified delimiter not occurring anywhere in
- the message body, either on a line by itself
- or as a substring anywhere. Note that the
- semantics of a part differ from the semantics
- of a message, as described in the text.>
-
- NOTE: In certain transport enclaves, RFC 822 restrictions such as
- the one that limits bodies to printable ASCII characters may not
- be in force. (That is, the transport domains may resemble
- standard Internet mail transport as specified in RFC821 and
- assumed by RFC822, but without certain restrictions.) The
- relaxation of these restrictions should be construed as locally
- extending the definition of bodies, for example to include octets
- outside of the ASCII range, as long as these extensions are
- supported by the transport and adequately documented in the
-
-
-
-Borenstein & Freed [Page 33]
-
-RFC 1521 MIME September 1993
-
-
- Content-Transfer-Encoding header field. However, in no event are
- headers (either message headers or body-part headers) allowed to
- contain anything other than ASCII characters.
-
- NOTE: Conspicuously missing from the multipart type is a notion of
- structured, related body parts. In general, it seems premature to
- try to standardize interpart structure yet. It is recommended
- that those wishing to provide a more structured or integrated
- multipart messaging facility should define a subtype of multipart
- that is syntactically identical, but that always expects the
- inclusion of a distinguished part that can be used to specify the
- structure and integration of the other parts, probably referring
- to them by their Content-ID field. If this approach is used,
- other implementations will not recognize the new subtype, but will
- treat it as the primary subtype (multipart/mixed) and will thus be
- able to show the user the parts that are recognized.
-
-7.2.2. The Multipart/mixed (primary) subtype
-
- The primary subtype for multipart, "mixed", is intended for use when
- the body parts are independent and need to be bundled in a particular
- order. Any multipart subtypes that an implementation does not
- recognize must be treated as being of subtype "mixed".
-
-7.2.3. The Multipart/alternative subtype
-
- The multipart/alternative type is syntactically identical to
- multipart/mixed, but the semantics are different. In particular,
- each of the parts is an "alternative" version of the same
- information.
-
- Systems should recognize that the content of the various parts are
- interchangeable. Systems should choose the "best" type based on the
- local environment and preferences, in some cases even through user
- interaction. As with multipart/mixed, the order of body parts is
- significant. In this case, the alternatives appear in an order of
- increasing faithfulness to the original content. In general, the best
- choice is the LAST part of a type supported by the recipient system's
- local environment.
-
- Multipart/alternative may be used, for example, to send mail in a
- fancy text format in such a way that it can easily be displayed
- anywhere:
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 34]
-
-RFC 1521 MIME September 1993
-
-
- From: Nathaniel Borenstein <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- Subject: Formatted text mail
- MIME-Version: 1.0
- Content-Type: multipart/alternative; boundary=boundary42
-
- --boundary42
-
- Content-Type: text/plain; charset=us-ascii
-
- ...plain text version of message goes here....
- --boundary42
- Content-Type: text/richtext
-
- .... RFC 1341 richtext version of same message goes here ...
- --boundary42
- Content-Type: text/x-whatever
-
- .... fanciest formatted version of same message goes here
- ...
- --boundary42--
-
- In this example, users whose mail system understood the "text/x-
- whatever" format would see only the fancy version, while other users
- would see only the richtext or plain text version, depending on the
- capabilities of their system.
-
- In general, user agents that compose multipart/alternative entities
- must place the body parts in increasing order of preference, that is,
- with the preferred format last. For fancy text, the sending user
- agent should put the plainest format first and the richest format
- last. Receiving user agents should pick and display the last format
- they are capable of displaying. In the case where one of the
- alternatives is itself of type "multipart" and contains unrecognized
- sub-parts, the user agent may choose either to show that alternative,
- an earlier alternative, or both.
-
- NOTE: From an implementor's perspective, it might seem more
- sensible to reverse this ordering, and have the plainest
- alternative last. However, placing the plainest alternative first
- is the friendliest possible option when multipart/alternative
- entities are viewed using a non-MIME-conformant mail reader.
- While this approach does impose some burden on conformant mail
- readers, interoperability with older mail readers was deemed to be
- more important in this case.
-
- It may be the case that some user agents, if they can recognize more
- than one of the formats, will prefer to offer the user the choice of
-
-
-
-Borenstein & Freed [Page 35]
-
-RFC 1521 MIME September 1993
-
-
- which format to view. This makes sense, for example, if mail
- includes both a nicely-formatted image version and an easily-edited
- text version. What is most critical, however, is that the user not
- automatically be shown multiple versions of the same data. Either
- the user should be shown the last recognized version or should be
- given the choice.
-
- NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each
- part of a multipart/alternative entity represents the same data, but
- the mappings between the two are not necessarily without information
- loss. For example, information is lost when translating ODA to
- PostScript or plain text. It is recommended that each part should
- have a different Content-ID value in the case where the information
- content of the two parts is not identical. However, where the
- information content is identical -- for example, where several parts
- of type "application/external- body" specify alternate ways to access
- the identical data -- the same Content-ID field value should be used,
- to optimize any cacheing mechanisms that might be present on the
- recipient's end. However, it is recommended that the Content-ID
- values used by the parts should not be the same Content-ID value that
- describes the multipart/alternative as a whole, if there is any such
- Content-ID field. That is, one Content-ID value will refer to the
- multipart/alternative entity, while one or more other Content-ID
- values will refer to the parts inside it.
-
-7.2.4. The Multipart/digest subtype
-
- This document defines a "digest" subtype of the multipart Content-
- Type. This type is syntactically identical to multipart/mixed, but
- the semantics are different. In particular, in a digest, the default
- Content-Type value for a body part is changed from "text/plain" to
- "message/rfc822". This is done to allow a more readable digest
- format that is largely compatible (except for the quoting convention)
- with RFC 934.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 36]
-
-RFC 1521 MIME September 1993
-
-
- A digest in this format might, then, look something like this:
-
- From: Moderator-Address
- To: Recipient-List
- MIME-Version: 1.0
- Subject: Internet Digest, volume 42
- Content-Type: multipart/digest;
- boundary="---- next message ----"
-
- ------ next message ----
-
- From: someone-else
- Subject: my opinion
-
- ...body goes here ...
-
- ------ next message ----
-
- From: someone-else-again
- Subject: my different opinion
-
- ... another body goes here...
-
- ------ next message ------
-
-7.2.5. The Multipart/parallel subtype
-
- This document defines a "parallel" subtype of the multipart Content-
- Type. This type is syntactically identical to multipart/mixed, but
- the semantics are different. In particular, in a parallel entity,
- the order of body parts is not significant.
-
- A common presentation of this type is to display all of the parts
- simultaneously on hardware and software that are capable of doing so.
- However, composing agents should be aware that many mail readers will
- lack this capability and will show the parts serially in any event.
-
-7.2.6. Other Multipart subtypes
-
- Other multipart subtypes are expected in the future. MIME
- implementations must in general treat unrecognized subtypes of
- multipart as being equivalent to "multipart/mixed".
-
- The formal grammar for content-type header fields for multipart data
- is given by:
-
- multipart-type := "multipart" "/" multipart-subtype
- ";" "boundary" "=" boundary
-
-
-
-Borenstein & Freed [Page 37]
-
-RFC 1521 MIME September 1993
-
-
- multipart-subtype := "mixed" / "parallel" / "digest"
- / "alternative" / extension-token
-
-7.3. The Message Content-Type
-
- It is frequently desirable, in sending mail, to encapsulate another
- mail message. For this common operation, a special Content-Type,
- "message", is defined. The primary subtype, message/rfc822, has no
- required parameters in the Content-Type field. Additional subtypes,
- "partial" and "External-body", do have required parameters. These
- subtypes are explained below.
-
- NOTE: It has been suggested that subtypes of message might be
- defined for forwarded or rejected messages. However, forwarded
- and rejected messages can be handled as multipart messages in
- which the first part contains any control or descriptive
- information, and a second part, of type message/rfc822, is the
- forwarded or rejected message. Composing rejection and forwarding
- messages in this manner will preserve the type information on the
- original message and allow it to be correctly presented to the
- recipient, and hence is strongly encouraged.
-
- As stated in the definition of the Content-Transfer-Encoding field,
- no encoding other than "7bit", "8bit", or "binary" is permitted for
- messages or parts of type "message". Even stronger restrictions
- apply to the subtypes "message/partial" and "message/external-body",
- as specified below. The message header fields are always US-ASCII in
- any case, and data within the body can still be encoded, in which
- case the Content-Transfer-Encoding header field in the encapsulated
- message will reflect this. Non-ASCII text in the headers of an
- encapsulated message can be specified using the mechanisms described
- in [RFC-1522].
-
- Mail gateways, relays, and other mail handling agents are commonly
- known to alter the top-level header of an RFC 822 message. In
- particular, they frequently add, remove, or reorder header fields.
- Such alterations are explicitly forbidden for the encapsulated
- headers embedded in the bodies of messages of type "message."
-
-7.3.1. The Message/rfc822 (primary) subtype
-
- A Content-Type of "message/rfc822" indicates that the body contains
- an encapsulated message, with the syntax of an RFC 822 message.
- However, unlike top-level RFC 822 messages, it is not required that
- each message/rfc822 body must include a "From", "Subject", and at
- least one destination header.
-
- It should be noted that, despite the use of the numbers "822", a
-
-
-
-Borenstein & Freed [Page 38]
-
-RFC 1521 MIME September 1993
-
-
- message/rfc822 entity can include enhanced information as defined in
- this document. In other words, a message/rfc822 message may be a
- MIME message.
-
-7.3.2. The Message/Partial subtype
-
- A subtype of message, "partial", is defined in order to allow large
- objects to be delivered as several separate pieces of mail and
- automatically reassembled by the receiving user agent. (The concept
- is similar to IP fragmentation/reassembly in the basic Internet
- Protocols.) This mechanism can be used when intermediate transport
- agents limit the size of individual messages that can be sent.
- Content-Type "message/partial" thus indicates that the body contains
- a fragment of a larger message.
-
- Three parameters must be specified in the Content-Type field of type
- message/partial: The first, "id", is a unique identifier, as close to
- a world-unique identifier as possible, to be used to match the parts
- together. (In general, the identifier is essentially a message-id;
- if placed in double quotes, it can be any message-id, in accordance
- with the BNF for "parameter" given earlier in this specification.)
- The second, "number", an integer, is the part number, which indicates
- where this part fits into the sequence of fragments. The third,
- "total", another integer, is the total number of parts. This third
- subfield is required on the final part, and is optional (though
- encouraged) on the earlier parts. Note also that these parameters
- may be given in any order.
-
- Thus, part 2 of a 3-part message may have either of the following
- header fields:
-
- Content-Type: Message/Partial;
- number=2; total=3;
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
-
- Content-Type: Message/Partial;
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
- number=2
-
- But part 3 MUST specify the total number of parts:
-
- Content-Type: Message/Partial;
- number=3; total=3;
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
-
- Note that part numbering begins with 1, not 0.
-
- When the parts of a message broken up in this manner are put
-
-
-
-Borenstein & Freed [Page 39]
-
-RFC 1521 MIME September 1993
-
-
- together, the result is a complete MIME entity, which may have its
- own Content-Type header field, and thus may contain any other data
- type.
-
- Message fragmentation and reassembly: The semantics of a reassembled
- partial message must be those of the "inner" message, rather than of
- a message containing the inner message. This makes it possible, for
- example, to send a large audio message as several partial messages,
- and still have it appear to the recipient as a simple audio message
- rather than as an encapsulated message containing an audio message.
- That is, the encapsulation of the message is considered to be
- "transparent".
-
- When generating and reassembling the parts of a message/partial
- message, the headers of the encapsulated message must be merged with
- the headers of the enclosing entities. In this process the following
- rules must be observed:
-
- (1) All of the header fields from the initial enclosing entity
- (part one), except those that start with "Content-" and the
- specific header fields "Message-ID", "Encrypted", and "MIME-
- Version", must be copied, in order, to the new message.
-
- (2) Only those header fields in the enclosed message which start
- with "Content-" and "Message-ID", "Encrypted", and "MIME-Version"
- must be appended, in order, to the header fields of the new
- message. Any header fields in the enclosed message which do not
- start with "Content-" (except for "Message-ID", "Encrypted", and
- "MIME-Version") will be ignored.
-
- (3) All of the header fields from the second and any subsequent
- messages will be ignored.
-
- For example, if an audio message is broken into two parts, the first
- part might look something like this:
-
- X-Weird-Header-1: Foo
- From: Bill@host.com
- To: joe@otherhost.com
- Subject: Audio mail
- Message-ID: <id1@host.com>
- MIME-Version: 1.0
- Content-type: message/partial;
- id="ABC@host.com";
- number=1; total=2
-
- X-Weird-Header-1: Bar
- X-Weird-Header-2: Hello
-
-
-
-Borenstein & Freed [Page 40]
-
-RFC 1521 MIME September 1993
-
-
- Message-ID: <anotherid@foo.com>
- MIME-Version: 1.0
- Content-type: audio/basic
- Content-transfer-encoding: base64
-
- ... first half of encoded audio data goes here...
-
- and the second half might look something like this:
-
- From: Bill@host.com
- To: joe@otherhost.com
- Subject: Audio mail
- MIME-Version: 1.0
- Message-ID: <id2@host.com>
- Content-type: message/partial;
- id="ABC@host.com"; number=2; total=2
-
- ... second half of encoded audio data goes here...
-
- Then, when the fragmented message is reassembled, the resulting
- message to be displayed to the user should look something like this:
-
- X-Weird-Header-1: Foo
- From: Bill@host.com
- To: joe@otherhost.com
- Subject: Audio mail
- Message-ID: <anotherid@foo.com>
- MIME-Version: 1.0
- Content-type: audio/basic
- Content-transfer-encoding: base64
-
- ... first half of encoded audio data goes here...
- ... second half of encoded audio data goes here...
-
- Note on encoding of MIME entities encapsulated inside message/partial
- entities: Because data of type "message" may never be encoded in
- base64 or quoted-printable, a problem might arise if message/partial
- entities are constructed in an environment that supports binary or
- 8-bit transport. The problem is that the binary data would be split
- into multiple message/partial objects, each of them requiring binary
- transport. If such objects were encountered at a gateway into a 7-
- bit transport environment, there would be no way to properly encode
- them for the 7-bit world, aside from waiting for all of the parts,
- reassembling the message, and then encoding the reassembled data in
- base64 or quoted-printable. Since it is possible that different
- parts might go through different gateways, even this is not an
- acceptable solution. For this reason, it is specified that MIME
- entities of type message/partial must always have a content-
-
-
-
-Borenstein & Freed [Page 41]
-
-RFC 1521 MIME September 1993
-
-
- transfer-encoding of 7-bit (the default). In particular, even in
- environments that support binary or 8-bit transport, the use of a
- content-transfer-encoding of "8bit" or "binary" is explicitly
- prohibited for entities of type message/partial.
-
- It should be noted that, because some message transfer agents may
- choose to automatically fragment large messages, and because such
- agents may use different fragmentation thresholds, it is possible
- that the pieces of a partial message, upon reassembly, may prove
- themselves to comprise a partial message. This is explicitly
- permitted.
-
- It should also be noted that the inclusion of a "References" field in
- the headers of the second and subsequent pieces of a fragmented
- message that references the Message-Id on the previous piece may be
- of benefit to mail readers that understand and track references.
- However, the generation of such "References" fields is entirely
- optional.
-
- Finally, it should be noted that the "Encrypted" header field has
- been made obsolete by Privacy Enhanced Messaging (PEM), but the rules
- above are believed to describe the correct way to treat it if it is
- encountered in the context of conversion to and from message/partial
- fragments.
-
-7.3.3. The Message/External-Body subtype
-
- The external-body subtype indicates that the actual body data are not
- included, but merely referenced. In this case, the parameters
- describe a mechanism for accessing the external data.
-
- When an entity is of type "message/external-body", it consists of a
- header, two consecutive CRLFs, and the message header for the
- encapsulated message. If another pair of consecutive CRLFs appears,
- this of course ends the message header for the encapsulated message.
- However, since the encapsulated message's body is itself external, it
- does NOT appear in the area that follows. For example, consider the
- following message:
-
- Content-type: message/external-body; access-
- type=local-file;
-
- name="/u/nsb/Me.gif"
-
- Content-type: image/gif
- Content-ID: <id42@guppylake.bellcore.com>
- Content-Transfer-Encoding: binary
-
-
-
-
-Borenstein & Freed [Page 42]
-
-RFC 1521 MIME September 1993
-
-
- THIS IS NOT REALLY THE BODY!
-
- The area at the end, which might be called the "phantom body", is
- ignored for most external-body messages. However, it may be used to
- contain auxiliary information for some such messages, as indeed it is
- when the access-type is "mail-server". Of the access-types defined
- by this document, the phantom body is used only when the access-type
- is "mail-server". In all other cases, the phantom body is ignored.
-
- The only always-mandatory parameter for message/external-body is
- "access-type"; all of the other parameters may be mandatory or
- optional depending on the value of access-type.
-
- ACCESS-TYPE -- A case-insensitive word, indicating the supported
- access mechanism by which the file or data may be obtained.
- Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP",
- "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for
- experimental values beginning with "X-" must be registered with
- IANA, as described in Appendix E .
-
- In addition, the following three parameters are optional for ALL
- access-types:
-
- EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as
- extended by RFC 1123 to permit 4 digits in the year field) after
- which the existence of the external data is not guaranteed.
-
- SIZE -- The size (in octets) of the data. The intent of this
- parameter is to help the recipient decide whether or not to expend
- the necessary resources to retrieve the external data. Note that
- this describes the size of the data in its canonical form, that
- is, before any Content- Transfer-Encoding has been applied or
- after the data have been decoded.
-
- PERMISSION -- A case-insensitive field that indicates whether or
- not it is expected that clients might also attempt to overwrite
- the data. By default, or if permission is "read", the assumption
- is that they are not, and that if the data is retrieved once, it
- is never needed again. If PERMISSION is "read-write", this
- assumption is invalid, and any local copy must be considered no
- more than a cache. "Read" and "Read-write" are the only defined
- values of permission.
-
- The precise semantics of the access-types defined here are described
- in the sections that follow.
-
- The encapsulated headers in ALL message/external-body entities MUST
- include a Content-ID header field to give a unique identifier by
-
-
-
-Borenstein & Freed [Page 43]
-
-RFC 1521 MIME September 1993
-
-
- which to reference the data. This identifier may be used for
- cacheing mechanisms, and for recognizing the receipt of the data when
- the access-type is "mail-server".
-
- Note that, as specified here, the tokens that describe external-body
- data, such as file names and mail server commands, are required to be
- in the US-ASCII character set. If this proves problematic in
- practice, a new mechanism may be required as a future extension to
- MIME, either as newly defined access-types for message/external-body
- or by some other mechanism.
-
- As with message/partial, it is specified that MIME entities of type
- message/external-body must always have a content-transfer-encoding of
- 7-bit (the default). In particular, even in environments that
- support binary or 8-bit transport, the use of a content-transfer-
- encoding of "8bit" or "binary" is explicitly prohibited for entities
- of type message/external-body.
-
-7.3.3.1. The "ftp" and "tftp" access-types
-
- An access-type of FTP or TFTP indicates that the message body is
- accessible as a file using the FTP [RFC-959] or TFTP [RFC-783]
- protocols, respectively. For these access-types, the following
- additional parameters are mandatory:
-
- NAME -- The name of the file that contains the actual body data.
-
- SITE -- A machine from which the file may be obtained, using the
- given protocol. This must be a fully qualified domain name, not a
- nickname.
-
- Before any data are retrieved, using FTP, the user will generally
- need to be asked to provide a login id and a password for the machine
- named by the site parameter. For security reasons, such an id and
- password are not specified as content-type parameters, but must be
- obtained from the user.
-
- In addition, the following parameters are optional:
-
- DIRECTORY -- A directory from which the data named by NAME should
- be retrieved.
-
- MODE -- A case-insensitive string indicating the mode to be used
- when retrieving the information. The legal values for access-type
- "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the
- TFTP protocol [RFC-783]. The legal values for access-type "FTP"
- are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a
- decimal integer, typically 8. These correspond to the
-
-
-
-Borenstein & Freed [Page 44]
-
-RFC 1521 MIME September 1993
-
-
- representation types "A" "E" "I" and "L n" as specified by the FTP
- protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid
- values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be
- used instead. IF MODE is not specified, the default value is
- "NETASCII" for TFTP and "ASCII" otherwise.
-
-7.3.3.2. The "anon-ftp" access-type
-
- The "anon-ftp" access-type is identical to the "ftp" access type,
- except that the user need not be asked to provide a name and password
- for the specified site. Instead, the ftp protocol will be used with
- login "anonymous" and a password that corresponds to the user's email
- address.
-
-7.3.3.3. The "local-file" and "afs" access-types
-
- An access-type of "local-file" indicates that the actual body is
- accessible as a file on the local machine. An access-type of "afs"
- indicates that the file is accessible via the global AFS file system.
- In both cases, only a single parameter is required:
-
- NAME -- The name of the file that contains the actual body data.
-
- The following optional parameter may be used to describe the locality
- of reference for the data, that is, the site or sites at which the
- file is expected to be visible:
-
- SITE -- A domain specifier for a machine or set of machines that
- are known to have access to the data file. Asterisks may be used
- for wildcard matching to a part of a domain name, such as
- "*.bellcore.com", to indicate a set of machines on which the data
- should be directly visible, while a single asterisk may be used to
- indicate a file that is expected to be universally available,
- e.g., via a global file system.
-
-7.3.3.4. The "mail-server" access-type
-
- The "mail-server" access-type indicates that the actual body is
- available from a mail server. The mandatory parameter for this
- access-type is:
-
- SERVER -- The email address of the mail server from which the
- actual body data can be obtained.
-
- Because mail servers accept a variety of syntaxes, some of which is
- multiline, the full command to be sent to a mail server is not
- included as a parameter on the content-type line. Instead, it is
- provided as the "phantom body" when the content-type is
-
-
-
-Borenstein & Freed [Page 45]
-
-RFC 1521 MIME September 1993
-
-
- message/external-body and the access- type is mail-server.
-
- An optional parameter for this access-type is:
-
- SUBJECT -- The subject that is to be used in the mail that is sent
- to obtain the data. Note that keying mail servers on Subject lines
- is NOT recommended, but such mail servers are known to exist.
-
- Note that MIME does not define a mail server syntax. Rather, it
- allows the inclusion of arbitrary mail server commands in the phantom
- body. Implementations must include the phantom body in the body of
- the message it sends to the mail server address to retrieve the
- relevant data.
-
- It is worth noting that, unlike other access-types, mail-server
- access is asynchronous and will happen at an unpredictable time in
- the future. For this reason, it is important that there be a
- mechanism by which the returned data can be matched up with the
- original message/external-body entity. MIME mailservers must use the
- same Content-ID field on the returned message that was used in the
- original message/external-body entity, to facilitate such matching.
-
-7.3.3.5. Examples and Further Explanations
-
- With the emerging possibility of very wide-area file systems, it
- becomes very hard to know in advance the set of machines where a file
- will and will not be accessible directly from the file system.
- Therefore it may make sense to provide both a file name, to be tried
- directly, and the name of one or more sites from which the file is
- known to be accessible. An implementation can try to retrieve remote
- files using FTP or any other protocol, using anonymous file retrieval
- or prompting the user for the necessary name and password. If an
- external body is accessible via multiple mechanisms, the sender may
- include multiple parts of type message/external-body within an entity
- of type multipart/alternative.
-
- However, the external-body mechanism is not intended to be limited to
- file retrieval, as shown by the mail-server access-type. Beyond
- this, one can imagine, for example, using a video server for external
- references to video clips.
-
- If an entity is of type "message/external-body", then the body of the
- entity will contain the header fields of the encapsulated message.
- The body itself is to be found in the external location. This means
- that if the body of the "message/external-body" message contains two
- consecutive CRLFs, everything after those pairs is NOT part of the
- message itself. For most message/external-body messages, this
- trailing area must simply be ignored. However, it is a convenient
-
-
-
-Borenstein & Freed [Page 46]
-
-RFC 1521 MIME September 1993
-
-
- place for additional data that cannot be included in the content-type
- header field. In particular, if the "access-type" value is "mail-
- server", then the trailing area must contain commands to be sent to
- the mail server at the address given by the value of the SERVER
- parameter.
-
- The embedded message header fields which appear in the body of the
- message/external-body data must be used to declare the Content-type
- of the external body if it is anything other than plain ASCII text,
- since the external body does not have a header section to declare its
- type. Similarly, any Content-transfer-encoding other than "7bit"
- must also be declared here. Thus a complete message/external-body
- message, referring to a document in PostScript format, might look
- like this:
-
- From: Whomever
- To: Someone
- Subject: whatever
- MIME-Version: 1.0
- Message-ID: <id1@host.com>
- Content-Type: multipart/alternative; boundary=42
- Content-ID: <id001@guppylake.bellcore.com>
-
- --42
- Content-Type: message/external-body;
- name="BodyFormats.ps";
- site="thumper.bellcore.com";
- access-type=ANON-FTP;
- directory="pub";
- mode="image";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <id42@guppylake.bellcore.com>
-
- --42
- Content-Type: message/external-body;
- name="/u/nsb/writing/rfcs/RFC-MIME.ps";
- site="thumper.bellcore.com";
- access-type=AFS
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <id42@guppylake.bellcore.com>
-
- --42
- Content-Type: message/external-body;
- access-type=mail-server
-
-
-
-Borenstein & Freed [Page 47]
-
-RFC 1521 MIME September 1993
-
-
- server="listserv@bogus.bitnet";
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
-
- Content-type: application/postscript
- Content-ID: <id42@guppylake.bellcore.com>
-
- get RFC-MIME.DOC
-
- --42--
-
- Note that in the above examples, the default Content-transfer-
- encoding of "7bit" is assumed for the external postscript data.
-
- Like the message/partial type, the message/external-body type is
- intended to be transparent, that is, to convey the data type in the
- external body rather than to convey a message with a body of that
- type. Thus the headers on the outer and inner parts must be merged
- using the same rules as for message/partial. In particular, this
- means that the Content-type header is overridden, but the From and
- Subject headers are preserved.
-
- Note that since the external bodies are not transported as mail, they
- need not conform to the 7-bit and line length requirements, but might
- in fact be binary files. Thus a Content-Transfer-Encoding is not
- generally necessary, though it is permitted.
-
- Note that the body of a message of type "message/external-body" is
- governed by the basic syntax for an RFC 822 message. In particular,
- anything before the first consecutive pair of CRLFs is header
- information, while anything after it is body information, which is
- ignored for most access-types.
-
- The formal grammar for content-type header fields for data of type
- message is given by:
-
- message-type := "message" "/" message-subtype
-
- message-subtype := "rfc822"
- / "partial" 2#3partial-param
- / "external-body" 1*external-param
- / extension-token
-
- partial-param := (";" "id" "=" value)
- / (";" "number" "=" 1*DIGIT)
- / (";" "total" "=" 1*DIGIT)
- ; id & number required; total required for last part
-
- external-param := (";" "access-type" "=" atype)
-
-
-
-Borenstein & Freed [Page 48]
-
-RFC 1521 MIME September 1993
-
-
- / (";" "expiration" "=" date-time)
- ; Note that date-time is quoted
- / (";" "size" "=" 1*DIGIT)
- / (";" "permission" "=" ("read" / "read-write"))
- ; Permission is case-insensitive
- / (";" "name" "=" value)
- / (";" "site" "=" value)
- / (";" "dir" "=" value)
- / (";" "mode" "=" value)
- / (";" "server" "=" value)
- / (";" "subject" "=" value)
- ; access-type required;others required based on access-type
-
- atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
- / "afs" / "mail-server" / extension-token
- ; Case-insensitive
-
-7.4. The Application Content-Type
-
- The "application" Content-Type is to be used for data which do not
- fit in any of the other categories, and particularly for data to be
- processed by mail-based uses of application programs. This is
- information which must be processed by an application before it is
- viewable or usable to a user. Expected uses for Content-Type
- application include mail-based file transfer, spreadsheets, data for
- mail-based scheduling systems, and languages for "active"
- (computational) email. (The latter, in particular, can pose security
- problems which must be understood by implementors, and are considered
- in detail in the discussion of the application/PostScript content-
- type.)
-
- For example, a meeting scheduler might define a standard
- representation for information about proposed meeting dates. An
- intelligent user agent would use this information to conduct a dialog
- with the user, and might then send further mail based on that dialog.
- More generally, there have been several "active" messaging languages
- developed in which programs in a suitably specialized language are
- sent through the mail and automatically run in the recipient's
- environment.
-
- Such applications may be defined as subtypes of the "application"
- Content-Type. This document defines two subtypes: octet-stream, and
- PostScript.
-
- In general, the subtype of application will often be the name of the
- application for which the data are intended. This does not mean,
- however, that any application program name may be used freely as a
- subtype of application. Such usages (other than subtypes beginning
-
-
-
-Borenstein & Freed [Page 49]
-
-RFC 1521 MIME September 1993
-
-
- with "x-") must be registered with IANA, as described in Appendix E.
-
-7.4.1. The Application/Octet-Stream (primary) subtype
-
- The primary subtype of application, "octet-stream", may be used to
- indicate that a body contains binary data. The set of possible
- parameters includes, but is not limited to:
-
- TYPE -- the general type or category of binary data. This is
- intended as information for the human recipient rather than for
- any automatic processing.
-
- PADDING -- the number of bits of padding that were appended to the
- bit-stream comprising the actual contents to produce the enclosed
- byte-oriented data. This is useful for enclosing a bit-stream in
- a body when the total number of bits is not a multiple of the byte
- size.
-
- An additional parameter, "conversions", was defined in [RFC-1341] but
- has been removed.
-
- RFC 1341 also defined the use of a "NAME" parameter which gave a
- suggested file name to be used if the data were to be written to a
- file. This has been deprecated in anticipation of a separate
- Content-Disposition header field, to be defined in a subsequent RFC.
-
- The recommended action for an implementation that receives
- application/octet-stream mail is to simply offer to put the data in a
- file, with any Content-Transfer-Encoding undone, or perhaps to use it
- as input to a user-specified process.
-
- To reduce the danger of transmitting rogue programs through the mail,
- it is strongly recommended that implementations NOT implement a
- path-search mechanism whereby an arbitrary program named in the
- Content-Type parameter (e.g., an "interpreter=" parameter) is found
- and executed using the mail body as input.
-
-7.4.2. The Application/PostScript subtype
-
- A Content-Type of "application/postscript" indicates a PostScript
- program. Currently two variants of the PostScript language are
- allowed; the original level 1 variant is described in [POSTSCRIPT]
- and the more recent level 2 variant is described in [POSTSCRIPT2].
-
- PostScript is a registered trademark of Adobe Systems, Inc. Use of
- the MIME content-type "application/postscript" implies recognition of
- that trademark and all the rights it entails.
-
-
-
-
-Borenstein & Freed [Page 50]
-
-RFC 1521 MIME September 1993
-
-
- The PostScript language definition provides facilities for internal
- labeling of the specific language features a given program uses. This
- labeling, called the PostScript document structuring conventions, is
- very general and provides substantially more information than just
- the language level.
-
- The use of document structuring conventions, while not required, is
- strongly recommended as an aid to interoperability. Documents which
- lack proper structuring conventions cannot be tested to see whether
- or not they will work in a given environment. As such, some systems
- may assume the worst and refuse to process unstructured documents.
-
- The execution of general-purpose PostScript interpreters entails
- serious security risks, and implementors are discouraged from simply
- sending PostScript email bodies to "off-the-shelf" interpreters.
- While it is usually safe to send PostScript to a printer, where the
- potential for harm is greatly constrained, implementors should
- consider all of the following before they add interactive display of
- PostScript bodies to their mail readers.
-
- The remainder of this section outlines some, though probably not all,
- of the possible problems with sending PostScript through the mail.
-
- Dangerous operations in the PostScript language include, but may not
- be limited to, the PostScript operators deletefile, renamefile,
- filenameforall, and file. File is only dangerous when applied to
- something other than standard input or output. Implementations may
- also define additional nonstandard file operators; these may also
- pose a threat to security. Filenameforall, the wildcard file search
- operator, may appear at first glance to be harmless. Note, however,
- that this operator has the potential to reveal information about what
- files the recipient has access to, and this information may itself be
- sensitive. Message senders should avoid the use of potentially
- dangerous file operators, since these operators are quite likely to
- be unavailable in secure PostScript implementations. Message-
- receiving and -displaying software should either completely disable
- all potentially dangerous file operators or take special care not to
- delegate any special authority to their operation. These operators
- should be viewed as being done by an outside agency when interpreting
- PostScript documents. Such disabling and/or checking should be done
- completely outside of the reach of the PostScript language itself;
- care should be taken to insure that no method exists for re-enabling
- full-function versions of these operators.
-
- The PostScript language provides facilities for exiting the normal
- interpreter, or server, loop. Changes made in this "outer"
- environment are customarily retained across documents, and may in
- some cases be retained semipermanently in nonvolatile memory. The
-
-
-
-Borenstein & Freed [Page 51]
-
-RFC 1521 MIME September 1993
-
-
- operators associated with exiting the interpreter loop have the
- potential to interfere with subsequent document processing. As such,
- their unrestrained use constitutes a threat of service denial.
- PostScript operators that exit the interpreter loop include, but may
- not be limited to, the exitserver and startjob operators. Message-
- sending software should not generate PostScript that depends on
- exiting the interpreter loop to operate. The ability to exit will
- probably be unavailable in secure PostScript implementations.
- Message-receiving and -displaying software should, if possible,
- disable the ability to make retained changes to the PostScript
- environment, and eliminate the startjob and exitserver commands. If
- these commands cannot be eliminated, the password associated with
- them should at least be set to a hard-to-guess value.
-
- PostScript provides operators for setting system-wide and device-
- specific parameters. These parameter settings may be retained across
- jobs and may potentially pose a threat to the correct operation of
- the interpreter. The PostScript operators that set system and device
- parameters include, but may not be limited to, the setsystemparams
- and setdevparams operators. Message-sending software should not
- generate PostScript that depends on the setting of system or device
- parameters to operate correctly. The ability to set these parameters
- will probably be unavailable in secure PostScript implementations.
- Message-receiving and -displaying software should, if possible,
- disable the ability to change system and device parameters. If these
- operators cannot be disabled, the password associated with them
- should at least be set to a hard-to-guess value.
-
- Some PostScript implementations provide nonstandard facilities for
- the direct loading and execution of machine code. Such facilities
- are quite obviously open to substantial abuse. Message-sending
- software should not make use of such features. Besides being totally
- hardware- specific, they are also likely to be unavailable in secure
- implementations of PostScript. Message-receiving and -displaying
- software should not allow such operators to be used if they exist.
-
- PostScript is an extensible language, and many, if not most,
- implementations of it provide a number of their own extensions. This
- document does not deal with such extensions explicitly since they
- constitute an unknown factor. Message-sending software should not
- make use of nonstandard extensions; they are likely to be missing
- from some implementations. Message-receiving and -displaying software
- should make sure that any nonstandard PostScript operators are secure
- and don't present any kind of threat.
-
- It is possible to write PostScript that consumes huge amounts of
- various system resources. It is also possible to write PostScript
- programs that loop infinitely. Both types of programs have the
-
-
-
-Borenstein & Freed [Page 52]
-
-RFC 1521 MIME September 1993
-
-
- potential to cause damage if sent to unsuspecting recipients.
- Message-sending software should avoid the construction and
- dissemination of such programs, which is antisocial. Message-
- receiving and -displaying software should provide appropriate
- mechanisms to abort processing of a document after a reasonable
- amount of time has elapsed. In addition, PostScript interpreters
- should be limited to the consumption of only a reasonable amount of
- any given system resource.
-
- Finally, bugs may exist in some PostScript interpreters which could
- possibly be exploited to gain unauthorized access to a recipient's
- system. Apart from noting this possibility, there is no specific
- action to take to prevent this, apart from the timely correction of
- such bugs if any are found.
-
-7.4.3. Other Application subtypes
-
- It is expected that many other subtypes of application will be
- defined in the future. MIME implementations must generally treat any
- unrecognized subtypes as being equivalent to application/octet-
- stream.
-
- The formal grammar for content-type header fields for application
- data is given by:
-
- application-type := "application" "/" application-subtype
-
- application-subtype := ("octet-stream" *stream-param)
- / "postscript" / extension-token
-
- stream-param := (";" "type" "=" value)
- / (";" "padding" "=" padding)
-
- padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
-
-7.5. The Image Content-Type
-
- A Content-Type of "image" indicates that the body contains an image.
- The subtype names the specific image format. These names are case
- insensitive. Two initial subtypes are "jpeg" for the JPEG format,
- JFIF encoding, and "gif" for GIF format [GIF].
-
- The list of image subtypes given here is neither exclusive nor
- exhaustive, and is expected to grow as more types are registered with
- IANA, as described in Appendix E.
-
- The formal grammar for the content-type header field for data of type
- image is given by:
-
-
-
-Borenstein & Freed [Page 53]
-
-RFC 1521 MIME September 1993
-
-
- image-type := "image" "/" ("gif" / "jpeg" / extension-token)
-
-7.6. The Audio Content-Type
-
- A Content-Type of "audio" indicates that the body contains audio
- data. Although there is not yet a consensus on an "ideal" audio
- format for use with computers, there is a pressing need for a format
- capable of providing interoperable behavior.
-
- The initial subtype of "basic" is specified to meet this requirement
- by providing an absolutely minimal lowest common denominator audio
- format. It is expected that richer formats for higher quality and/or
- lower bandwidth audio will be defined by a later document.
-
- The content of the "audio/basic" subtype is audio encoded using 8-bit
- ISDN mu-law [PCM]. When this subtype is present, a sample rate of
- 8000 Hz and a single channel is assumed.
-
- The formal grammar for the content-type header field for data of type
- audio is given by:
-
- audio-type := "audio" "/" ("basic" / extension-token)
-
-7.7. The Video Content-Type
-
- A Content-Type of "video" indicates that the body contains a time-
- varying-picture image, possibly with color and coordinated sound.
- The term "video" is used extremely generically, rather than with
- reference to any particular technology or format, and is not meant to
- preclude subtypes such as animated drawings encoded compactly. The
- subtype "mpeg" refers to video coded according to the MPEG standard
- [MPEG].
-
- Note that although in general this document strongly discourages the
- mixing of multiple media in a single body, it is recognized that many
- so-called "video" formats include a representation for synchronized
- audio, and this is explicitly permitted for subtypes of "video".
-
- The formal grammar for the content-type header field for data of type
- video is given by:
-
- video-type := "video" "/" ("mpeg" / extension-token)
-
-7.8. Experimental Content-Type Values
-
- A Content-Type value beginning with the characters "X-" is a private
- value, to be used by consenting mail systems by mutual agreement.
- Any format without a rigorous and public definition must be named
-
-
-
-Borenstein & Freed [Page 54]
-
-RFC 1521 MIME September 1993
-
-
- with an "X-" prefix, and publicly specified values shall never begin
- with "X-". (Older versions of the widely-used Andrew system use the
- "X-BE2" name, so new systems should probably choose a different
- name.)
-
- In general, the use of "X-" top-level types is strongly discouraged.
- Implementors should invent subtypes of the existing types whenever
- possible. The invention of new types is intended to be restricted
- primarily to the development of new media types for email, such as
- digital odors or holography, and not for new data formats in general.
- In many cases, a subtype of application will be more appropriate than
- a new top-level type.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 55]
-
-RFC 1521 MIME September 1993
-
-
-8. Summary
-
- Using the MIME-Version, Content-Type, and Content-Transfer-Encoding
- header fields, it is possible to include, in a standardized way,
- arbitrary types of data objects with RFC 822 conformant mail
- messages. No restrictions imposed by either RFC 821 or RFC 822 are
- violated, and care has been taken to avoid problems caused by
- additional restrictions imposed by the characteristics of some
- Internet mail transport mechanisms (see Appendix B). The "multipart"
- and "message" Content-Types allow mixing and hierarchical structuring
- of objects of different types in a single message. Further Content-
- Types provide a standardized mechanism for tagging messages or body
- parts as audio, image, or several other kinds of data. A
- distinguished parameter syntax allows further specification of data
- format details, particularly the specification of alternate character
- sets. Additional optional header fields provide mechanisms for
- certain extensions deemed desirable by many implementors. Finally, a
- number of useful Content-Types are defined for general use by
- consenting user agents, notably message/partial, and
- message/external-body.
-
-9. Security Considerations
-
- Security issues are discussed in Section 7.4.2 and in Appendix F.
- Implementors should pay special attention to the security
- implications of any mail content-types that can cause the remote
- execution of any actions in the recipient's environment. In such
- cases, the discussion of the application/postscript content-type in
- Section 7.4.2 may serve as a model for considering other content-
- types with remote execution capabilities.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 56]
-
-RFC 1521 MIME September 1993
-
-
-10. Authors' Addresses
-
- For more information, the authors of this document may be contacted
- via Internet mail:
-
- Nathaniel S. Borenstein
- MRE 2D-296, Bellcore
- 445 South St.
- Morristown, NJ 07962-1910
-
- Phone: +1 201 829 4270
- Fax: +1 201 829 7019
- Email: nsb@bellcore.com
-
-
- Ned Freed
- Innosoft International, Inc.
- 250 West First Street
- Suite 240
- Claremont, CA 91711
-
- Phone: +1 909 624 7907
- Fax: +1 909 621 5319
- Email: ned@innosoft.com
-
- MIME is a result of the work of the Internet Engineering Task Force
- Working Group on Email Extensions. The chairman of that group, Greg
- Vaudreuil, may be reached at:
-
- Gregory M. Vaudreuil
- Tigon Corporation
- 17060 Dallas Parkway
- Dallas Texas, 75248
-
- Phone: +1 214-733-2722
- EMail: gvaudre@cnri.reston.va.us
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 57]
-
-RFC 1521 MIME September 1993
-
-
-11. Acknowledgements
-
- This document is the result of the collective effort of a large
- number of people, at several IETF meetings, on the IETF-SMTP and
- IETF-822 mailing lists, and elsewhere. Although any enumeration
- seems doomed to suffer from egregious omissions, the following are
- among the many contributors to this effort:
-
- Harald Tveit Alvestrand Timo Lehtinen
- Randall Atkinson John R. MacMillan
- Philippe Brandon Rick McGowan
- Kevin Carosso Leo Mclaughlin
- Uhhyung Choi Goli Montaser-Kohsari
- Cristian Constantinof Keith Moore
- Mark Crispin Tom Moore
- Dave Crocker Erik Naggum
- Terry Crowley Mark Needleman
- Walt Daniels John Noerenberg
- Frank Dawson Mats Ohrman
- Hitoshi Doi Julian Onions
- Kevin Donnelly Michael Patton
- Keith Edwards David J. Pepper
- Chris Eich Blake C. Ramsdell
- Johnny Eriksson Luc Rooijakkers
- Craig Everhart Marshall T. Rose
- Patrik Faeltstroem Jonathan Rosenberg
- Erik E. Fair Jan Rynning
- Roger Fajman Harri Salminen
- Alain Fontaine Michael Sanderson
- James M. Galvin Masahiro Sekiguchi
- Philip Gladstone Mark Sherman
- Thomas Gordon Keld Simonsen
- Phill Gross Bob Smart
- James Hamilton Peter Speck
- Steve Hardcastle-Kille Henry Spencer
- David Herron Einar Stefferud
- Bruce Howard Michael Stein
- Bill Janssen Klaus Steinberger
- Olle Jaernefors Peter Svanberg
- Risto Kankkunen James Thompson
- Phil Karn Steve Uhler
- Alan Katz Stuart Vance
- Tim Kehres Erik van der Poel
- Neil Katin Guido van Rossum
- Kyuho Kim Peter Vanderbilt
- Anders Klemets Greg Vaudreuil
- John Klensin Ed Vielmetti
- Valdis Kletniek Ryan Waldron
-
-
-
-Borenstein & Freed [Page 58]
-
-RFC 1521 MIME September 1993
-
-
- Jim Knowles Wally Wedel
- Stev Knowles Sven-Ove Westberg
- Bob Kummerfeld Brian Wideen
- Pekka Kytolaakso John Wobus
- Stellan Lagerstrom Glenn Wright
- Vincent Lau Rayan Zachariassen
- Donald Lindsay David Zimmerman
- Marc Andreessen Bob Braden
- Brian Capouch Peter Clitherow
- Dave Collier-Brown John Coonrod
- Stephen Crocker Jim Davis
- Axel Deininger Dana S Emery
- Martin Forssen Stephen Gildea
- Terry Gray Mark Horton
- Warner Losh Carlyn Lowery
- Laurence Lundblade Charles Lynn
- Larry Masinter Michael J. McInerny
- Jon Postel Christer Romson
- Yutaka Sato Markku Savela
- Richard Alan Schafer Larry W. Virden
- Rhys Weatherly Jay Weber
- Dave Wecker
-
-The authors apologize for any omissions from this list, which are
-certainly unintentional.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 59]
-
-RFC 1521 MIME September 1993
-
-
-Appendix A -- Minimal MIME-Conformance
-
- The mechanisms described in this document are open-ended. It is
- definitely not expected that all implementations will support all of
- the Content-Types described, nor that they will all share the same
- extensions. In order to promote interoperability, however, it is
- useful to define the concept of "MIME-conformance" to define a
- certain level of implementation that allows the useful interworking
- of messages with content that differs from US ASCII text. In this
- section, we specify the requirements for such conformance.
-
- A mail user agent that is MIME-conformant MUST:
-
- 1. Always generate a "MIME-Version: 1.0" header field.
-
- 2. Recognize the Content-Transfer-Encoding header field, and
- decode all received data encoded with either the quoted-printable
- or base64 implementations. Encode any data sent that is not in
- seven-bit mail-ready representation using one of these
- transformations and include the appropriate Content-Transfer-
- Encoding header field, unless the underlying transport mechanism
- supports non-seven-bit data, as SMTP does not.
-
- 3. Recognize and interpret the Content-Type header field, and
- avoid showing users raw data with a Content-Type field other than
- text. Be able to send at least text/plain messages, with the
- character set specified as a parameter if it is not US-ASCII.
-
- 4. Explicitly handle the following Content-Type values, to at
- least the following extents:
-
- Text:
-
- -- Recognize and display "text" mail
- with the character set "US-ASCII."
-
- -- Recognize other character sets at
- least to the extent of being able
- to inform the user about what
- character set the message uses.
-
- -- Recognize the "ISO-8859-*" character
- sets to the extent of being able to
- display those characters that are
- common to ISO-8859-* and US-ASCII,
- namely all characters represented
- by octet values 0-127.
-
-
-
-
-Borenstein & Freed [Page 60]
-
-RFC 1521 MIME September 1993
-
-
- -- For unrecognized subtypes, show or
- offer to show the user the "raw"
- version of the data after
- conversion of the content from
- canonical form to local form.
-
- Message:
-
- -- Recognize and display at least the
- primary (822) encapsulation.
-
- Multipart:
-
- -- Recognize the primary (mixed)
- subtype. Display all relevant
- information on the message level
- and the body part header level and
- then display or offer to display
- each of the body parts individually.
-
- -- Recognize the "alternative" subtype,
- and avoid showing the user
- redundant parts of
- multipart/alternative mail.
-
- -- Treat any unrecognized subtypes as if
- they were "mixed".
-
- Application:
-
- -- Offer the ability to remove either of
- the two types of Content-Transfer-
- Encoding defined in this document
- and put the resulting information
- in a user file.
-
- 5. Upon encountering any unrecognized Content- Type, an
- implementation must treat it as if it had a Content-Type of
- "application/octet-stream" with no parameter sub-arguments. How
- such data are handled is up to an implementation, but likely
- options for handling such unrecognized data include offering the
- user to write it into a file (decoded from its mail transport
- format) or offering the user to name a program to which the
- decoded data should be passed as input. Unrecognized predefined
- types, which in a MIME-conformant mailer might still include
- audio, image, or video, should also be treated in this way.
-
- A user agent that meets the above conditions is said to be MIME-
-
-
-
-Borenstein & Freed [Page 61]
-
-RFC 1521 MIME September 1993
-
-
- conformant. The meaning of this phrase is that it is assumed to be
- "safe" to send virtually any kind of properly-marked data to users of
- such mail systems, because such systems will at least be able to
- treat the data as undifferentiated binary, and will not simply splash
- it onto the screen of unsuspecting users. There is another sense in
- which it is always "safe" to send data in a format that is MIME-
- conformant, which is that such data will not break or be broken by
- any known systems that are conformant with RFC 821 and RFC 822. User
- agents that are MIME-conformant have the additional guarantee that
- the user will not be shown data that were never intended to be viewed
- as text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 62]
-
-RFC 1521 MIME September 1993
-
-
-Appendix B -- General Guidelines For Sending Email Data
-
- Internet email is not a perfect, homogeneous system. Mail may become
- corrupted at several stages in its travel to a final destination.
- Specifically, email sent throughout the Internet may travel across
- many networking technologies. Many networking and mail technologies
- do not support the full functionality possible in the SMTP transport
- environment. Mail traversing these systems is likely to be modified
- in such a way that it can be transported.
-
- There exist many widely-deployed non-conformant MTAs in the Internet.
- These MTAs, speaking the SMTP protocol, alter messages on the fly to
- take advantage of the internal data structure of the hosts they are
- implemented on, or are just plain broken.
-
- The following guidelines may be useful to anyone devising a data
- format (Content-Type) that will survive the widest range of
- networking technologies and known broken MTAs unscathed. Note that
- anything encoded in the base64 encoding will satisfy these rules, but
- that some well-known mechanisms, notably the UNIX uuencode facility,
- will not. Note also that anything encoded in the Quoted-Printable
- encoding will survive most gateways intact, but possibly not some
- gateways to systems that use the EBCDIC character set.
-
- (1) Under some circumstances the encoding used for data may change
- as part of normal gateway or user agent operation. In particular,
- conversion from base64 to quoted-printable and vice versa may be
- necessary. This may result in the confusion of CRLF sequences with
- line breaks in text bodies. As such, the persistence of CRLF as
- something other than a line break must not be relied on.
-
- (2) Many systems may elect to represent and store text data using
- local newline conventions. Local newline conventions may not match
- the RFC822 CRLF convention -- systems are known that use plain CR,
- plain LF, CRLF, or counted records. The result is that isolated
- CR and LF characters are not well tolerated in general; they may
- be lost or converted to delimiters on some systems, and hence must
- not be relied on.
-
- (3) TAB (HT) characters may be misinterpreted or may be
- automatically converted to variable numbers of spaces. This is
- unavoidable in some environments, notably those not based on the
- ASCII character set. Such conversion is STRONGLY DISCOURAGED, but
- it may occur, and mail formats must not rely on the persistence of
- TAB (HT) characters.
-
- (4) Lines longer than 76 characters may be wrapped or truncated in
- some environments. Line wrapping and line truncation are STRONGLY
-
-
-
-Borenstein & Freed [Page 63]
-
-RFC 1521 MIME September 1993
-
-
- DISCOURAGED, but unavoidable in some cases. Applications which
- require long lines must somehow differentiate between soft and
- hard line breaks. (A simple way to do this is to use the quoted-
- printable encoding.)
-
- (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line
- may be discarded by some transport agents, while other transport
- agents may pad lines with these characters so that all lines in a
- mail file are of equal length. The persistence of trailing white
- space, therefore, must not be relied on.
-
- (6) Many mail domains use variations on the ASCII character set,
- or use character sets such as EBCDIC which contain most but not
- all of the US-ASCII characters. The correct translation of
- characters not in the "invariant" set cannot be depended on across
- character converting gateways. For example, this situation is a
- problem when sending uuencoded information across BITNET, an
- EBCDIC system. Similar problems can occur without crossing a
- gateway, since many Internet hosts use character sets other than
- ASCII internally. The definition of Printable Strings in X.400
- adds further restrictions in certain special cases. In
- particular, the only characters that are known to be consistent
- across all gateways are the 73 characters that correspond to the
- upper and lower case letters A-Z and a-z, the 10 digits 0-9, and
- the following eleven special characters:
-
- "'" (ASCII code 39)
- "(" (ASCII code 40)
- ")" (ASCII code 41)
- "+" (ASCII code 43)
- "," (ASCII code 44)
- "-" (ASCII code 45)
- "." (ASCII code 46)
- "/" (ASCII code 47)
- ":" (ASCII code 58)
- "=" (ASCII code 61)
- "?" (ASCII code 63)
-
- A maximally portable mail representation, such as the base64
- encoding, will confine itself to relatively short lines of text in
- which the only meaningful characters are taken from this set of 73
- characters.
-
- (7) Some mail transport agents will corrupt data that includes
- certain literal strings. In particular, a period (".") alone on a
- line is known to be corrupted by some (incorrect) SMTP
- implementations, and a line that starts with the five characters
- "From " (the fifth character is a SPACE) are commonly corrupted as
-
-
-
-Borenstein & Freed [Page 64]
-
-RFC 1521 MIME September 1993
-
-
- well. A careful composition agent can prevent these corruptions
- by encoding the data (e.g., in the quoted-printable encoding,
- "=46rom " in place of "From " at the start of a line, and "=2E" in
- place of "." alone on a line.
-
- Please note that the above list is NOT a list of recommended
- practices for MTAs. RFC 821 MTAs are prohibited from altering the
- character of white space or wrapping long lines. These BAD and
- illegal practices are known to occur on established networks, and
- implementations should be robust in dealing with the bad effects they
- can cause.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 65]
-
-RFC 1521 MIME September 1993
-
-
-Appendix C -- A Complex Multipart Example
-
- What follows is the outline of a complex multipart message. This
- message has five parts to be displayed serially: two introductory
- plain text parts, an embedded multipart message, a richtext part, and
- a closing encapsulated text message in a non-ASCII character set.
- The embedded multipart message has two parts to be displayed in
- parallel, a picture and an audio fragment.
-
- MIME-Version: 1.0
- From: Nathaniel Borenstein <nsb@bellcore.com>
- To: Ned Freed <ned@innosoft.com>
- Subject: A multipart example
- Content-Type: multipart/mixed;
- boundary=unique-boundary-1
-
- This is the preamble area of a multipart message.
- Mail readers that understand multipart format
- should ignore this preamble.
- If you are reading this text, you might want to
- consider changing to a mail reader that understands
- how to properly display multipart messages.
- --unique-boundary-1
-
- ...Some text appears here...
- [Note that the preceding blank line means
- no header fields were given and this is text,
- with charset US ASCII. It could have been
- done with explicit typing as in the next part.]
-
- --unique-boundary-1
- Content-type: text/plain; charset=US-ASCII
-
- This could have been part of the previous part,
- but illustrates explicit versus implicit
- typing of body parts.
-
- --unique-boundary-1
- Content-Type: multipart/parallel;
- boundary=unique-boundary-2
-
-
- --unique-boundary-2
- Content-Type: audio/basic
- Content-Transfer-Encoding: base64
-
- ... base64-encoded 8000 Hz single-channel
- mu-law-format audio data goes here....
-
-
-
-Borenstein & Freed [Page 66]
-
-RFC 1521 MIME September 1993
-
-
- --unique-boundary-2
- Content-Type: image/gif
- Content-Transfer-Encoding: base64
-
- ... base64-encoded image data goes here....
-
- --unique-boundary-2--
-
- --unique-boundary-1
- Content-type: text/richtext
-
- This is <bold><italic>richtext.</italic></bold>
- <smaller>as defined in RFC 1341</smaller>
- <nl><nl>Isn't it
- <bigger><bigger>cool?</bigger></bigger>
-
- --unique-boundary-1
- Content-Type: message/rfc822
-
- From: (mailbox in US-ASCII)
- To: (address in US-ASCII)
- Subject: (subject in US-ASCII)
- Content-Type: Text/plain; charset=ISO-8859-1
- Content-Transfer-Encoding: Quoted-printable
-
- ... Additional text in ISO-8859-1 goes here ...
-
- --unique-boundary-1--
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 67]
-
-RFC 1521 MIME September 1993
-
-
-Appendix D -- Collected Grammar
-
- This appendix contains the complete BNF grammar for all the syntax
- specified by this document.
-
- By itself, however, this grammar is incomplete. It refers to several
- entities that are defined by RFC 822. Rather than reproduce those
- definitions here, and risk unintentional differences between the two,
- this document simply refers the reader to RFC 822 for the remaining
- definitions. Wherever a term is undefined, it refers to the RFC 822
- definition.
-
- application-subtype := ("octet-stream" *stream-param)
- / "postscript" / extension-token
-
- application-type := "application" "/" application-subtype
-
- attribute := token ; case-insensitive
-
- atype := "ftp" / "anon-ftp" / "tftp" / "local-file"
- / "afs" / "mail-server" / extension-token
- ; Case-insensitive
-
- audio-type := "audio" "/" ("basic" / extension-token)
-
- body-part := <"message" as defined in RFC 822,
- with all header fields optional, and with the
- specified delimiter not occurring anywhere in
- the message body, either on a line by itself
- or as a substring anywhere.>
-
- NOTE: In certain transport enclaves, RFC 822 restrictions such as
- the one that limits bodies to printable ASCII characters may not
- be in force. (That is, the transport domains may resemble
- standard Internet mail transport as specified in RFC821 and
- assumed by RFC822, but without certain restrictions.) The
- relaxation of these restrictions should be construed as locally
- extending the definition of bodies, for example to include octets
- outside of the ASCII range, as long as these extensions are
- supported by the transport and adequately documented in the
- Content-Transfer-Encoding header field. However, in no event are
- headers (either message headers or body-part headers) allowed to
- contain anything other than ASCII characters.
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 68]
-
-RFC 1521 MIME September 1993
-
-
- boundary := 0*69<bchars> bcharsnospace
-
- bchars := bcharsnospace / " "
-
- bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_"
- / "," / "-" / "." / "/" / ":" / "=" / "?"
-
- charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3"
- / "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7"
- / "iso-8859-8" / "iso-8859-9" / extension-token
- ; case insensitive
-
- close-delimiter := "--" boundary "--" CRLF;Again,no space by "--",
-
- content := "Content-Type" ":" type "/" subtype *(";" parameter)
- ; case-insensitive matching of type and subtype
-
- delimiter := "--" boundary CRLF ;taken from Content-Type field.
- ; There must be no space
- ; between "--" and boundary.
-
- description := "Content-Description" ":" *text
-
- discard-text := *(*text CRLF)
-
- encapsulation := delimiter body-part CRLF
-
- encoding := "Content-Transfer-Encoding" ":" mechanism
-
- epilogue := discard-text ; to be ignored upon receipt.
-
- extension-token := x-token / iana-token
-
- external-param := (";" "access-type" "=" atype)
- / (";" "expiration" "=" date-time)
-
- ; Note that date-time is quoted
- / (";" "size" "=" 1*DIGIT)
- / (";" "permission" "=" ("read" / "read-write"))
- ; Permission is case-insensitive
- / (";" "name" "=" value)
- / (";" "site" "=" value)
- / (";" "dir" "=" value)
- / (";" "mode" "=" value)
- / (";" "server" "=" value)
- / (";" "subject" "=" value)
- ;access-type required; others required based on access-type
-
-
-
-
-Borenstein & Freed [Page 69]
-
-RFC 1521 MIME September 1993
-
-
- iana-token := <a publicly-defined extension token,
- registered with IANA, as specified in
- appendix E>
-
- id := "Content-ID" ":" msg-id
-
- image-type := "image" "/" ("gif" / "jpeg" / extension-token)
-
- mechanism := "7bit" ; case-insensitive
- / "quoted-printable"
- / "base64"
- / "8bit"
- / "binary"
- / x-token
-
- message-subtype := "rfc822"
- / "partial" 2#3partial-param
- / "external-body" 1*external-param
- / extension-token
-
- message-type := "message" "/" message-subtype
-
- multipart-body :=preamble 1*encapsulation close-delimiter epilogue
-
- multipart-subtype := "mixed" / "parallel" / "digest"
- / "alternative" / extension-token
-
- multipart-type := "multipart" "/" multipart-subtype
- ";" "boundary" "=" boundary
-
- octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
- ; octet must be used for characters > 127, =, SPACE, or
- TAB,
- ; and is recommended for any characters not listed in
- ; Appendix B as "mail-safe".
-
- padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
-
- parameter := attribute "=" value
-
- partial-param := (";" "id" "=" value)
- / (";" "number" "=" 1*DIGIT)
- / (";" "total" "=" 1*DIGIT)
- ; id & number required;total required for last part
-
- preamble := discard-text ; to be ignored upon receipt.
-
- ptext := octet / <any ASCII character except "=", SPACE, or TAB>
-
-
-
-Borenstein & Freed [Page 70]
-
-RFC 1521 MIME September 1993
-
-
- ; characters not listed as "mail-safe" in Appendix B
- ; are also not recommended.
-
- quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
- ; Maximum line length of 76 characters excluding CRLF
-
- stream-param := (";" "type" "=" value)
- / (";" "padding" "=" padding)
-
- subtype := token ; case-insensitive
-
- text-subtype := "plain" / extension-token
-
- text-type := "text" "/" text-subtype [";" "charset" "=" charset]
-
- token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>
-
- tspecials := "(" / ")" / "<" / ">" / "@"
- / "," / ";" / ":" / "\" / <">
- / "/" / "[" / "]" / "?" / "="
- ; Must be in quoted-string,
- ; to use within parameter values
-
-
- type := "application" / "audio" ; case-insensitive
- / "image" / "message"
- / "multipart" / "text"
- / "video" / extension-token
- ; All values case-insensitive
-
- value := token / quoted-string
-
- version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
-
- video-type := "video" "/" ("mpeg" / extension-token)
-
- x-token := <The two characters "X-" or "x-" followed, with no
- intervening white space, by any token>
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 71]
-
-RFC 1521 MIME September 1993
-
-
-Appendix E -- IANA Registration Procedures
-
- MIME has been carefully designed to have extensible mechanisms, and
- it is expected that the set of content-type/subtype pairs and their
- associated parameters will grow significantly with time. Several
- other MIME fields, notably character set names, access-type
- parameters for the message/external-body type, and possibly even
- Content-Transfer-Encoding values, are likely to have new values
- defined over time. In order to ensure that the set of such values is
- developed in an orderly, well-specified, and public manner, MIME
- defines a registration process which uses the Internet Assigned
- Numbers Authority (IANA) as a central registry for such values.
-
- In general, parameters in the content-type header field are used to
- convey supplemental information for various content types, and their
- use is defined when the content-type and subtype are defined. New
- parameters should not be defined as a way to introduce new
- functionality.
-
- In order to simplify and standardize the registration process, this
- appendix gives templates for the registration of new values with
- IANA. Each of these is given in the form of an email message
- template, to be filled in by the registering party.
-
- E.1 Registration of New Content-type/subtype Values
-
- Note that MIME is generally expected to be extended by subtypes. If
- a new fundamental top-level type is needed, its specification must be
- published as an RFC or submitted in a form suitable to become an RFC,
- and be subject to the Internet standards process.
-
- To: IANA@isi.edu
- Subject: Registration of new MIME
- content-type/subtype
-
- MIME type name:
-
- (If the above is not an existing top-level MIME type,
- please explain why an existing type cannot be used.)
-
- MIME subtype name:
-
- Required parameters:
-
- Optional parameters:
-
- Encoding considerations:
-
-
-
-
-Borenstein & Freed [Page 72]
-
-RFC 1521 MIME September 1993
-
-
- Security considerations:
-
- Published specification:
-
- (The published specification must be an Internet RFC or
- RFC-to-be if a new top-level type is being defined, and
- must be a publicly available specification in any
- case.)
-
- Person & email address to contact for further information:
-
- E.2 Registration of New Access-type Values
- for Message/external-body
-
- To: IANA@isi.edu
- Subject: Registration of new MIME Access-type for
- Message/external-body content-type
-
- MIME access-type name:
-
- Required parameters:
-
- Optional parameters:
-
- Published specification:
-
- (The published specification must be an Internet RFC or
- RFC-to-be.)
-
- Person & email address to contact for further information:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 73]
-
-RFC 1521 MIME September 1993
-
-
-Appendix F -- Summary of the Seven Content-types
-
- Content-type: text
-
- Subtypes defined by this document: plain
-
- Important Parameters: charset
-
- Encoding notes: quoted-printable generally preferred if an encoding
- is needed and the character set is mostly an ASCII superset.
-
- Security considerations: Rich text formats such as TeX and Troff
- often contain mechanisms for executing arbitrary commands or file
- system operations, and should not be used automatically unless
- these security problems have been addressed. Even plain text may
- contain control characters that can be used to exploit the
- capabilities of "intelligent" terminals and cause security
- violations. User interfaces designed to run on such terminals
- should be aware of and try to prevent such problems.
-
- ________________________________________________________
- Content-type: multipart
-
- Subtypes defined by this document: mixed, alternative,
- digest, parallel.
-
- Important Parameters: boundary
-
- Encoding notes: No content-transfer-encoding is permitted.
-
- ________________________________________________________
- Content-type: message
-
- Subtypes defined by this document: rfc822, partial, external-body
-
- Important Parameters: id, number, total, access-type, expiration,
- size, permission, name, site, directory, mode, server, subject
-
- Encoding notes: No content-transfer-encoding is permitted.
- Specifically, only "7bit" is permitted for "message/partial" or
- "message/external-body", and only "7bit", "8bit", or "binary" are
- permitted for other subtypes of "message".
- ______________________________________________________________
- Content-type: application
-
- Subtypes defined by this document: octet-stream, postscript
-
- Important Parameters: type, padding
-
-
-
-Borenstein & Freed [Page 74]
-
-RFC 1521 MIME September 1993
-
-
- Deprecated Parameters: name and conversions were
- defined in RFC 1341.
-
- Encoding notes: base64 preferred for unreadable subtypes.
-
- Security considerations: This type is intended for the
- transmission of data to be interpreted by locally-installed
- programs. If used, for example, to transmit executable
- binary programs or programs in general-purpose interpreted
- languages, such as LISP programs or shell scripts, severe
- security problems could result. Authors of mail-reading
- agents are cautioned against giving their systems the power
- to execute mail-based application data without carefully
- considering the security implications. While it is
- certainly possible to define safe application formats and
- even safe interpreters for unsafe formats, each interpreter
- should be evaluated separately for possible security
- problems.
- ________________________________________________________________
- Content-type: image
-
- Subtypes defined by this document: jpeg, gif
-
- Important Parameters: none
-
- Encoding notes: base64 generally preferred
- ________________________________________________________________
- Content-type: audio
-
- Subtypes defined by this document: basic
-
- Important Parameters: none
-
- Encoding notes: base64 generally preferred
- ________________________________________________________________
- Content-type: video
-
- Subtypes defined by this document: mpeg
-
- Important Parameters: none
-
- Encoding notes: base64 generally preferred
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 75]
-
-RFC 1521 MIME September 1993
-
-
-Appendix G -- Canonical Encoding Model
-
- There was some confusion, in earlier drafts of this memo, regarding
- the model for when email data was to be converted to canonical form
- and encoded, and in particular how this process would affect the
- treatment of CRLFs, given that the representation of newlines varies
- greatly from system to system. For this reason, a canonical model
- for encoding is presented below.
-
- The process of composing a MIME entity can be modeled as being done
- in a number of steps. Note that these steps are roughly similar to
- those steps used in RFC 1421 and are performed for each 'innermost
- level' body:
-
- Step 1. Creation of local form.
-
- The body to be transmitted is created in the system's native format.
- The native character set is used, and where appropriate local end of
- line conventions are used as well. The body may be a UNIX-style text
- file, or a Sun raster image, or a VMS indexed file, or audio data in
- a system-dependent format stored only in memory, or anything else
- that corresponds to the local model for the representation of some
- form of information. Fundamentally, the data is created in the
- "native" form specified by the type/subtype information.
-
- Step 2. Conversion to canonical form.
-
- The entire body, including "out-of-band" information such as record
- lengths and possibly file attribute information, is converted to a
- universal canonical form. The specific content type of the body as
- well as its associated attributes dictate the nature of the canonical
- form that is used. Conversion to the proper canonical form may
- involve character set conversion, transformation of audio data,
- compression, or various other operations specific to the various
- content types. If character set conversion is involved, however,
- care must be taken to understand the semantics of the content-type,
- which may have strong implications for any character set conversion,
- e.g. with regard to syntactically meaningful characters in a text
- subtype other than "plain".
-
- For example, in the case of text/plain data, the text must be
- converted to a supported character set and lines must be delimited
- with CRLF delimiters in accordance with RFC822. Note that the
- restriction on line lengths implied by RFC822 is eliminated if the
- next step employs either quoted-printable or base64 encoding.
-
-
-
-
-
-
-Borenstein & Freed [Page 76]
-
-RFC 1521 MIME September 1993
-
-
- Step 3. Apply transfer encoding.
-
- A Content-Transfer-Encoding appropriate for this body is applied.
- Note that there is no fixed relationship between the content type and
- the transfer encoding. In particular, it may be appropriate to base
- the choice of base64 or quoted-printable on character frequency
- counts which are specific to a given instance of a body.
-
- Step 4. Insertion into entity.
-
- The encoded object is inserted into a MIME entity with appropriate
- headers. The entity is then inserted into the body of a higher-level
- entity (message or multipart) if needed.
-
- It is vital to note that these steps are only a model; they are
- specifically NOT a blueprint for how an actual system would be built.
- In particular, the model fails to account for two common designs:
-
- 1. In many cases the conversion to a canonical form prior to
- encoding will be subsumed into the encoder itself, which
- understands local formats directly. For example, the local
- newline convention for text bodies might be carried through to the
- encoder itself along with knowledge of what that format is.
-
- 2. The output of the encoders may have to pass through one or
- more additional steps prior to being transmitted as a message. As
- such, the output of the encoder may not be conformant with the
- formats specified by RFC822. In particular, once again it may be
- appropriate for the converter's output to be expressed using local
- newline conventions rather than using the standard RFC822 CRLF
- delimiters.
-
- Other implementation variations are conceivable as well. The vital
- aspect of this discussion is that, in spite of any optimizations,
- collapsings of required steps, or insertion of additional processing,
- the resulting messages must be consistent with those produced by the
- model described here. For example, a message with the following
- header fields:
-
- Content-type: text/foo; charset=bar
- Content-Transfer-Encoding: base64
-
- must be first represented in the text/foo form, then (if necessary)
- represented in the "bar" character set, and finally transformed via
- the base64 algorithm into a mail-safe form.
-
-
-
-
-
-
-Borenstein & Freed [Page 77]
-
-RFC 1521 MIME September 1993
-
-
-Appendix H -- Changes from RFC 1341
-
- This document is a relatively minor revision of RFC 1341. For
- the convenience of those familiar with RFC 1341, the technical
- changes from that document are summarized in this appendix.
-
- 1. The definition of "tspecials" has been changed to no longer
- include ".".
-
- 2. The Content-ID field is now mandatory for message/external-body
- parts.
-
- 3. The text/richtext type (including the old Section 7.1.3 and
- Appendix D) has been moved to a separate document.
-
- 4. The rules on header merging for message/partial data have been
- changed to treat the Encrypted and MIME-Version headers as special
- cases.
-
- 5. The definition of the external-body access-type parameter has
- been changed so that it can only indicate a single access method
- (which was all that made sense).
-
- 6. There is a new "Subject" parameter for message/external-body,
- access-type mail-server, to permit MIME-based use of mail servers
- that rely on Subject field information.
-
- 7. The "conversions" parameter for application/octet-stream has been
- removed.
-
- 8. Section 7.4.1 now deprecates the use of the "name" parameter for
- application/octet-stream, as this will be superseded in the future by
- a Content-Disposition header.
-
- 9. The formal grammar for multipart bodies has been changed so that
- a CRLF is no longer required before the first boundary line.
-
- 10. MIME entities of type "message/partial" and "message/external-
- body" are now required to use only the "7bit" transfer-encoding.
- (Specifically, "binary" and "8bit" are not permitted.)
-
- 11. The "application/oda" content-type has been removed.
-
- 12. A note has been added to the end of section 7.2.3, explaining
- the semantics of Content-ID in a multipart/alternative MIME entity.
-
- 13. The formal syntax for the "MIME-Version" field has been
- tightened, but in a way that is completely compatible with the only
-
-
-
-Borenstein & Freed [Page 78]
-
-RFC 1521 MIME September 1993
-
-
- version number defined in RFC 1341.
-
- 14. In Section 7.3.1, the definition of message/rfc822 has been
- relaxed regarding mandatory fields.
-
- All other changes from RFC 1341 were editorial changes and do not
- affect the technical content of MIME. Considerable formal grammar
- has been added, but this reflects the prose specification that was
- already in place.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Borenstein & Freed [Page 79]
-
-RFC 1521 MIME September 1993
-
-
-References
-
- [US-ASCII] Coded Character Set--7-Bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
- [ATK] Borenstein, Nathaniel S., Multimedia Applications Development
- with the Andrew Toolkit, Prentice-Hall, 1990.
-
- [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc.,
- Columbus, Ohio, 1990.
-
- [ISO-2022] International Standard--Information Processing--ISO 7-bit
- and 8-bit coded character sets--Code extension techniques, ISO
- 2022:1986.
-
- [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic
- Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part
- 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet
- No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4,
- 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:
- Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek
- alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO
- 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
-
- [ISO-646] International Standard--Information Processing--ISO 7-bit
- coded character set for information interchange, ISO 646:1983.
-
- [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11
- (Motion Picture Experts Group), May, 1991.
-
- [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972,
- "Pulse Code Modulation (PCM) of Voice Frequencies".
-
- [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference
- Manual, Addison-Wesley, 1985.
-
- [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference
- Manual, Addison-Wesley, Second Edition, 1990.
-
- [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message
- Handling Systems and Distributed Applications, E. Stefferud, O-j.
- Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.
-
- [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT,
- June 1981.
-
- [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, USC/Information Sciences Institute, August 1982.
-
-
-
-Borenstein & Freed [Page 80]
-
-RFC 1521 MIME September 1993
-
-
- [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, UDEL, August 1982.
-
- [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message
- Encapsulation", RFC 934, Delaware and NMA, January 1985.
-
- [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol",
- STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
-
- [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet
- Messages", STD 11, RFC 1049, CMU, March 1988.
-
- [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail:
- Part I - Message Encryption and Authentication Procedures", RFC
- 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.
-
- [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for
- Internet Messages", RFC 1154, Prime Computer, Inc., April 1990.
-
- [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
- Mail Extensions): Mechanisms for Specifying and Describing the Format
- of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.
-
- [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet
- Message Headers", RFC 1342, University of Tennessee, June 1992.
-
- [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism
- for Multimedia Mail Format Information", RFC 1343, Bellcore, June
- 1992.
-
- [RFC-1344] Borenstein, N., "Implications of MIME for Internet
- Mail Gateways", RFC 1344, Bellcore, June 1992.
-
- [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets",
- RFC 1345, Rationel Almen Planlaegning, June 1992.
-
- [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
- Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME
- transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach
- Consulting, Inc., Network Management Associates, Inc., The Branch
- Office, February 1993.
-
- [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet
- Message Headers" RFC 1522, University of Tennessee, September 1993.
-
- [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
- 1340, USC/Information Sciences Institute, July 1992.
-
-
-
-
-Borenstein & Freed [Page 81]
-
\ No newline at end of file diff --git a/RFC/rfc1725.txt b/RFC/rfc1725.txt deleted file mode 100644 index 43fcc518..00000000 --- a/RFC/rfc1725.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -Network Working Group J. Myers -Request for Comments: 1725 Carnegie Mellon -Obsoletes: 1460 M. Rose -Category: Standards Track Dover Beach Consulting, Inc. - November 1994 - - - Post Office Protocol - Version 3 - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Overview - - This memo is a revision to RFC 1460, a Draft Standard. It makes the - following changes from that document: - - - removed text regarding "split-UA model", which didn't add - anything to the understanding of POP - - - clarified syntax of commands, keywords, and arguments - - - clarified behavior on broken connection - - - explicitly permitted an inactivity autologout timer - - - clarified the requirements of the "exclusive-access lock" - - - removed implementation-specific wording regarding the parsing of - the maildrop - - - allowed servers to close the connection after a failed - authentication command - - - removed the LAST command - - - fixed typo in example of TOP command - - - clarified that the second argument to the TOP command is non- - negative - - - added the optional UIDL command - - - - -Myers & Rose [Page 1] - -RFC 1725 POP3 November 1994 - - - - added warning regarding length of shared secrets with APOP - - - added additional warnings to the security considerations section - -1. Introduction - - On certain types of smaller nodes in the Internet it is often - impractical to maintain a message transport system (MTS). For - example, a workstation may not have sufficient resources (cycles, - disk space) in order to permit a SMTP server [RFC821] and associated - local mail delivery system to be kept resident and continuously - running. Similarly, it may be expensive (or impossible) to keep a - personal computer interconnected to an IP-style network for long - amounts of time (the node is lacking the resource known as - "connectivity"). - - Despite this, it is often very useful to be able to manage mail on - these smaller nodes, and they often support a user agent (UA) to aid - the tasks of mail handling. To solve this problem, a node which can - support an MTS entity offers a maildrop service to these less endowed - nodes. The Post Office Protocol - Version 3 (POP3) is intended to - permit a workstation to dynamically access a maildrop on a server - host in a useful fashion. Usually, this means that the POP3 is used - to allow a workstation to retrieve mail that the server is holding - for it. - - For the remainder of this memo, the term "client host" refers to a - host making use of the POP3 service, while the term "server host" - refers to a host which offers the POP3 service. - -2. A Short Digression - - This memo does not specify how a client host enters mail into the - transport system, although a method consistent with the philosophy of - this memo is presented here: - - When the user agent on a client host wishes to enter a message - into the transport system, it establishes an SMTP connection to - its relay host (this relay host could be, but need not be, the - POP3 server host for the client host). - -3. Basic Operation - - Initially, the server host starts the POP3 service by listening on - TCP port 110. When a client host wishes to make use of the service, - it establishes a TCP connection with the server host. When the - connection is established, the POP3 server sends a greeting. The - client and POP3 server then exchange commands and responses - - - -Myers & Rose [Page 2] - -RFC 1725 POP3 November 1994 - - - (respectively) until the connection is closed or aborted. - - Commands in the POP3 consist of a keyword, possibly followed by one - or more arguments. All commands are terminated by a CRLF pair. - Keywords and arguments consist of printable ASCII characters. - Keywords and arguments are each separated by a single SPACE - character. Keywords are three or four characters long. Each argument - may be up to 40 characters long. - - Responses in the POP3 consist of a status indicator and a keyword - possibly followed by additional information. All responses are - terminated by a CRLF pair. There are currently two status - indicators: positive ("+OK") and negative ("-ERR"). - - Responses to certain commands are multi-line. In these cases, which - are clearly indicated below, after sending the first line of the - response and a CRLF, any additional lines are sent, each terminated - by a CRLF pair. When all lines of the response have been sent, a - final line is sent, consisting of a termination octet (decimal code - 046, ".") and a CRLF pair. If any line of the multi-line response - begins with the termination octet, the line is "byte-stuffed" by - pre-pending the termination octet to that line of the response. - Hence a multi-line response is terminated with the five octets - "CRLF.CRLF". When examining a multi-line response, the client checks - to see if the line begins with the termination octet. If so and if - octets other than CRLF follow, the the first octet of the line (the - termination octet) is stripped away. If so and if CRLF immediately - follows the termination character, then the response from the POP - server is ended and the line containing ".CRLF" is not considered - part of the multi-line response. - - A POP3 session progresses through a number of states during its - lifetime. Once the TCP connection has been opened and the POP3 - server has sent the greeting, the session enters the AUTHORIZATION - state. In this state, the client must identify itself to the POP3 - server. Once the client has successfully done this, the server - acquires resources associated with the client's maildrop, and the - session enters the TRANSACTION state. In this state, the client - requests actions on the part of the POP3 server. When the client has - issued the QUIT command, the session enters the UPDATE state. In - this state, the POP3 server releases any resources acquired during - the TRANSACTION state and says goodbye. The TCP connection is then - closed. - - A POP3 server MAY have an inactivity autologout timer. Such a timer - MUST be of at least 10 minutes' duration. The receipt of any command - from the client during that interval should suffice to reset the - autologout timer. When the timer expires, the session does NOT enter - - - -Myers & Rose [Page 3] - -RFC 1725 POP3 November 1994 - - - the UPDATE state--the server should close the TCP connection without - removing any messages or sending any response to the client. - -4. The AUTHORIZATION State - - Once the TCP connection has been opened by a POP3 client, the POP3 - server issues a one line greeting. This can be any string terminated - by CRLF. An example might be: - - S: +OK POP3 server ready - - Note that this greeting is a POP3 reply. The POP3 server should - always give a positive response as the greeting. - - The POP3 session is now in the AUTHORIZATION state. The client must - now identify and authenticate itself to the POP3 server. Two - possible mechanisms for doing this are described in this document, - the USER and PASS command combination and the APOP command. The APOP - command is described later in this document. - - To authenticate using the USER and PASS command combination, the - client must first issue the USER command. If the POP3 server - responds with a positive status indicator ("+OK"), then the client - may issue either the PASS command to complete the authentication, or - the QUIT command to terminate the POP3 session. If the POP3 server - responds with a negative status indicator ("-ERR") to the USER - command, then the client may either issue a new authentication - command or may issue the QUIT command. - - When the client issues the PASS command, the POP3 server uses the - argument pair from the USER and PASS commands to determine if the - client should be given access to the appropriate maildrop. - - Once the POP3 server has determined through the use of any - authentication command that the client should be given access to the - appropriate maildrop, the POP3 server then acquires an exclusive- - access lock on the maildrop, as necessary to prevent messages from - being modified or removed before the session enters the UPDATE state. - If the lock is successfully acquired, the POP3 server responds with a - positive status indicator. The POP3 session now enters the - TRANSACTION state, with no messages marked as deleted. If the the - maildrop cannot be opened for some reason (for example, a lock can - not be acquired, the client is denied access to the appropriate - maildrop, or the maildrop cannot be parsed), the POP3 server responds - with a negative status indicator. (If a lock was acquired but the - POP3 server intends to respond with a negative status indicator, the - POP3 server must release the lock prior to rejecting the command.) - After returning a negative status indicator, the server may close the - - - -Myers & Rose [Page 4] - -RFC 1725 POP3 November 1994 - - - connection. If the server does not close the connection, the client - may either issue a new authentication command and start again, or the - client may issue the QUIT command. - - After the POP3 server has opened the maildrop, it assigns a message- - number to each message, and notes the size of each message in octets. - The first message in the maildrop is assigned a message-number of - "1", the second is assigned "2", and so on, so that the n'th message - in a maildrop is assigned a message-number of "n". In POP3 commands - and responses, all message-number's and message sizes are expressed - in base-10 (i.e., decimal). - - Here are summaries for the three POP3 commands discussed thus far: - - USER name - - Arguments: - a string identifying a mailbox (required), which is of - significance ONLY to the server - - Restrictions: - may only be given in the AUTHORIZATION state after the POP3 - greeting or after an unsuccessful USER or PASS command - - Possible Responses: - +OK name is a valid mailbox - -ERR never heard of mailbox name - - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - ... - C: USER frated - S: -ERR sorry, no mailbox for frated here - - PASS string - - Arguments: - a server/mailbox-specific password (required) - - Restrictions: - may only be given in the AUTHORIZATION state after a - successful USER command - - Discussion: - Since the PASS command has exactly one argument, a POP3 - server may treat spaces in the argument as part of the - password, instead of as argument separators. - - - -Myers & Rose [Page 5] - -RFC 1725 POP3 November 1994 - - - Possible Responses: - +OK maildrop locked and ready - -ERR invalid password - -ERR unable to lock maildrop - - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: +OK mrose's maildrop has 2 messages (320 octets) - ... - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: -ERR maildrop already locked - - QUIT - - Arguments: none - - Restrictions: none - - Possible Responses: - +OK - - Examples: - C: QUIT - S: +OK dewey POP3 server signing off - -5. The TRANSACTION State - - Once the client has successfully identified itself to the POP3 server - and the POP3 server has locked and opened the appropriate maildrop, - the POP3 session is now in the TRANSACTION state. The client may now - issue any of the following POP3 commands repeatedly. After each - command, the POP3 server issues a response. Eventually, the client - issues the QUIT command and the POP3 session enters the UPDATE state. - - Here are the POP3 commands valid in the TRANSACTION state: - - STAT - - Arguments: none - - Restrictions: - may only be given in the TRANSACTION state - - - - - -Myers & Rose [Page 6] - -RFC 1725 POP3 November 1994 - - - Discussion: - The POP3 server issues a positive response with a line - containing information for the maildrop. This line is - called a "drop listing" for that maildrop. - - In order to simplify parsing, all POP3 servers required to - use a certain format for drop listings. The positive - response consists of "+OK" followed by a single space, the - number of messages in the maildrop, a single space, and the - size of the maildrop in octets. This memo makes no - requirement on what follows the maildrop size. Minimal - implementations should just end that line of the response - with a CRLF pair. More advanced implementations may - include other information. - - NOTE: This memo STRONGLY discourages implementations - from supplying additional information in the drop - listing. Other, optional, facilities are discussed - later on which permit the client to parse the messages - in the maildrop. - - Note that messages marked as deleted are not counted in - either total. - - Possible Responses: - +OK nn mm - - Examples: - C: STAT - S: +OK 2 320 - - LIST [msg] - - Arguments: - a message-number (optional), which, if present, may NOT - refer to a message marked as deleted - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - If an argument was given and the POP3 server issues a - positive response with a line containing information for - that message. This line is called a "scan listing" for - that message. - - If no argument was given and the POP3 server issues a - positive response, then the response given is multi-line. - - - -Myers & Rose [Page 7] - -RFC 1725 POP3 November 1994 - - - After the initial +OK, for each message in the maildrop, - the POP3 server responds with a line containing information - for that message. This line is also called a "scan - listing" for that message. - - In order to simplify parsing, all POP3 servers are required - to use a certain format for scan listings. A scan listing - consists of the message-number of the message, followed by - a single space and the exact size of the message in octets. - This memo makes no requirement on what follows the message - size in the scan listing. Minimal implementations should - just end that line of the response with a CRLF pair. More - advanced implementations may include other information, as - parsed from the message. - - NOTE: This memo STRONGLY discourages implementations - from supplying additional information in the scan - listing. Other, optional, facilities are discussed - later on which permit the client to parse the messages - in the maildrop. - - Note that messages marked as deleted are not listed. - - Possible Responses: - +OK scan listing follows - -ERR no such message - - Examples: - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - ... - C: LIST 2 - S: +OK 2 200 - ... - C: LIST 3 - S: -ERR no such message, only 2 messages in maildrop - - RETR msg - - Arguments: - a message-number (required) which may not refer to a - message marked as deleted - - Restrictions: - may only be given in the TRANSACTION state - - - -Myers & Rose [Page 8] - -RFC 1725 POP3 November 1994 - - - Discussion: - If the POP3 server issues a positive response, then the - response given is multi-line. After the initial +OK, the - POP3 server sends the message corresponding to the given - message-number, being careful to byte-stuff the termination - character (as with all multi-line responses). - - Possible Responses: - +OK message follows - -ERR no such message - - Examples: - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends the entire message here> - S: . - - DELE msg - - Arguments: - a message-number (required) which may not refer to a - message marked as deleted - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - The POP3 server marks the message as deleted. Any future - reference to the message-number associated with the message - in a POP3 command generates an error. The POP3 server does - not actually delete the message until the POP3 session - enters the UPDATE state. - - Possible Responses: - +OK message deleted - -ERR no such message - - Examples: - C: DELE 1 - S: +OK message 1 deleted - ... - C: DELE 2 - S: -ERR message 2 already deleted - - NOOP - - Arguments: none - - - - -Myers & Rose [Page 9] - -RFC 1725 POP3 November 1994 - - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - The POP3 server does nothing, it merely replies with a - positive response. - - Possible Responses: - +OK - - Examples: - C: NOOP - S: +OK - - RSET - - Arguments: none - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - If any messages have been marked as deleted by the POP3 - server, they are unmarked. The POP3 server then replies - with a positive response. - - Possible Responses: - +OK - - Examples: - C: RSET - S: +OK maildrop has 2 messages (320 octets) - -6. The UPDATE State - - When the client issues the QUIT command from the TRANSACTION state, - the POP3 session enters the UPDATE state. (Note that if the client - issues the QUIT command from the AUTHORIZATION state, the POP3 - session terminates but does NOT enter the UPDATE state.) - - If a session terminates for some reason other than a client-issued - QUIT command, the POP3 session does NOT enter the UPDATE state and - MUST not remove any messages from the maildrop. - - QUIT - - Arguments: none - - - - -Myers & Rose [Page 10] - -RFC 1725 POP3 November 1994 - - - Restrictions: none - - Discussion: - The POP3 server removes all messages marked as deleted from - the maildrop. It then releases any exclusive-access lock - on the maildrop and replies as to the status of these - operations. The TCP connection is then closed. - - Possible Responses: - +OK - - Examples: - C: QUIT - S: +OK dewey POP3 server signing off (maildrop empty) - ... - C: QUIT - S: +OK dewey POP3 server signing off (2 messages left) - ... - -7. Optional POP3 Commands - - The POP3 commands discussed above must be supported by all minimal - implementations of POP3 servers. - - The optional POP3 commands described below permit a POP3 client - greater freedom in message handling, while preserving a simple POP3 - server implementation. - - NOTE: This memo STRONGLY encourages implementations to support - these commands in lieu of developing augmented drop and scan - listings. In short, the philosophy of this memo is to put - intelligence in the part of the POP3 client and not the POP3 - server. - - TOP msg n - - Arguments: - a message-number (required) which may NOT refer to to a - message marked as deleted, and a non-negative number - (required) - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - If the POP3 server issues a positive response, then the - response given is multi-line. After the initial +OK, the - POP3 server sends the headers of the message, the blank - - - -Myers & Rose [Page 11] - -RFC 1725 POP3 November 1994 - - - line separating the headers from the body, and then the - number of lines indicated message's body, being careful to - byte-stuff the termination character (as with all multi- - line responses). - - Note that if the number of lines requested by the POP3 - client is greater than than the number of lines in the - body, then the POP3 server sends the entire message. - - Possible Responses: - +OK top of message follows - -ERR no such message - - Examples: - C: TOP 1 10 - S: +OK - S: <the POP3 server sends the headers of the - message, a blank line, and the first 10 lines - of the body of the message> - S: . - ... - C: TOP 100 3 - S: -ERR no such message - - UIDL [msg] - - Arguments: - a message-number (optionally) If a message-number is given, - it may NOT refer to a message marked as deleted. - - Restrictions: - may only be given in the TRANSACTION state. - - Discussion: - If an argument was given and the POP3 server issues a positive - response with a line containing information for that message. - This line is called a "unique-id listing" for that message. - - If no argument was given and the POP3 server issues a positive - response, then the response given is multi-line. After the - initial +OK, for each message in the maildrop, the POP3 server - responds with a line containing information for that message. - This line is called a "unique-id listing" for that message. - - In order to simplify parsing, all POP3 servers are required to - use a certain format for unique-id listings. A unique-id - listing consists of the message-number of the message, - followed by a single space and the unique-id of the message. - - - -Myers & Rose [Page 12] - -RFC 1725 POP3 November 1994 - - - No information follows the unique-id in the unique-id listing. - - The unique-id of a message is an arbitrary server-determined - string, consisting of characters in the range 0x21 to 0x7E, - which uniquely identifies a message within a maildrop and - which persists across sessions. The server should never reuse - an unique-id in a given maildrop, for as long as the entity - using the unique-id exists. - - Note that messages marked as deleted are not listed. - - Possible Responses: - +OK unique-id listing follows - -ERR no such message - - Examples: - C: UIDL - S: +OK - S: 1 whqtswO00WBw418f9t5JxYwZ - S: 2 QhdPYR:00WBw1Ph7x7 - S: . - ... - C: UIDL 2 - S: +OK 2 QhdPYR:00WBw1Ph7x7 - ... - C: UIDL 3 - S: -ERR no such message, only 2 messages in maildrop - - APOP name digest - - Arguments: - a string identifying a mailbox and a MD5 digest string - (both required) - - Restrictions: - may only be given in the AUTHORIZATION state after the POP3 - greeting - - Discussion: - Normally, each POP3 session starts with a USER/PASS - exchange. This results in a server/user-id specific - password being sent in the clear on the network. For - intermittent use of POP3, this may not introduce a sizable - risk. However, many POP3 client implementations connect to - the POP3 server on a regular basis -- to check for new - mail. Further the interval of session initiation may be on - the order of five minutes. Hence, the risk of password - capture is greatly enhanced. - - - -Myers & Rose [Page 13] - -RFC 1725 POP3 November 1994 - - - An alternate method of authentication is required which - provides for both origin authentication and replay - protection, but which does not involve sending a password - in the clear over the network. The APOP command provides - this functionality. - - A POP3 server which implements the APOP command will - include a timestamp in its banner greeting. The syntax of - the timestamp corresponds to the `msg-id' in [RFC822], and - MUST be different each time the POP3 server issues a banner - greeting. For example, on a UNIX implementation in which a - separate UNIX process is used for each instance of a POP3 - server, the syntax of the timestamp might be: - - <process-ID.clock@hostname> - - where `process-ID' is the decimal value of the process's - PID, clock is the decimal value of the system clock, and - hostname is the fully-qualified domain-name corresponding - to the host where the POP3 server is running. - - The POP3 client makes note of this timestamp, and then - issues the APOP command. The `name' parameter has - identical semantics to the `name' parameter of the USER - command. The `digest' parameter is calculated by applying - the MD5 algorithm [RFC1321] to a string consisting of the - timestamp (including angle-brackets) followed by a shared - secret. This shared secret is a string known only to the - POP3 client and server. Great care should be taken to - prevent unauthorized disclosure of the secret, as knowledge - of the secret will allow any entity to successfully - masquerade as the named user. The `digest' parameter - itself is a 16-octet value which is sent in hexadecimal - format, using lower-case ASCII characters. - - When the POP3 server receives the APOP command, it verifies - the digest provided. If the digest is correct, the POP3 - server issues a positive response, and the POP3 session - enters the TRANSACTION state. Otherwise, a negative - response is issued and the POP3 session remains in the - AUTHORIZATION state. - - Note that as the length of the shared secret increases, so - does the difficulty of deriving it. As such, shared - secrets should be long strings (considerably longer than - the 8-character example shown below). - - - - - -Myers & Rose [Page 14] - -RFC 1725 POP3 November 1994 - - - Possible Responses: - +OK maildrop locked and ready - -ERR permission denied - - Examples: - S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> - C: APOP mrose c4c9334bac560ecc979e58001b3e22fb - S: +OK maildrop has 1 message (369 octets) - - In this example, the shared secret is the string `tan- - staaf'. Hence, the MD5 algorithm is applied to the string - - <1896.697170952@dbc.mtview.ca.us>tanstaaf - - which produces a digest value of - - c4c9334bac560ecc979e58001b3e22fb - -8. POP3 Command Summary - - Minimal POP3 Commands: - - USER name valid in the AUTHORIZATION state - PASS string - QUIT - - STAT valid in the TRANSACTION state - LIST [msg] - RETR msg - DELE msg - NOOP - RSET - - QUIT valid in the UPDATE state - - Optional POP3 Commands: - - APOP name digest valid in the AUTHORIZATION state - - TOP msg n valid in the TRANSACTION state - UIDL [msg] - - POP3 Replies: - - +OK - -ERR - - - - - -Myers & Rose [Page 15] - -RFC 1725 POP3 November 1994 - - - Note that with the exception of the STAT, LIST, and UIDL commands, - the reply given by the POP3 server to any command is significant only - to "+OK" and "-ERR". Any text occurring after this reply may be - ignored by the client. - -9. Example POP3 Session - - S: <wait for connection on TCP port 110> - C: <open connection> - S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> - C: APOP mrose c4c9334bac560ecc979e58001b3e22fb - S: +OK mrose's maildrop has 2 messages (320 octets) - C: STAT - S: +OK 2 320 - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends message 1> - S: . - C: DELE 1 - S: +OK message 1 deleted - C: RETR 2 - S: +OK 200 octets - S: <the POP3 server sends message 2> - S: . - C: DELE 2 - S: +OK message 2 deleted - C: QUIT - S: +OK dewey POP3 server signing off (maildrop empty) - C: <close connection> - S: <wait for next connection> - -10. Message Format - - All messages transmitted during a POP3 session are assumed to conform - to the standard for the format of Internet text messages [RFC822]. - - It is important to note that the octet count for a message on the - server host may differ from the octet count assigned to that message - due to local conventions for designating end-of-line. Usually, - during the AUTHORIZATION state of the POP3 session, the POP3 server - can calculate the size of each message in octets when it opens the - maildrop. For example, if the POP3 server host internally represents - end-of-line as a single character, then the POP3 server simply counts - - - -Myers & Rose [Page 16] - -RFC 1725 POP3 November 1994 - - - each occurrence of this character in a message as two octets. Note - that lines in the message which start with the termination octet need - not be counted twice, since the POP3 client will remove all byte- - stuffed termination characters when it receives a multi-line - response. - -11. References - - [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC - 821, USC/Information Sciences Institute, August 1982. - - [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text - Messages", STD 11, RFC 822, University of Delaware, August 1982. - - [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, - MIT Laboratory for Computer Science, April, 1992. - -12. Security Considerations - - It is conjectured that use of the APOP command provides origin - identification and replay protection for a POP3 session. - Accordingly, a POP3 server which implements both the PASS and APOP - commands must not allow both methods of access for a given user; that - is, for a given "USER name" either the PASS or APOP command is - allowed, but not both. - - Further, note that as the length of the shared secret increases, so - does the difficulty of deriving it. - - Servers that answer -ERR to the USER command are giving potential - attackers clues about which names are valid - - Use of the PASS command sends passwords in the clear over the - network. - - Use of the RETR and TOP commands sends mail in the clear over the - network. - - Otherwise, security issues are not discussed in this memo. - -13. Acknowledgements - - The POP family has a long and checkered history. Although primarily - a minor revision to RFC 1460, POP3 is based on the ideas presented in - RFCs 918, 937, and 1081. - - In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff - provided significant comments on the APOP command. - - - -Myers & Rose [Page 17] - -RFC 1725 POP3 November 1994 - - -14. Authors' Addresses - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave - Pittsburgh, PA 15213 - - EMail: jgm+@cmu.edu - - - Marshall T. Rose - Dover Beach Consulting, Inc. - 420 Whisman Court - Mountain View, CA 94043-2186 - - EMail: mrose@dbc.mtview.ca.us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Rose [Page 18] - diff --git a/RFC/rfc1730.txt b/RFC/rfc1730.txt deleted file mode 100644 index fcf72ad7..00000000 --- a/RFC/rfc1730.txt +++ /dev/null @@ -1,4318 +0,0 @@ -
-
-
-
-
-
-Network Working Group M. Crispin
-Request for Comments: 1730 University of Washington
-Category: Standards Track December 1994
-
-
- INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
-
-
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-
-Abstract
-
- The Internet Message Access Protocol, Version 4 (IMAP4) allows a
- client to access and manipulate electronic mail messages on a server.
- IMAP4 permits manipulation of remote message folders, called
- "mailboxes", in a way that is functionally equivalent to local
- mailboxes. IMAP4 also provides the capability for an offline client
- to resynchronize with the server (see also [IMAP-DISC]).
-
- IMAP4 includes operations for creating, deleting, and renaming
- mailboxes; checking for new messages; permanently removing messages;
- setting and clearing flags; RFC 822 and MIME parsing; searching; and
- selective fetching of message attributes, texts, and portions
- thereof. Messages in IMAP4 are accessed by the use of numbers.
- These numbers are either message sequence numbers (relative position
- from 1 to the number of messages in the mailbox) or unique
- identifiers (immutable, strictly ascending values assigned to each
- message, but which are not necessarily contiguous).
-
- IMAP4 supports a single server. A mechanism for supporting multiple
- IMAP4 servers is discussed in [IMSP].
-
- IMAP4 does not specify a means of posting mail; this function is
- handled by a mail transfer protocol such as [SMTP].
-
- IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
- Compatibility issues are discussed in [IMAP-COMPAT].
-
-
-
-
-
-
-Crispin [Page i]
-
-RFC 1730 IMAP4 December 1994
-
-
-
-
-
-Table of Contents
-
-
-
-IMAP4 Protocol Specification ...................................... 1
-1. Organization of this Document ............................. 1
-1.1. How to Read This Document ................................. 1
-1.2. Conventions Used in this Document ......................... 1
-2. Protocol Overview ......................................... 1
-2.1. Link Level ................................................ 1
-2.2. Commands and Responses .................................... 1
-2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2
-2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2
-3. State and Flow Diagram .................................... 4
-3.1. Non-Authenticated State ................................... 4
-3.2. Authenticated State ....................................... 4
-3.3. Selected State ............................................ 4
-3.4. Logout State .............................................. 4
-4. Data Formats .............................................. 6
-4.1. Atom ...................................................... 6
-4.2. Number .................................................... 6
-4.3. String .................................................... 6
-4.3.1. 8-bit and Binary Strings .................................. 7
-4.4. Parenthesized List ........................................ 7
-4.5. NIL ....................................................... 7
-5. Operational Considerations ................................ 8
-5.1. Mailbox Naming ............................................ 8
-5.2. Mailbox Size and Message Status Updates ................... 8
-5.3. Response when no Command in Progress ...................... 8
-5.4. Autologout Timer .......................................... 9
-5.5. Multiple Commands in Progress ............................. 9
-6. Client Commands ........................................... 10
-6.1. Client Commands - Any State ............................... 10
-6.1.1. CAPABILITY Command ........................................ 10
-6.1.2. NOOP Command .............................................. 11
-6.1.3. LOGOUT Command ............................................ 11
-6.2. Client Commands - Non-Authenticated State ................. 12
-6.2.1. AUTHENTICATE Command ...................................... 12
-6.2.2. LOGIN Command ............................................. 14
-6.3. Client Commands - Authenticated State ..................... 14
-6.3.1. SELECT Command ............................................ 15
-6.3.2. EXAMINE Command ........................................... 16
-6.3.3. CREATE Command ............................................ 17
-6.3.4. DELETE Command ............................................ 18
-6.3.5. RENAME Command ............................................ 18
-
-
-
-Crispin [Page ii]
-
-RFC 1730 IMAP4 December 1994
-
-
-6.3.6. SUBSCRIBE Command ......................................... 19
-6.3.7. UNSUBSCRIBE Command ....................................... 19
-6.3.8. LIST Command .............................................. 20
-6.3.9. LSUB Command .............................................. 22
-6.3.10. APPEND Command ............................................ 22
-6.4. Client Commands - Selected State .......................... 23
-6.4.1. CHECK Command ............................................. 23
-6.4.2. CLOSE Command ............................................. 24
-6.4.3. EXPUNGE Command ........................................... 25
-6.4.4. SEARCH Command ............................................ 25
-6.4.5. FETCH Command ............................................. 29
-6.4.6. PARTIAL Command ........................................... 32
-6.4.7. STORE Command ............................................. 33
-6.4.8. COPY Command .............................................. 34
-6.4.9. UID Command ............................................... 35
-6.5. Client Commands - Experimental/Expansion .................. 37
-6.5.1. X<atom> Command ........................................... 37
-7. Server Responses .......................................... 38
-7.1. Server Responses - Status Responses ....................... 39
-7.1.1. OK Response ............................................... 40
-7.1.2. NO Response ............................................... 40
-7.1.3. BAD Response .............................................. 41
-7.1.4. PREAUTH Response .......................................... 41
-7.1.5. BYE Response .............................................. 41
-7.2. Server Responses - Server and Mailbox Status .............. 42
-7.2.1. CAPABILITY Response ....................................... 42
-7.2.2. LIST Response ............................................. 43
-7.2.3. LSUB Response ............................................. 44
-7.2.4. SEARCH Response ........................................... 44
-7.2.5. FLAGS Response ............................................ 44
-7.3. Server Responses - Message Status ......................... 45
-7.3.1. EXISTS Response ........................................... 45
-7.3.2. RECENT Response ........................................... 45
-7.3.3. EXPUNGE Response .......................................... 45
-7.3.4. FETCH Response ............................................ 46
-7.3.5. Obsolete Responses ........................................ 51
-7.4. Server Responses - Command Continuation Request ........... 51
-8. Sample IMAP4 session ...................................... 52
-9. Formal Syntax ............................................. 53
-10. Author's Note ............................................. 64
-11. Security Considerations ................................... 64
-12. Author's Address .......................................... 64
-Appendices ........................................................ 65
-A. Obsolete Commands ......................................... 65
-A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65
-A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65
-A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66
-A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66
-
-
-
-Crispin [Page iii]
-
-RFC 1730 IMAP4 December 1994
-
-
-B. Obsolete Responses ........................................ 68
-B.7.2.OBS.1. MAILBOX Response .................................. 68
-B.7.3.OBS.1. COPY Response ..................................... 68
-B.7.3.OBS.2. STORE Response .................................... 69
-C. References ................................................ 70
-E. IMAP4 Keyword Index ....................................... 71
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page iv]
-
-RFC 1730 IMAP4 December 1994
-
-
-IMAP4 Protocol Specification
-
-1. Organization of this Document
-
-1.1. How to Read This Document
-
- This document is written from the point of view of the implementor of
- an IMAP4 client or server. Beyond the protocol overview in section
- 2, it is not optimized for someone trying to understand the operation
- of the protocol. The material in sections 3 through 5 provides the
- general context and definitions with which IMAP4 operates.
-
- Sections 6, 7, and 9 describe the IMAP commands, responses, and
- syntax, respectively. The relationships among these are such that it
- is almost impossible to understand any of them separately. In
- particular, one should not attempt to deduce command syntax from the
- command section alone; one should instead refer to the formal syntax
- section.
-
-
-1.2. Conventions Used in this Document
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
-
-2. Protocol Overview
-
-2.1. Link Level
-
- The IMAP4 protocol assumes a reliable data stream such as provided by
- TCP. When TCP is used, an IMAP4 server listens on port 143.
-
-
-2.2. Commands and Responses
-
- An IMAP4 session consists of the establishment of a client/server
- connection, an initial greeting from the server, and client/server
- interactions. These client/server interactions consist of a client
- command, server data, and a server completion result response.
-
- All interactions transmitted by client and server are in the form of
- lines; that is, strings that end with a CRLF. The protocol receiver
- of an IMAP4 client or server is either reading a line, or is reading
- a sequence of octets with a known count followed by a line.
-
-
-
-
-
-
-Crispin [Page 1]
-
-RFC 1730 IMAP4 December 1994
-
-
-2.2.1. Client Protocol Sender and Server Protocol Receiver
-
- The client command begins an operation. Each client command is
- prefixed with a identifier (typically a short alphanumeric string,
- e.g. A0001, A0002, etc.) called a "tag". A different tag is
- generated by the client for each command.
-
- There are two cases in which a line from the client does not
- represent a complete command. In one case, a command argument is
- quoted with an octet count (see the description of literal in String
- under Data Formats); in the other case, the command arguments require
- server feedback (see the AUTHENTICATE command). In either case, the
- server sends a command continuation request response if it is ready
- for the octets (if appropriate) and the remainder of the command.
- This response is prefixed with the token "+".
-
- Note: If, instead, the server detected an error in the
- command, it sends a BAD completion response with tag
- matching the command (as described below) to reject the
- command and prevent the client from sending any more of the
- command.
-
- It is also possible for the server to send a completion
- response for some other command (if multiple commands are
- in progress), or untagged data. In either case, the
- command continuation request is still pending; the client
- takes the appropriate action for the response, and reads
- another response from the server.
-
- The protocol receiver of an IMAP4 server reads a command line from
- the client, parses the command and its arguments, and transmits
- server data and a server command completion result response.
-
-
-2.2.2. Server Protocol Sender and Client Protocol Receiver
-
- Data transmitted by the server to the client and status responses
- that do not indicate command completion are prefixed with the token
- "*", and are called untagged responses.
-
- Server data may be sent as a result of a client command, or may be
- sent unilaterally by the server. There is no syntactic difference
- between server data that resulted from a specific command and server
- data that were sent unilaterally.
-
- The server completion result response indicates the success or
- failure of the operation. It is tagged with the same tag as the
- client command which began the operation. Thus, if more than one
-
-
-
-Crispin [Page 2]
-
-RFC 1730 IMAP4 December 1994
-
-
- command is in progress, the tag in a server completion response
- identifies the command to which the response applies. There are
- three possible server completion responses: OK (indicating success),
- NO (indicating failure), or BAD (indicating protocol error such as
- unrecognized command or command syntax error).
-
- The protocol receiver of an IMAP4 client reads a response line from
- the server. It then takes action on the response based upon the
- first token of the response, which may be a tag, a "*", or a "+". As
- described above.
-
- A client MUST be prepared to accept any server response at all times.
- This includes server data that it may not have requested. Server
- data SHOULD be recorded, so that the client can reference its
- recorded copy rather than sending a command to the server to request
- the data. In the case of certain server data, recording the data is
- mandatory.
-
- This topic is discussed in greater detail in the Server Responses
- section.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 3]
-
-RFC 1730 IMAP4 December 1994
-
-
-3. State and Flow Diagram
-
- An IMAP4 server is in one of four states. Most commands are valid in
- only certain states. It is a protocol error for the client to
- attempt a command while the command is in an inappropriate state. In
- this case, a server will respond with a BAD or NO (depending upon
- server implementation) command completion result.
-
-
-3.1. Non-Authenticated State
-
- In non-authenticated state, the user must supply authentication
- credentials before most commands will be permitted. This state is
- entered when a connection starts unless the connection has been
- pre-authenticated.
-
-
-3.2. Authenticated State
-
- In authenticated state, the user is authenticated and must select a
- mailbox to access before commands that affect messages will be
- permitted. This state is entered when a pre-authenticated connection
- starts, when acceptable authentication credentials have been
- provided, or after an error in selecting a mailbox.
-
-
-3.3. Selected State
-
- In selected state, a mailbox has been selected to access. This state
- is entered when a mailbox has been successfully selected.
-
-
-3.4. Logout State
-
- In logout state, the session is being terminated, and the server will
- close the connection. This state can be entered as a result of a
- client request or by unilateral server decision.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 4]
-
-RFC 1730 IMAP4 December 1994
-
-
- +--------------------------------------+
- |initial connection and server greeting|
- +--------------------------------------+
- || (1) || (2) || (3)
- VV || ||
- +-----------------+ || ||
- |non-authenticated| || ||
- +-----------------+ || ||
- || (7) || (4) || ||
- || VV VV ||
- || +----------------+ ||
- || | authenticated |<=++ ||
- || +----------------+ || ||
- || || (7) || (5) || (6) ||
- || || VV || ||
- || || +--------+ || ||
- || || |selected|==++ ||
- || || +--------+ ||
- || || || (7) ||
- VV VV VV VV
- +--------------------------------------+
- | logout and close connection |
- +--------------------------------------+
-
- (1) connection without pre-authentication (OK greeting)
- (2) pre-authenticated connection (PREAUTH greeting)
- (3) rejected connection (BYE greeting)
- (4) successful LOGIN or AUTHENTICATE command
- (5) successful SELECT or EXAMINE command
- (6) CLOSE command, or failed SELECT or EXAMINE command
- (7) LOGOUT command, server shutdown, or connection closed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 5]
-
-RFC 1730 IMAP4 December 1994
-
-
-4. Data Formats
-
- IMAP4 uses textual commands and responses. Data in IMAP4 can be in
- one of several forms: atom, number, string, parenthesized list, or
- NIL.
-
-
-4.1. Atom
-
- An atom consists of one or more non-special characters.
-
-
-4.2. Number
-
- A number consists of one or more digit characters, and represents a
- numeric value.
-
-
-4.3. String
-
- A string is in one of two forms: literal and quoted string. The
- literal form is the general form of string. The quoted string form
- is an alternative that avoids the overhead of processing a literal at
- the cost of restrictions of what may be in a quoted string.
-
- A literal is a sequence of zero or more octets (including CR and LF),
- prefix-quoted with an octet count in the form of an open brace ("{"),
- the number of octets, close brace ("}"), and CRLF. In the case of
- literals transmitted from server to client, the CRLF is immediately
- followed by the octet data. In the case of literals transmitted from
- client to server, the client must wait to receive a command
- continuation request (described later in this document) before
- sending the octet data (and the remainder of the command).
-
- A quoted string is a sequence of zero or more 7-bit characters,
- excluding CR and LF, with double quote (<">) characters at each end.
-
- The empty string is respresented as either "" (a quoted string with
- zero characters between double quotes) or as {0} followed by CRLF (a
- literal with an octet count of 0).
-
- Note: Even if the octet count is 0, a client transmitting a
- literal must wait to receive a command continuation
- request.
-
-
-
-
-
-
-
-Crispin [Page 6]
-
-RFC 1730 IMAP4 December 1994
-
-
-4.3.1. 8-bit and Binary Strings
-
- 8-bit textual and binary mail is supported through the use of
- [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or
- multi-octet characters in literals, but should do so only when the
- character set is identified.
-
- Although a BINARY body encoding is defined, unencoded binary strings
- are not permitted. A "binary string" is any string with NUL
- characters. Implementations MUST encode binary data into a textual
- form such as BASE64 before transmitting the data. A string with an
- excessive amount of CTL characters may also be considered to be
- binary, although this is not required.
-
-
-4.4. Parenthesized List
-
- Data structures are represented as a "parenthesized list"; a sequence
- of data items, delimited by space, and bounded at each end by
- parentheses. A parenthesized list may itself contain other
- parenthesized lists, using multiple levels of parentheses to indicate
- nesting.
-
- The empty list is represented as () -- a parenthesized list with no
- members.
-
-
-4.5. NIL
-
- The special atom "NIL" represents the non-existence of a particular
- data item that is represented as a string or parenthesized list, as
- distinct from the empty string "" or the empty parenthesized list ().
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 7]
-
-RFC 1730 IMAP4 December 1994
-
-
-5. Operational Considerations
-
-5.1. Mailbox Naming
-
- The interpretation of mailbox names is implementation-dependent.
- However, the mailbox name INBOX is a special name reserved to mean
- "the primary mailbox for this user on this server". If it is desired
- to export hierarchical mailbox names, mailbox names must be
- left-to-right hierarchical using a single character to separate
- levels of hierarchy. The same hierarchy separator character is used
- for all levels of hierarchy within a single name.
-
-5.2. Mailbox Size and Message Status Updates
-
- At any time, a server can send data that the client did not request.
- Sometimes, such behavior is required. For example, agents other than
- the server may add messages to the mailbox (e.g. new mail delivery),
- change the flags of message in the mailbox (e.g. simultaneous access
- to the same mailbox by multiple agents), or even remove messages from
- the mailbox. A server MUST send mailbox size updates automatically
- if a mailbox size change is observed during the processing of a
- command. A server SHOULD send message flag updates automatically,
- without requiring the client to request such updates explicitly.
- Special rules exist for server notification of a client about the
- removal of messages to prevent synchronization errors; see the
- description of the EXPUNGE response for more details.
-
- Regardless of what implementation decisions a client may take on
- remembering data from the server, a client implementation MUST record
- mailbox size updates. It MUST NOT assume that any command after
- initial mailbox selection will return the size of the mailbox.
-
-
-5.3. Response when no Command in Progress
-
- Server implementations are permitted to send an untagged response
- (except for EXPUNGE) while there is no command in progress. Server
- implementations that send such responses MUST deal with flow control
- considerations. Specifically, they must either (1) verify that the
- size of the data does not exceed the underlying transport's available
- window size, or (2) use non-blocking writes.
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 8]
-
-RFC 1730 IMAP4 December 1994
-
-
-5.4. Autologout Timer
-
- If a server has an inactivity autologout timer, that timer MUST be of
- at least 30 minutes' duration. The receipt of ANY command from the
- client during that interval should suffice to reset the autologout
- timer.
-
-
-5.5. Multiple Commands in Progress
-
- The client is not required to wait for the completion result response
- of a command before sending another command, subject to flow control
- constraints on the underlying data stream. Similarly, a server is
- not required to process a command to completion before beginning
- processing of the next command, unless an ambiguity would result
- because of a command that would affect the results of other commands.
- If there is such an ambiguity, the server executes commands to
- completion in the order given by the client.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 9]
-
-RFC 1730 IMAP4 December 1994
-
-
-6. Client Commands
-
- IMAP4 commands are described in this section. Commands are organized
- by the state in which the command is permitted. Commands which are
- permitted in multiple states are listed in the minimum permitted
- state (for example, commands valid in authenticated and selected
- state are listed in the authenticated state commands).
-
- Command arguments, identified by "Arguments:" in the command
- descriptions below, are described by function, not by syntax. The
- precise syntax of command arguments is described in the Formal Syntax
- section.
-
- Some commands cause specific server data to be returned; these are
- identified by "Data:" in the command descriptions below. See the
- response descriptions in the Responses section for information on
- these responses, and the Formal Syntax section for the precise syntax
- of these responses. It is possible for server data to be transmitted
- as a result of any command; thus, commands that do not specifically
- require server data specify "no specific data for this command"
- instead of "none".
-
- The "Result:" in the command description refers to the possible
- tagged status responses to a command, and any special interpretation
- of these status responses.
-
-
-6.1. Client Commands - Any State
-
- The following commands are valid in any state: CAPABILITY, NOOP, and
- LOGOUT.
-
-6.1.1. CAPABILITY Command
-
- Arguments: none
-
- Data: mandatory untagged response: CAPABILITY
-
- Result: OK - capability completed
- BAD - command unknown or arguments invalid
-
- The CAPABILITY command requests a listing of capabilities that the
- server supports. The server MUST send a single untagged
- CAPABILITY response with "IMAP4" as the first listed capability
- before the (tagged) OK response. This listing of capabilities is
- not dependent upon connection state or user. It is therefore not
- necessary to issue a CAPABILITY command more than once in a
- session.
-
-
-
-Crispin [Page 10]
-
-RFC 1730 IMAP4 December 1994
-
-
- Capability names other than "IMAP4" refer to extensions,
- revisions, or amendments to this specification. See the
- documentation of the CAPABILITY response for additional
- information. No capabilities are enabled without explicit client
- action to invoke the capability. See the section entitled "Client
- Commands - Experimental/Expansion" for information about the form
- of site or implementation-specific capabilities.
-
- Example: C: abcd CAPABILITY
- S: * CAPABILITY IMAP4
- S: abcd OK CAPABILITY completed
-
-
-6.1.2. NOOP Command
-
- Arguments: none
-
- Data: no specific data for this command (but see below)
-
- Result: OK - noop completed
- BAD - command unknown or arguments invalid
-
- The NOOP command always succeeds. It does nothing.
-
- Since any command can return a status update as untagged data, the
- NOOP command can be used as a periodic poll for new messages or
- message status updates during a period of inactivity. The NOOP
- command can also be used to reset any inactivity autologout timer
- on the server.
-
- Example: C: a002 NOOP
- S: a002 OK NOOP completed
- . . .
- C: a047 NOOP
- S: * 22 EXPUNGE
- S: * 23 EXISTS
- S: * 3 RECENT
- S: * 14 FETCH (FLAGS (\Seen \Deleted))
- S: a047 OK NOOP completed
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 11]
-
-RFC 1730 IMAP4 December 1994
-
-
-6.1.3. LOGOUT Command
-
- Arguments: none
-
- Data: mandatory untagged response: BYE
-
- Result: OK - logout completed
- BAD - command unknown or arguments invalid
-
- The LOGOUT command informs the server that the client is done with
- the session. The server must send a BYE untagged response before
- the (tagged) OK response, and then close the network connection.
-
- Example: C: A023 LOGOUT
- S: * BYE IMAP4 Server logging out
- S: A023 OK LOGOUT completed
- (Server and client then close the connection)
-
-
-
-6.2. Client Commands - Non-Authenticated State
-
- In non-authenticated state, the AUTHENTICATE or LOGIN command
- establishes authentication and enter authenticated state. The
- AUTHENTICATE command provides a general mechanism for a variety of
- authentication techniques, whereas the LOGIN command uses the
- traditional user name and plaintext password pair.
-
- Server implementations may allow non-authenticated access to certain
- mailboxes. The convention is to use a LOGIN command with the userid
- "anonymous". A password is required. It is implementation-dependent
- what requirements, if any, are placed on the password and what access
- restrictions are placed on anonymous users.
-
- Once authenticated (including as anonymous), it is not possible to
- re-enter non-authenticated state.
-
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
- the following commands are valid in non-authenticated state:
- AUTHENTICATE and LOGIN.
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 12]
-
-RFC 1730 IMAP4 December 1994
-
-
-6.2.1. AUTHENTICATE Command
-
- Arguments: authentication mechanism name
-
- Data: continuation data may be requested
-
- Result: OK - authenticate completed, now in authenticated state
- NO - authenticate failure: unsupported authentication
- mechanism, credentials rejected
- BAD - command unknown or arguments invalid,
- authentication exchange cancelled
-
- The AUTHENTICATE command indicates an authentication mechanism,
- such as described in [IMAP-AUTH], to the server. If the server
- supports the requested authentication mechanism, it performs an
- authentication protocol exchange to authenticate and identify the
- user. Optionally, it also negotiates a protection mechanism for
- subsequent protocol interactions. If the requested authentication
- mechanism is not supported, the server should reject the
- AUTHENTICATE command by sending a tagged NO response.
-
- The authentication protocol exchange consists of a series of
- server challenges and client answers that are specific to the
- authentication mechanism. A server challenge consists of a
- command continuation request response with the "+" token followed
- by a BASE64 encoded string. The client answer consists of a line
- consisting of a BASE64 encoded string. If the client wishes to
- cancel an authentication exchange, it should issue a line with a
- single "*". If the server receives such an answer, it must reject
- the AUTHENTICATE command by sending a tagged BAD response.
-
- A protection mechanism provides integrity and privacy protection
- to the protocol session. If a protection mechanism is negotiated,
- it is applied to all subsequent data sent over the connection.
- The protection mechanism takes effect immediately following the
- CRLF that concludes the authentication exchange for the client,
- and the CRLF of the tagged OK response for the server. Once the
- protection mechanism is in effect, the stream of command and
- response octets is processed into buffers of ciphertext. Each
- buffer is transferred over the connection as a stream of octets
- prepended with a four octet field in network byte order that
- represents the length of the following data. The maximum
- ciphertext buffer length is defined by the protection mechanism.
-
- The server is not required to support any particular
- authentication mechanism, nor are authentication mechanisms
- required to support any protection mechanisms. If an AUTHENTICATE
- command fails with a NO response, the client may try another
-
-
-
-Crispin [Page 13]
-
-RFC 1730 IMAP4 December 1994
-
-
- authentication mechanism by issuing another AUTHENTICATE command,
- or may attempt to authenticate by using the LOGIN command. In
- other words, the client may request authentication types in
- decreasing order of preference, with the LOGIN command as a last
- resort.
-
- Example: S: * OK KerberosV4 IMAP4 Server
- C: A001 AUTHENTICATE KERBEROS_V4
- S: + AmFYig==
- C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
- +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
- WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
- S: + or//EoAADZI=
- C: DiAF5A4gA+oOIALuBkAAmw==
- S: A001 OK Kerberos V4 authentication successful
-
- Note: the line breaks in the first client answer are for
- editorial clarity and are not in real authenticators.
-
-
-6.2.2. LOGIN Command
-
- Arguments: user name
- password
-
- Data: no specific data for this command
-
- Result: OK - login completed, now in authenticated state
- NO - login failure: user name or password rejected
- BAD - command unknown or arguments invalid
-
- The LOGIN command identifies the user to the server and carries
- the plaintext password authenticating this user.
-
- Example: C: a001 LOGIN SMITH SESAME
- S: a001 OK LOGIN completed
-
-
-
-6.3. Client Commands - Authenticated State
-
- In authenticated state, commands that manipulate mailboxes as atomic
- entities are permitted. Of these commands, the SELECT and EXAMINE
- commands will select a mailbox for access and enter selected state.
-
-
-
-
-
-
-
-Crispin [Page 14]
-
-RFC 1730 IMAP4 December 1994
-
-
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
- the following commands are valid in authenticated state: SELECT,
- EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
- and APPEND.
-
-6.3.1. SELECT Command
-
- Arguments: mailbox name
-
- Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
- optional OK untagged responses: UNSEEN, PERMANENTFLAGS
-
- Result: OK - select completed, now in selected state
- NO - select failure, now in authenticated state: no
- such mailbox, can't access mailbox
- BAD - command unknown or arguments invalid
-
- The SELECT command selects a mailbox so that messages in the
- mailbox can be accessed. Before returning an OK to the client,
- the server MUST send the following untagged data to the client:
-
- FLAGS Defined flags in the mailbox
-
- <n> EXISTS The number of messages in the mailbox
-
- <n> RECENT The number of messages added to the mailbox since
- the previous time this mailbox was read
-
- OK [UIDVALIDITY <n>]
- The unique identifier validity value. See the
- description of the UID command for more detail.
-
- to define the initial state of the mailbox at the client. If it
- is not possible to determine the messages that were added since
- the previous time a mailbox was read, then all messages SHOULD be
- considered recent.
-
- The server SHOULD also send an UNSEEN response code in an OK
- untagged response, indicating the message sequence number of the
- first unseen message in the mailbox.
-
- If the client can not change the permanent state of one or more of
- the flags listed in the FLAGS untagged response, the server SHOULD
- send a PERMANENTFLAGS response code in an OK untagged response,
- listing the flags that the client may change permanently.
-
- Only one mailbox may be selected at a time in a session;
- simultaneous access to multiple mailboxes requires multiple
-
-
-
-Crispin [Page 15]
-
-RFC 1730 IMAP4 December 1994
-
-
- sessions. The SELECT command automatically deselects any
- currently selected mailbox before attempting the new selection.
- Consequently, if a mailbox is selected and a SELECT command that
- fails is attempted, no mailbox is selected.
-
- If the user is permitted to modify the mailbox, the server SHOULD
- prefix the text of the tagged OK response with the "[READ-WRITE]"
- response code.
-
- If the user is not permitted to modify the mailbox but is
- permitted read access, the mailbox is selected as read-only, and
- the server MUST prefix the text of the tagged OK response to
- SELECT with the "[READ-ONLY]" response code. Read-only access
- through SELECT differs from the EXAMINE command in that certain
- read-only mailboxes may permit the change of permanent state on a
- per-user (as opposed to global) basis. Netnews messages marked in
- a user's .newsrc file are an example of such per-user permanent
- state that can be modified with read-only mailboxes.
-
- Example: C: A142 SELECT INBOX
- S: * 172 EXISTS
- S: * 1 RECENT
- S: * OK [UNSEEN 12] Message 12 is first unseen
- S: * OK [UIDVALIDITY 3857529045] UIDs valid
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
- S: A142 OK [READ-WRITE] SELECT completed
-
-
-6.3.2. EXAMINE Command
-
- Arguments: mailbox name
-
- Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
- optional OK untagged responses: UNSEEN, PERMANENTFLAGS
-
- Result: OK - examine completed, now in selected state
- NO - examine failure, now in authenticated state: no
- such mailbox, can't access mailbox
- BAD - command unknown or arguments invalid
-
- The EXAMINE command is identical to SELECT and returns the same
- output; however, the selected mailbox is identified as read-only.
- No changes to the permanent state of the mailbox, including
- per-user state, are permitted.
-
-
-
-
-
-
-Crispin [Page 16]
-
-RFC 1730 IMAP4 December 1994
-
-
- The text of the tagged OK response to the EXAMINE command MUST
- begin with the "[READ-ONLY]" response code.
-
- Example: C: A932 EXAMINE blurdybloop
- S: * 17 EXISTS
- S: * 2 RECENT
- S: * OK [UNSEEN 8] Message 8 is first unseen
- S: * OK [UIDVALIDITY 3857529045] UIDs valid
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
- S: A932 OK [READ-ONLY] EXAMINE completed
-
-
-6.3.3. CREATE Command
-
- Arguments: mailbox name
-
- Data: no specific data for this command
-
- Result: OK - create completed
- NO - create failure: can't create mailbox with that name
- BAD - command unknown or arguments invalid
-
- The CREATE command creates a mailbox with the given name. An OK
- response is returned only if a new mailbox with that name has been
- created. It is an error to attempt to create INBOX or a mailbox
- with a name that refers to an extant mailbox. Any error in
- creation will return a tagged NO response.
-
- If the mailbox name is suffixed with the server's hierarchy
- separator character (as returned from the server by a LIST
- command), this is a declaration that the client may, in the
- future, create mailbox names under this name in the hierarchy.
- Server implementations that do not require this declaration MUST
- ignore it.
-
- If a new mailbox is created with the same name as a mailbox which
- was deleted, its unique identifiers MUST be greater than any
- unique identifiers used in the previous incarnation of the mailbox
- UNLESS the new incarnation has a different unique identifier
- validity value. See the description of the UID command for more
- detail.
-
- Example: C: A003 CREATE owatagusiam/
- S: A003 OK CREATE completed
- C: A004 CREATE owatagusiam/blurdybloop
- S: A004 OK CREATE completed
-
-
-
-
-Crispin [Page 17]
-
-RFC 1730 IMAP4 December 1994
-
-
- Note: the interpretation of this example depends on whether
- "/" was returned as the hierarchy separator from LIST. If
- "/" is the hierarchy separator, a new level of hierarchy
- named "owatagusiam" with a member called "blurdybloop" is
- created. Otherwise, two mailboxes at the same hierarchy
- level are created.
-
-
-6.3.4. DELETE Command
-
- Arguments: mailbox name
-
- Data: no specific data for this command
-
- Result: OK - delete completed
- NO - delete failure: can't delete mailbox with that name
- BAD - command unknown or arguments invalid
-
- The DELETE command permanently removes the mailbox with the given
- name. A tagged OK response is returned only if the mailbox has
- been deleted. It is an error to attempt to delete INBOX or a
- mailbox name that does not exist. Any error in deletion will
- return a tagged NO response.
-
- The value of the highest-used unique indentifier of the deleted
- mailbox MUST be preserved so that a new mailbox created with the
- same name will not reuse the identifiers of the former
- incarnation, UNLESS the new incarnation has a different unique
- identifier validity value. See the description of the UID command
- for more detail.
-
- Example: C: A683 DELETE blurdybloop
- S: A683 OK DELETE completed
-
-
-6.3.5. RENAME Command
-
- Arguments: existing mailbox name
- new mailbox name
-
- Data: no specific data for this command
-
- Result: OK - rename completed
- NO - rename failure: can't rename mailbox with that name,
- can't rename to mailbox with that name
- BAD - command unknown or arguments invalid
-
-
-
-
-
-Crispin [Page 18]
-
-RFC 1730 IMAP4 December 1994
-
-
- The RENAME command changes the name of a mailbox. A tagged OK
- response is returned only if the mailbox has been renamed. It is
- an error to attempt to rename from a mailbox name that does not
- exist or to a mailbox name that already exists. Any error in
- renaming will return a tagged NO response.
-
- Renaming INBOX is permitted; a new, empty INBOX is created in its
- place.
-
- Example: C: Z4S9 RENAME blurdybloop owatagusiam
- S: Z4S9 OK RENAME completed
-
-
-6.3.6. SUBSCRIBE Command
-
- Arguments: mailbox
-
- Data: no specific data for this command
-
- Result: OK - subscribe completed
- NO - subscribe failure: can't subscribe to that name
- BAD - command unknown or arguments invalid
-
- The SUBSCRIBE command adds the specified mailbox name to the
- server's set of "active" or "subscribed" mailboxes as returned by
- the LSUB command. This command returns a tagged OK response only
- if the subscription is successful.
-
- Example: C: A002 SUBSCRIBE #news.comp.mail.mime
- S: A002 OK SUBSCRIBE completed
-
-
-6.3.7. UNSUBSCRIBE Command
-
- Arguments: mailbox name
-
- Data: no specific data for this command
-
- Result: OK - unsubscribe completed
- NO - unsubscribe failure: can't unsubscribe that name
- BAD - command unknown or arguments invalid
-
- The UNSUBSCRIBE command removes the specified mailbox name from
- the server's set of "active" or "subscribed" mailboxes as returned
- by the LSUB command. This command returns a tagged OK response
- only if the unsubscription is successful.
-
-
-
-
-
-Crispin [Page 19]
-
-RFC 1730 IMAP4 December 1994
-
-
- Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
- S: A002 OK UNSUBSCRIBE completed
-
-
-6.3.8. LIST Command
-
- Arguments: reference name
- mailbox name with possible wildcards
-
- Data: untagged responses: LIST
-
- Result: OK - list completed
- NO - list failure: can't list that reference or name
- BAD - command unknown or arguments invalid
-
- The LIST command returns a subset of names from the complete set
- of all names available to the user. Zero or more untagged LIST
- replies are returned, containing the name attributes, hierarchy
- delimiter, and name; see the description of the LIST reply for
- more detail.
-
- An empty ("" string) reference name argument indicates that the
- mailbox name is interpreted as by SELECT. The returned mailbox
- names MUST match the supplied mailbox name pattern. A non-empty
- reference name argument is the name of a mailbox or a level of
- mailbox hierarchy, and indicates a context in which the mailbox
- name is interpreted in an implementation-defined manner.
-
- The reference and mailbox name arguments are interpreted, in an
- implementation-dependent fashion, into a canonical form that
- represents an unambiguous left-to-right hierarchy. The returned
- mailbox names will be in the interpreted form.
-
- Any part of the reference argument that is included in the
- interpreted form SHOULD prefix the interpreted form. It should
- also be in the same form as the reference name argument. This
- rule permits the client to determine if the returned mailbox name
- is in the context of the reference argument, or if something about
- the mailbox argument overrode the reference argument. Without
- this rule, the client would have to have knowledge of the server's
- naming semantics including what characters are "breakouts" that
- override a naming context.
-
-
-
-
-
-
-
-
-
-Crispin [Page 20]
-
-RFC 1730 IMAP4 December 1994
-
-
- For example, here are some examples of how references
- and mailbox names might be interpreted on a UNIX-based
- server:
-
- Reference Mailbox Name Interpretation
- ------------ ------------ --------------
- ~smith/Mail/ foo.* ~smith/Mail/foo.*
- archive/ % archive/%
- #news. comp.mail.* #news.comp.mail.*
- ~smith/Mail/ /usr/doc/foo /usr/doc/foo
- archive/ ~fred/Mail/* ~fred/Mail/*
-
- The first three examples demonstrate interpretations in
- the context of the reference argument. Note that
- "~smith/Mail" should not be transformed into something
- like "/u2/users/smith/Mail", or it would be impossible
- for the client to determine that the interpretation was
- in the context of the reference.
-
- The character "*" is a wildcard, and matches zero or more
- characters at this position. The character "%" is similar to "*",
- but it does not match a hierarchy delimiter. If the "%" wildcard
- is the last character of a mailbox name argument, matching levels
- of hierarchy are also returned. If these levels of hierarchy are
- not also selectable mailboxes, they are returned with the
- \Noselect mailbox name attribute (see the description of the LIST
- response for more detail).
-
- Server implementations are permitted to "hide" otherwise
- accessible mailboxes from the wildcard characters, by preventing
- certain characters or names from matching a wildcard in certain
- situations. For example, a UNIX-based server might restrict the
- interpretation of "*" so that an initial "/" character does not
- match.
-
- The special name INBOX is included in the output from LIST if it
- matches the input arguments and INBOX is supported by this server
- for this user. The criteria for omitting INBOX is whether SELECT
- INBOX will return failure; it is not relevant whether the user's
- real INBOX resides on this or some other server.
-
- Example: C: A002 LIST "~/Mail/" "%"
- S: * LIST (\Noselect) "/" ~/Mail/foo
- S: * LIST () "/" ~/Mail/meetings
- S: A002 OK LIST completed
-
-
-
-
-
-
-Crispin [Page 21]
-
-RFC 1730 IMAP4 December 1994
-
-
-6.3.9. LSUB Command
-
- Arguments: reference name
- mailbox name with possible wildcards
-
- Data: untagged responses: LSUB
-
- Result: OK - lsub completed
- NO - lsub failure: can't list that reference or name
- BAD - command unknown or arguments invalid
-
- The LSUB command returns a subset of names from the set of names
- that the user has declared as being "active" or "subscribed".
- Zero or more untagged LSUB replies are returned. The arguments to
- LSUB are in the same form as those for LIST.
-
- Example: C: A002 LSUB "#news." "comp.mail.*"
- S: * LSUB () "." #news.comp.mail.mime
- S: * LSUB () "." #news.comp.mail.misc
- S: A002 OK LSUB completed
-
-
-6.3.10. APPEND Command
-
- Arguments: mailbox name
- optional flag parenthesized list
- optional date/time string
- message literal
-
- Data: no specific data for this command
-
- Result: OK - append completed
- NO - append error: can't append to that mailbox, error
- in flags or date/time or message text
- BAD - command unknown or arguments invalid
-
- The APPEND command appends the literal argument as a new message
- in the specified destination mailbox. This argument is in the
- format of an [RFC-822] message. 8-bit characters are permitted in
- the message. A server implementation that is unable to preserve
- 8-bit data properly MUST be able to reversibly convert 8-bit
- APPEND data to 7-bit using [MIME-1] encoding.
-
- If a flag parenthesized list or date_time are specified, that data
- SHOULD be set in the resulting message; otherwise, the defaults of
- empty flags and the current date/time are used.
-
-
-
-
-
-Crispin [Page 22]
-
-RFC 1730 IMAP4 December 1994
-
-
- If the append is unsuccessful for any reason, the mailbox MUST be
- restored to its state before the APPEND attempt; no partial
- appending is permitted. If the mailbox is currently selected, the
- normal new mail actions should occur.
-
- If the destination mailbox does not exist, a server MUST return an
- error, and MUST NOT automatically create the mailbox. Unless it
- is certain that the destination mailbox can not be created, the
- server MUST send the response code "[TRYCREATE]" as the prefix of
- the text of the tagged NO response. This gives a hint to the
- client that it can attempt a CREATE command and retry the APPEND
- if the CREATE is successful.
-
- Example: C: A003 APPEND saved-messages (\Seen) {310}
- C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
- C: From: Fred Foobar <foobar@Blurdybloop.COM>
- C: Subject: afternoon meeting
- C: To: mooch@owatagu.siam.edu
- C: Message-Id: <B27397-0100000@Blurdybloop.COM>
- C: MIME-Version: 1.0
- C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
- C:
- C: Hello Joe, do you think we can meet at 3:30 tomorrow?
- C:
- S: A003 OK APPEND completed
-
- Note: the APPEND command is not used for message delivery,
- because it does not provide a mechanism to transfer [SMTP]
- envelope information.
-
-
-
-6.4. Client Commands - Selected State
-
- In selected state, commands that manipulate messages in a mailbox are
- permitted.
-
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
- and the authenticated state commands (SELECT, EXAMINE, CREATE,
- DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
- ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
- are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
- FETCH, PARTIAL, STORE, COPY, and UID.
-
-
-
-
-
-
-
-
-Crispin [Page 23]
-
-RFC 1730 IMAP4 December 1994
-
-
-6.4.1. CHECK Command
-
- Arguments: none
-
- Data: no specific data for this command
-
- Result: OK - check completed
- BAD - command unknown or arguments invalid
-
- The CHECK command requests a checkpoint of the currently selected
- mailbox. A checkpoint refers to any implementation-dependent
- housekeeping associated with the mailbox (e.g. resolving the
- server's in-memory state of the mailbox with the state on its
- disk) that is not normally executed as part of each command. A
- checkpoint may take a non-instantaneous amount of real time to
- complete. If a server implementation has no such housekeeping
- considerations, CHECK is equivalent to NOOP.
-
- There is no guarantee that an EXISTS untagged response will happen
- as a result of CHECK. NOOP, not CHECK, should be used for new
- mail polling.
-
- Example: C: FXXZ CHECK
- S: FXXZ OK CHECK Completed
-
-
-6.4.2. CLOSE Command
-
- Arguments: none
-
- Data: no specific data for this command
-
- Result: OK - close completed, now in authenticated state
- NO - close failure: no mailbox selected
- BAD - command unknown or arguments invalid
-
- The CLOSE command permanently removes from the currently selected
- mailbox all messages that have the \Deleted flag set, and returns
- to authenticated state from selected state. No untagged EXPUNGE
- responses are sent.
-
- No messages are removed, and no error is given, if the mailbox is
- selected by an EXAMINE command or is otherwise selected read-only.
-
- Even when a mailbox is selected, it is not required to send a
- CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The
- SELECT, EXAMINE, and LOGOUT commands implicitly close the
- currently selected mailbox without doing an expunge. However,
-
-
-
-Crispin [Page 24]
-
-RFC 1730 IMAP4 December 1994
-
-
- when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
- sequence is considerably faster than an EXPUNGE-LOGOUT or
- EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
- client would probably ignore) are sent.
-
- Example: C: A341 CLOSE
- S: A341 OK CLOSE completed
-
-
-6.4.3. EXPUNGE Command
-
- Arguments: none
-
- Data: untagged responses: EXPUNGE
-
- Result: OK - expunge completed
- NO - expunge failure: can't expunge (e.g. permission
- denied)
- BAD - command unknown or arguments invalid
-
- The EXPUNGE command permanently removes from the currently
- selected mailbox all messages that have the \Deleted flag set.
- Before returning an OK to the client, an untagged EXPUNGE response
- is sent for each message that is removed.
-
- Example: C: A202 EXPUNGE
- S: * 3 EXPUNGE
- S: * 3 EXPUNGE
- S: * 5 EXPUNGE
- S: * 8 EXPUNGE
- S: A202 OK EXPUNGE completed
-
- Note: in this example, messages 3, 4, 7, and 11 had the
- \Deleted flag set. See the description of the EXPUNGE
- response for further explanation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 25]
-
-RFC 1730 IMAP4 December 1994
-
-
-6.4.4. SEARCH Command
-
- Arguments: optional character set specification
- searching criteria (one or more)
-
- Data: mandatory untagged response: SEARCH
-
- Result: OK - search completed
- NO - search error: can't search that character set or
- criteria
- BAD - command unknown or arguments invalid
-
- The SEARCH command searches the mailbox for messages that match
- the given searching criteria. Searching criteria consist of one
- or more search keys. The untagged SEARCH response from the server
- contains a listing of message sequence numbers corresponding to
- those messages that match the searching criteria.
-
- When multiple keys are specified, the result is the intersection
- (AND function) of all the messages that match those keys. For
- example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
- to all deleted messages from Smith that were placed in the mailbox
- since February 1, 1994. A search key may also be a parenthesized
- list of one or more search keys (e.g. for use with the OR and NOT
- keys).
-
- Server implementations MAY exclude [MIME-1] body parts with
- terminal content types other than TEXT and MESSAGE from
- consideration in SEARCH matching.
-
- The optional character set specification consists of the word
- "CHARSET" followed by a registered MIME character set. It
- indicates the character set of the strings that appear in the
- search criteria. [MIME-2] strings that appear in RFC 822/MIME
- message headers, and [MIME-1] content transfer encodings, MUST be
- decoded before matching. Except for US-ASCII, it is not required
- that any particular character set be supported. If the server
- does not support the specified character set, it MUST return a
- tagged NO response (not a BAD).
-
- In all search keys that use strings, a message matches the key if
- the string is a substring of the field. The matching is
- case-insensitive.
-
-
-
-
-
-
-
-
-Crispin [Page 26]
-
-RFC 1730 IMAP4 December 1994
-
-
- The defined search keys are as follows. Refer to the Formal
- Syntax section for the precise syntactic definitions of the
- arguments.
-
- <message set> Messages with message sequence numbers
- corresponding to the specified message sequence
- number set
-
- ALL All messages in the mailbox; the default initial
- key for ANDing.
-
- ANSWERED Messages with the \Answered flag set.
-
- BCC <string> Messages that contain the specified string in the
- envelope structure's BCC field.
-
- BEFORE <date> Messages whose internal date is earlier than the
- specified date.
-
- BODY <string> Messages that contain the specified string in the
- body of the message.
-
- CC <string> Messages that contain the specified string in the
- envelope structure's CC field.
-
- DELETED Messages with the \Deleted flag set.
-
- DRAFT Messages with the \Draft flag set.
-
- FLAGGED Messages with the \Flagged flag set.
-
- FROM <string> Messages that contain the specified string in the
- envelope structure's FROM field.
-
- HEADER <field-name> <string>
- Messages that have a header with the specified
- field-name (as defined in [RFC-822]) and that
- contains the specified string in the [RFC-822]
- field-body.
-
- KEYWORD <flag> Messages with the specified keyword set.
-
- LARGER <n> Messages with an RFC822.SIZE larger than the
- specified number of octets.
-
- NEW Messages that have the \Recent flag set but not the
- \Seen flag. This is functionally equivalent to
- "(RECENT UNSEEN)".
-
-
-
-Crispin [Page 27]
-
-RFC 1730 IMAP4 December 1994
-
-
- NOT <search-key>
- Messages that do not match the specified search
- key.
-
- OLD Messages that do not have the \Recent flag set.
- This is functionally equivalent to "NOT RECENT" (as
- opposed to "NOT NEW").
-
- ON <date> Messages whose internal date is within the
- specified date.
-
- OR <search-key1> <search-key2>
- Messages that match either search key.
-
- RECENT Messages that have the \Recent flag set.
-
- SEEN Messages that have the \Seen flag set.
-
- SENTBEFORE <date>
- Messages whose [RFC-822] Date: header is earlier
- than the specified date.
-
- SENTON <date> Messages whose [RFC-822] Date: header is within the
- specified date.
-
- SENTSINCE <date>
- Messages whose [RFC-822] Date: header is within or
- later than the specified date.
-
- SINCE <date> Messages whose internal date is within or later
- than the specified date.
-
- SMALLER <n> Messages with an RFC822.SIZE smaller than the
- specified number of octets.
-
- SUBJECT <string>
- Messages that contain the specified string in the
- envelope structure's SUBJECT field.
-
- TEXT <string> Messages that contain the specified string in the
- header or body of the message.
-
- TO <string> Messages that contain the specified string in the
- envelope structure's TO field.
-
- UID <message set>
- Messages with unique identifiers corresponding to
- the specified unique identifier set.
-
-
-
-Crispin [Page 28]
-
-RFC 1730 IMAP4 December 1994
-
-
- UNANSWERED Messages that do not have the \Answered flag set.
-
- UNDELETED Messages that do not have the \Deleted flag set.
-
- UNDRAFT Messages that do not have the \Draft flag set.
-
- UNFLAGGED Messages that do not have the \Flagged flag set.
-
- UNKEYWORD <flag>
- Messages that do not have the specified keyword
- set.
-
- UNSEEN Messages that do not have the \Seen flag set.
-
-
- Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
- S: * SEARCH 2 84 882
- S: A282 OK SEARCH completed
-
-
-6.4.5. FETCH Command
-
- Arguments: message set
- message data item names
-
- Data: untagged responses: FETCH
-
- Result: OK - fetch completed
- NO - fetch error: can't fetch that data
- BAD - command unknown or arguments invalid
-
- The FETCH command retrieves data associated with a message in the
- mailbox. The data items to be fetched may be either a single atom
- or a parenthesized list. The currently defined data items that
- can be fetched are:
-
- ALL Macro equivalent to: (FLAGS INTERNALDATE
- RFC822.SIZE ENVELOPE)
-
- BODY Non-extensible form of BODYSTRUCTURE.
-
- BODY[<section>]
- The text of a particular body section. The section
- specification is a set of one or more part numbers
- delimited by periods.
-
- Single-part messages only have a part 1.
-
-
-
-
-Crispin [Page 29]
-
-RFC 1730 IMAP4 December 1994
-
-
- Multipart messages are assigned consecutive part
- numbers, as they occur in the message. If a
- particular part is of type message or multipart,
- its parts must be indicated by a period followed by
- the part number within that nested multipart part.
- It is not permitted to fetch a multipart part
- itself, only its individual members.
-
- A part of type MESSAGE and subtype RFC822 also has
- nested parts. These are the parts of the MESSAGE
- part's body. Nested part 0 of a part of type
- MESSAGE and subtype RFC822 is the [RFC-822] header
- of the message.
-
- Every message has at least one part.
-
- Here is an example of a complex message
- with its associated section
- specifications:
-
- 0 ([RFC-822] header of the message)
- MULTIPART/MIXED
- 1 TEXT/PLAIN
- 2 APPLICATION/OCTET-STREAM
- 3 MESSAGE/RFC822
- 3.0 ([RFC-822] header of the message)
- 3.1 TEXT/PLAIN
- 3.2 APPLICATION/OCTET-STREAM
- MULTIPART/MIXED
- 4.1 IMAGE/GIF
- 4.2 MESSAGE/RFC822
- 4.2.0 ([RFC-822] header of the message)
- 4.2.1 TEXT/PLAIN
- MULTIPART/ALTERNATIVE
- 4.2.2.1 TEXT/PLAIN
- 4.2.2.2 TEXT/RICHTEXT
-
- Note that there is no section
- specification for the Multi-part parts
- (no section 4 or 4.2.2).
-
- The \Seen flag is implicitly set; if this causes
- the flags to change they should be included as part
- of the fetch responses.
-
- BODY.PEEK[<section>]
- An alternate form of BODY[section] that does not
- implicitly set the \Seen flag.
-
-
-
-Crispin [Page 30]
-
-RFC 1730 IMAP4 December 1994
-
-
- BODYSTRUCTURE The [MIME-1] body structure of the message. This
- is computed by the server by parsing the [MIME-1]
- header lines.
-
- ENVELOPE The envelope structure of the message. This is
- computed by the server by parsing the [RFC-822]
- header into the component parts, defaulting various
- fields as necessary.
-
- FAST Macro equivalent to: (FLAGS INTERNALDATE
- RFC822.SIZE)
-
- FLAGS The flags that are set for this message.
-
- FULL Macro equivalent to: (FLAGS INTERNALDATE
- RFC822.SIZE ENVELOPE BODY)
-
- INTERNALDATE The date and time of final delivery of the message
- as defined by RFC 821.
-
- RFC822 The message in [RFC-822] format. The \Seen flag is
- implicitly set; if this causes the flags to change
- they should be included as part of the fetch
- responses. This is the concatenation of
- RFC822.HEADER and RFC822.TEXT.
-
- RFC822.PEEK An alternate form of RFC822 that does not
- implicitly set the \Seen flag.
-
- RFC822.HEADER The [RFC-822] format header of the message as
- stored on the server including the delimiting blank
- line between the header and the body.
-
- RFC822.HEADER.LINES <header_list>
- All header lines (including continuation lines) of
- the [RFC-822] format header of the message with a
- field-name (as defined in [RFC-822]) that matches
- any of the strings in header_list. The matching is
- case-insensitive but otherwise exact. The
- delimiting blank line between the header and the
- body is always included.
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 31]
-
-RFC 1730 IMAP4 December 1994
-
-
- RFC822.HEADER.LINES.NOT <header_list>
- All header lines (including continuation lines) of
- the [RFC-822] format header of the message with a
- field-name (as defined in [RFC-822]) that does not
- match any of the strings in header_list. The
- matching is case-insensitive but otherwise exact.
- The delimiting blank line between the header and
- the body is always included.
-
- RFC822.SIZE The number of octets in the message, as expressed
- in [RFC-822] format.
-
- RFC822.TEXT The text body of the message, omitting the
- [RFC-822] header. The \Seen flag is implicitly
- set; if this causes the flags to change they should
- be included as part of the fetch responses.
-
- RFC822.TEXT.PEEK
- An alternate form of RFC822.TEXT that does not
- implicitly set the \Seen flag.
-
- UID The unique identifier for the message.
-
-
- Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
- S: * 2 FETCH ....
- S: * 3 FETCH ....
- S: * 4 FETCH ....
- S: A003 OK FETCH completed
-
-
-6.4.6. PARTIAL Command
-
- Arguments: message sequence number
- message data item name
- position of first octet
- number of octets
-
- Data: untagged responses: FETCH
-
- Result: OK - partial completed
- NO - partial error: can't fetch that data
- BAD - command unknown or arguments invalid
-
- The PARTIAL command is equivalent to the associated FETCH command,
- with the added functionality that only the specified number of
- octets, beginning at the specified starting octet, are returned.
- Only a single message can be fetched at a time. The first octet
-
-
-
-Crispin [Page 32]
-
-RFC 1730 IMAP4 December 1994
-
-
- of a message, and hence the minimum for the starting octet, is
- octet 1.
-
- The following FETCH items are valid data for PARTIAL: RFC822,
- RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK
- forms of these.
-
- Any partial fetch that attempts to read beyond the end of the text
- is truncated as appropriate. If the starting octet is beyond the
- end of the text, an empty string is returned.
-
- The data are returned with the FETCH response. There is no
- indication of the range of the partial data in this response. It
- is not possible to stream multiple PARTIAL commands of the same
- data item without processing and synchronizing at each step, since
- streamed commands may be executed out of order.
-
- There is no requirement that partial fetches follow any sequence.
- For example, if a partial fetch of octets 1 through 10000 breaks
- in an awkward place for BASE64 decoding, it is permitted to
- continue with a partial fetch of 9987 through 19987, etc.
-
- The handling of the \Seen flag is the same as in the associated
- FETCH command.
-
- Example: C: A005 PARTIAL 4 RFC822 1 1024
- S: * 1 FETCH (RFC822 {1024}
- S: Return-Path: <gray@cac.washington.edu>
- S: ...
- S: ......... FLAGS (\Seen))
- S: A005 OK PARTIAL completed
-
-
-6.4.7. STORE Command
-
- Arguments: message set
- message data item name
- value for message data item
-
- Data: untagged responses: FETCH
-
- Result: OK - store completed
- NO - store error: can't store that data
- BAD - command unknown or arguments invalid
-
- The STORE command alters data associated with a message in the
- mailbox. Normally, STORE will return the updated value of the
- data with an untagged FETCH response. A suffix of ".SILENT" in
-
-
-
-Crispin [Page 33]
-
-RFC 1730 IMAP4 December 1994
-
-
- the data item name prevents the untagged FETCH, and the server
- should assume that the client has determined the updated value
- itself or does not care about the updated value.
-
- The currently defined data items that can be stored are:
-
- FLAGS <flag list>
- Replace the flags for the message with the
- argument. The new value of the flags are returned
- as if a FETCH of those flags was done.
-
- FLAGS.SILENT <flag list>
- Equivalent to FLAGS, but without returning a new
- value.
-
- +FLAGS <flag list>
- Add the argument to the flags for the message. The
- new value of the flags are returned as if a FETCH
- of those flags was done.
-
- +FLAGS.SILENT <flag list>
- Equivalent to +FLAGS, but without returning a new
- value.
-
- -FLAGS <flag list>
- Remove the argument from the flags for the message.
- The new value of the flags are returned as if a
- FETCH of those flags was done.
-
- -FLAGS.SILENT <flag list>
- Equivalent to -FLAGS, but without returning a new
- value.
-
-
- Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
- S: * 2 FETCH FLAGS (\Deleted \Seen)
- S: * 3 FETCH FLAGS (\Deleted)
- S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
- S: A003 OK STORE completed
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 34]
-
-RFC 1730 IMAP4 December 1994
-
-
-6.4.8. COPY Command
-
- Arguments: message set
- mailbox name
-
- Data: no specific data for this command
-
- Result: OK - copy completed
- NO - copy error: can't copy those messages or to that
- name
- BAD - command unknown or arguments invalid
-
- The COPY command copies the specified message(s) to the specified
- destination mailbox. The flags and internal date of the
- message(s) SHOULD be preserved in the copy.
-
- If the destination mailbox does not exist, a server SHOULD return
- an error. It SHOULD NOT automatically create the mailbox. Unless
- it is certain that the destination mailbox can not be created, the
- server MUST send the response code "[TRYCREATE]" as the prefix of
- the text of the tagged NO response. This gives a hint to the
- client that it can attempt a CREATE command and retry the COPY if
- the CREATE is successful.
-
- If the COPY command is unsuccessful for any reason, server
- implementations MUST restore the destination mailbox to its state
- before the COPY attempt.
-
- Example: C: A003 COPY 2:4 MEETING
- S: A003 OK COPY completed
-
-
-6.4.9. UID Command
-
- Arguments: command name
- command arguments
-
- Data: untagged responses: FETCH, SEARCH
-
- Result: OK - UID command completed
- NO - UID command error
- BAD - command unknown or arguments invalid
-
- The UID command has two forms. In the first form, it takes as its
- arguments a COPY, FETCH, or STORE command with arguments
- appropriate for the associated command. However, the numbers in
- the message set argument are unique identifiers instead of message
- sequence numbers.
-
-
-
-Crispin [Page 35]
-
-RFC 1730 IMAP4 December 1994
-
-
- In the second form, the UID command takes a SEARCH command with
- SEARCH command arguments. The interpretation of the arguments is
- the same as with SEARCH; however, the numbers returned in a SEARCH
- response for a UID SEARCH command are unique identifiers instead
- of message sequence numbers. For example, the command UID SEARCH
- 1:100 UID 443:557 returns the unique identifiers corresponding to
- the intersection of the message sequence number set 1:100 and the
- UID set 443:557.
-
- A unique identifier of a message is a number, and is guaranteed
- not to refer to any other message in the mailbox. Unique
- identifiers are assigned in a strictly ascending fashion for each
- message added to the mailbox. Unlike message sequence numbers,
- unique identifiers persist across sessions. This permits a client
- to resynchronize its state from a previous session with the server
- (e.g. disconnected or offline access clients); this is discussed
- further in [IMAP-DISC].
-
- Associated with every mailbox is a unique identifier validity
- value, which is sent in an UIDVALIDITY response code in an OK
- untagged response at message selection time. If unique
- identifiers from an earlier session fail to persist to this
- session, the unique identifier validity value MUST be greater than
- in the earlier session.
-
- Note: An example of a good value to use for the unique
- identifier validity value would be a 32-bit
- representation of the creation date/time of the mailbox.
- It is alright to use a constant such as 1, but only if
- it guaranteed that unique identifers will never be
- reused, even in the case of a mailbox being deleted and
- a new mailbox by the same name created at some future
- time.
-
-
- Message set ranges are permitted; however, there is no guarantee
- that unique identifiers be contiguous. A non-existent unique
- identifier within a message set range is ignored without any error
- message generated.
-
- The number after the "*" in an untagged FETCH response is always a
- message sequence number, not a unique identifier, even for a UID
- command response. However, server implementations MUST implicitly
- include the UID message data item as part of any FETCH response
- caused by a UID command, regardless of whether UID was specified
- as a message data item to the FETCH.
-
-
-
-
-
-Crispin [Page 36]
-
-RFC 1730 IMAP4 December 1994
-
-
- Example: C: A003 UID FETCH 4827313:4828442 FLAGS
- S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
- S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
- S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
- S: A999 UID FETCH completed
-
-
-
-6.5. Client Commands - Experimental/Expansion
-
-
-6.5.1. X<atom> Command
-
- Arguments: implementation defined
-
- Data: implementation defined
-
- Result: OK - command completed
- NO - failure
- BAD - command unknown or arguments invalid
-
- Any command prefixed with an X is an experimental command.
- Commands which are not part of this specification, or a standard
- or standards-track revision of this specification, MUST use the X
- prefix.
-
- Any added untagged responses issued by an experimental command
- MUST also be prefixed with an X. Server implementations MUST NOT
- send any such untagged responses, unless the client requested it
- by issuing the associated experimental command.
-
- Example: C: a441 CAPABILITY
- S: * CAPABILITY IMAP4 XPIG-LATIN
- S: a441 OK CAPABILITY completed
- C: A442 XPIG-LATIN
- S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
- S: A442 OK XPIG-LATIN ompleted-cay
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 37]
-
-RFC 1730 IMAP4 December 1994
-
-
-7. Server Responses
-
- Server responses are in three forms: status responses, server data,
- and command continuation request.
-
- Server response data, identified by "Data:" in the response
- descriptions below, are described by function, not by syntax. The
- precise syntax of server response data is described in the Formal
- Syntax section.
-
- The client MUST be prepared to accept any response at all times.
-
- Status responses that are tagged indicate the completion result of a
- client command, and have a tag matching the command.
-
- Some status responses, and all server data, are untagged. An
- untagged response is indicated by the token "*" instead of a tag.
- Untagged status responses indicate server greeting, or server status
- that does not indicate the completion of a command. For historical
- reasons, untagged server data responses are also called "unsolicited
- data", although strictly speaking only unilateral server data is
- truly "unsolicited".
-
- Certain server data MUST be recorded by the client when it is
- received; this is noted in the description of that data. Such data
- conveys critical information which affects the interpretation of all
- subsequent commands and responses (e.g. updates reflecting the
- creation or destruction of messags).
-
- Other server data SHOULD be recorded for later reference; if the
- client does not need to record the data, or if recording the data has
- no obvious purpose (e.g. a SEARCH response when no SEARCH command is
- in progress), the data SHOULD be ignored.
-
- An example of unilateral untagged responses occurs when the IMAP
- connection is in selected state. In selected state, the server
- checks the mailbox for new messages as part of the execution of each
- command. If new messages are found, the server sends untagged EXISTS
- and RECENT responses reflecting the new size of the mailbox. Server
- implementations that offer multiple simultaneous access to the same
- mailbox should also send appropriate unilateral untagged FETCH and
- EXPUNGE responses if another agent changes the state of any message
- flags or expunges any messages.
-
- Command continuation request responses use the token "+" instead of a
- tag. These responses are sent by the server to indicate acceptance
- of an incomplete client command and readiness for the remainder of
- the command.
-
-
-
-Crispin [Page 38]
-
-RFC 1730 IMAP4 December 1994
-
-
-7.1. Server Responses - Status Responses
-
- Status responses may include an optional response code. A response
- code consists of data inside square brackets in the form of an atom,
- possibly followed by a space and arguments. The response code
- contains additional information or status codes for client software
- beyond the OK/NO/BAD condition, and are defined when there is a
- specific action that a client can take based upon the additional
- information.
-
- The currently defined response codes are:
-
- ALERT The human-readable text contains a special alert
- that MUST be presented to the user in a fashion
- that calls the user's attention to the message.
-
- PARSE The human-readable text represents an error in
- parsing the [RFC-822] or [MIME-1] headers of a
- message in the mailbox.
-
- PERMANENTFLAGS Followed by a parenthesized list of flags,
- indicates which of the known flags that the client
- may change permanently. Any flags that are in the
- FLAGS untagged response, but not the PERMANENTFLAGS
- list, can not be set permanently. If the client
- attempts to STORE a flag that is not in the
- PERMANENTFLAGS list, the server will either reject
- it with a NO reply or store the state for the
- remainder of the current session only. The
- PERMANENTFLAGS list may also include the special
- flag \*, which indicates that it is possible to
- create new keywords by attempting to store those
- flags in the mailbox.
-
- READ-ONLY The mailbox is selected read-only, or its access
- while selected has changed from read-write to
- read-only.
-
- READ-WRITE The mailbox is selected read-write, or its access
- while selected has changed from read-only to
- read-write.
-
- TRYCREATE An APPEND or COPY attempt is failing because the
- target mailbox does not exist (as opposed to some
- other reason). This is a hint to the client that
- the operation may succeed if the mailbox is first
- created by the CREATE command.
-
-
-
-
-Crispin [Page 39]
-
-RFC 1730 IMAP4 December 1994
-
-
- UIDVALIDITY Followed by a decimal number, indicates the unique
- identifier validity value. See the description of
- the UID command for more detail.
-
- UNSEEN Followed by a decimal number, indicates the number
- of the first message without the \Seen flag set.
-
- Additional response codes defined by particular client or server
- implementations should be prefixed with an "X" until they are
- added to a revision of this protocol. Client implementations
- should ignore response codes that they do not recognize.
-
-
-7.1.1. OK Response
-
- Data: optional response code
- human-readable text
-
- The OK response indicates an information message from the server.
- When tagged, it indicates successful completion of the associated
- command. The human-readable text may be presented to the user as
- an information message. The untagged form indicates an
- information-only message; the nature of the information may be
- indicated by a response code.
-
- The untagged form is also used as one of three possible greetings
- at session startup. It indicates that the session is not yet
- authenticated and that a LOGIN command is needed.
-
- Example: S: * OK IMAP4 server ready
- C: A001 LOGIN fred blurdybloop
- S: * OK [ALERT] System shutdown in 10 minutes
- S: A001 OK LOGIN Completed
-
-
-7.1.2. NO Response
-
- Data: optional response code
- human-readable text
-
- The NO response indicates an operational error message from the
- server. When tagged, it indicates unsuccessful completion of the
- associated command. The untagged form indicates a warning; the
- command may still complete successfully. The human-readable text
- describes the condition.
-
-
-
-
-
-
-Crispin [Page 40]
-
-RFC 1730 IMAP4 December 1994
-
-
- Example: C: A222 COPY 1:2 owatagusiam
- S: * NO Disk is 98% full, please delete unnecessary data
- S: A222 OK COPY completed
- C: A222 COPY 3:200 blurdybloop
- S: * NO Disk is 98% full, please delete unnecessary data
- S: * NO Disk is 99% full, please delete unnecessary data
- S: A222 NO COPY failed: disk is full
-
-
-7.1.3. BAD Response
-
- Data: optional response code
- human-readable text
-
- The BAD response indicates an error message from the server. When
- tagged, it reports a protocol-level error in the client's command;
- the tag indicates the command that caused the error. The untagged
- form indicates a protocol-level error for which the associated
- command can not be determined; it may also indicate an internal
- server failure. The human-readable text describes the condition.
-
- Example: C: ...very long command line...
- S: * BAD Command line too long
- C: ...empty line...
- S: * BAD Empty command line
- C: A443 EXPUNGE
- S: * BAD Disk crash, attempting salvage to a new disk!
- S: * OK Salvage successful, no data lost
- S: A443 OK Expunge completed
-
-
-7.1.4. PREAUTH Response
-
- Data: optional response code
- human-readable text
-
- The PREAUTH response is always untagged, and is one of three
- possible greetings at session startup. It indicates that the
- session has already been authenticated by external means and thus
- no LOGIN command is needed.
-
- Example: S: * PREAUTH IMAP4 server ready and logged in as Smith
-
-
-
-
-
-
-
-
-
-Crispin [Page 41]
-
-RFC 1730 IMAP4 December 1994
-
-
-7.1.5. BYE Response
-
- Data: optional response code
- human-readable text
-
- The BYE response is always untagged, and indicates that the server
- is about to close the connection. The human-readable text may be
- displayed to the user in a status report by the client. The BYE
- response may be sent as part of a normal logout sequence, or as a
- panic shutdown announcement by the server. It is also used by
- some server implementations as an announcement of an inactivity
- autologout.
-
- This response is also used as one of three possible greetings at
- session startup. It indicates that the server is not willing to
- accept a session from this client.
-
- Example: S: * BYE Autologout; idle for too long
-
-
-
-7.2. Server Responses - Server and Mailbox Status
-
- These responses are always untagged. This is how server data are
- transmitted from the server to the client, often as a result of a
- command with the same name.
-
-7.2.1. CAPABILITY Response
-
- Data: capability listing
-
- The CAPABILITY response occurs as a result of a CAPABILITY
- command. The capability listing contains a space-separated
- listing of capability names that the server supports. The first
- name in the capability listing MUST be the atom "IMAP4".
-
- A capability name other than IMAP4 indicates that the server
- supports an extension, revision, or amendment to the IMAP4
- protocol. Server responses MUST conform to this document until
- the client issues a command that uses the associated capability.
-
- Capability names MUST either begin with "X" or be standard or
- standards-track IMAP4 extensions, revisions, or amendments
- registered with IANA. A server MUST NOT offer unregistered or
- non-standard capability names, unless such names are prefixed with
- an "X".
-
-
-
-
-
-Crispin [Page 42]
-
-RFC 1730 IMAP4 December 1994
-
-
- Client implementations SHOULD NOT require any capability name
- other than "IMAP4", and MUST ignore any unknown capability names.
-
- Example: S: * CAPABILITY IMAP4 XPIG-LATIN
-
-
-7.2.2. LIST Response
-
- Data: name attributes
- hierarchy delimiter
- name
-
- The LIST response occurs as a result of a LIST command. It
- returns a single name that matches the LIST specification. There
- may be multiple LIST responses for a single LIST command.
-
- Four name attributes are defined:
-
- \Noinferiors It is not possible for any child levels of
- hierarchy to exist under this name; no child levels
- exist now and none can be created in the future.
-
- \Noselect It is not possible to use this name as a selectable
- mailbox.
-
- \Marked The mailbox has been marked "interesting" by the
- server; the mailbox probably contains messages that
- have been added since the last time the mailbox was
- selected.
-
- \Unmarked The mailbox does not contain any additional
- messages since the last time the mailbox was
- selected.
-
- If it is not feasible for the server to determine whether the
- mailbox is "interesting" or not, or if the name is a \Noselect
- name, the server should not send either \Marked or \Unmarked.
-
- The hierarchy delimiter is a character used to delimit levels of
- hierarchy in a mailbox name. A client may use it to create child
- mailboxes, and to search higher or lower levels of naming
- hierarchy. All children of a top-level hierarchy node must use
- the same separator character. A NIL hierarchy delimiter means
- that no hierarchy exists; the name is a "flat" name.
-
-
-
-
-
-
-
-Crispin [Page 43]
-
-RFC 1730 IMAP4 December 1994
-
-
- The name represents an unambiguous left-to-right hierarchy, and
- MUST be valid for use as a reference in LIST and LSUB commands.
- Unless \Noselect is indicated, the name must also be valid as an
- argument for commands, such as SELECT, that accept mailbox names.
-
- Example: S: * LIST (\Noselect) "/" ~/Mail/foo
-
-
-7.2.3. LSUB Response
-
- Data: name attributes
- hierarchy delimiter
- name
-
- The LSUB response occurs as a result of an LSUB command. It
- returns a single name that matches the LSUB specification. There
- may be multiple LSUB responses for a single LSUB command. The
- data is identical in format to the LIST response.
-
- Example: S: * LSUB () "." #news.comp.mail.misc
-
-
-7.2.4. SEARCH Response
-
- Data: zero or more numbers
-
- The SEARCH response occurs as a result of a SEARCH or UID SEARCH
- command. The number(s) refer to those messages that match the
- search criteria. For SEARCH, these are message sequence numbers;
- for UID SEARCH, these are unique identifiers. Each number is
- delimited by a space.
-
- Example: S: * SEARCH 2 3 6
-
-
-7.2.5. FLAGS Response
-
- Data: flag parenthesized list
-
- The FLAGS response occurs as a result of a SELECT or EXAMINE
- command. The flag parenthesized list identifies the flags (at a
- minimum, the system-defined flags) that are applicable for this
- mailbox. Flags other than the system flags may also exist,
- depending on server implementation.
-
- The update from the FLAGS response MUST be recorded by the client.
-
- Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
-
-
-
-Crispin [Page 44]
-
-RFC 1730 IMAP4 December 1994
-
-
-7.3. Server Responses - Message Status
-
- These responses are always untagged. This is how message data are
- transmitted from the server to the client, often as a result of a
- command with the same name. Immediately following the "*" token is a
- number that represents either a message sequence number or a message
- count.
-
-7.3.1. EXISTS Response
-
- Data: none
-
- The EXISTS response reports the number of messages in the mailbox.
- This response occurs as a result of a SELECT or EXAMINE command,
- and if the size of the mailbox changes (e.g. new mail).
-
- The update from the EXISTS response MUST be recorded by the
- client.
-
- Example: S: * 23 EXISTS
-
-
-7.3.2. RECENT Response
-
- Data: none
-
- The RECENT response reports the number of messages that have
- arrived since the previous time a SELECT command was done on this
- mailbox. This response occurs as a result of a SELECT or EXAMINE
- command, and if the size of the mailbox changes (e.g. new mail).
-
- The update from the RECENT response MUST be recorded by the
- client.
-
- Example: S: * 5 RECENT
-
-
-7.3.3. EXPUNGE Response
-
- Data: none
-
- The EXPUNGE response reports that the specified message sequence
- number has been permanently removed from the mailbox. The message
- sequence number for each successive message in the mailbox is
- immediately decremented by 1, and this decrement is reflected in
- message sequence numbers in subsequent responses (including other
- untagged EXPUNGE responses).
-
-
-
-
-Crispin [Page 45]
-
-RFC 1730 IMAP4 December 1994
-
-
- As a result of the immediate decrement rule, message sequence
- numbers that appear in a set of successive EXPUNGE responses
- depend upon whether the messages are removed starting from lower
- numbers to higher numbers, or from higher numbers to lower
- numbers. For example, if the last 5 messages in a 9-message
- mailbox are expunged; a "lower to higher" server will send five
- untagged EXPUNGE responses for message sequence number 5, whereas
- a "higher to lower server" will send successive untagged EXPUNGE
- responses for message sequence numbers 9, 8, 7, 6, and 5.
-
- An EXPUNGE response MUST NOT be sent when no command is in
- progress; nor while responding to a FETCH, STORE, or SEARCH
- command. This rule is necessary to prevent a loss of
- synchronization of message sequence numbers between client and
- server.
-
- The update from the EXPUNGE response MUST be recorded by the
- client.
-
- Example: S: * 44 EXPUNGE
-
-
-7.3.4. FETCH Response
-
- Data: message data
-
- The FETCH response returns data about a message to the client.
- The data are pairs of data item names and their values in
- parentheses. This response occurs as the result of a FETCH or
- STORE command, as well as by unilateral server decision (e.g. flag
- updates).
-
- The current data items are:
-
- BODY A form of BODYSTRUCTURE without extension data.
-
- BODY[section] A string expressing the body contents of the
- specified section. The string should be
- interpreted by the client according to the content
- transfer encoding, body type, and subtype.
-
- 8-bit textual data is permitted if a character set
- identifier is part of the body parameter
- parenthesized list for this section.
-
- Non-textual data such as binary data must be
- transfer encoded into a textual form such as BASE64
- prior to being sent to the client. To derive the
-
-
-
-Crispin [Page 46]
-
-RFC 1730 IMAP4 December 1994
-
-
- original binary data, the client must decode the
- transfer encoded string.
-
- BODYSTRUCTURE A parenthesized list that describes the body
- structure of a message. This is computed by the
- server by parsing the [RFC-822] header and body
- into the component parts, defaulting various fields
- as necessary.
-
- Multiple parts are indicated by parenthesis
- nesting. Instead of a body type as the first
- element of the parenthesized list there is a nested
- body. The second element of the parenthesized list
- is the multipart subtype (mixed, digest, parallel,
- alternative, etc.).
-
- Extension data follows the multipart subtype.
- Extension data is never returned with the BODY
- fetch, but may be returned with a BODYSTRUCTURE
- fetch. Extension data, if present, must be in the
- defined order.
-
- The extension data of a multipart body part are in
- the following order:
-
- body parameter parenthesized list
- A parenthesized list of attribute/value pairs
- [e.g. (foo bar baz rag) where "bar" is the value
- of "foo" and "rag" is the value of "baz"] as
- defined in [MIME-1].
-
- Any following extension data are not yet defined in
- this version of the protocol. Such extension data
- may consist of zero or more NILs, strings, numbers,
- or potentially nested parenthesized lists of such
- data. Client implementations that do a
- BODYSTRUCTURE fetch MUST be prepared to accept such
- extension data. Server implementations MUST NOT
- send such extension data until it has been defined
- by a revision of this protocol.
-
- The basic fields of a non-multipart body part are
- in the following order:
-
- body type
- A string giving the content type name as defined
- in [MIME-1].
-
-
-
-
-Crispin [Page 47]
-
-RFC 1730 IMAP4 December 1994
-
-
- body subtype
- A string giving the content subtype name as
- defined in [MIME-1].
-
- body parameter parenthesized list
- A parenthesized list of attribute/value pairs
- [e.g. (foo bar baz rag) where "bar" is the value
- of "foo" and "rag" is the value of "baz"] as
- defined in [MIME-1].
-
- body id
- A string giving the content id as defined in
- [MIME-1].
-
- body description
- A string giving the content description as
- defined in [MIME-1].
-
- body encoding
- A string giving the content transfer encoding as
- defined in [MIME-1].
-
- body size
- A number giving the size of the body in octets.
- Note that this size is the size in its transfer
- encoding and not the resulting size after any
- decoding.
-
- A body type of type MESSAGE and subtype RFC822
- contains, immediately after the basic fields, the
- envelope structure, body structure, and size in
- text lines of the encapsulated message.
-
- A body type of type TEXT contains, immediately
- after the basic fields, the size of the body in
- text lines. Note that this size is the size in its
- transfer encoding and not the resulting size after
- any decoding.
-
- Extension data follows the basic fields and the
- type-specific fields listed above. Extension data
- is never returned with the BODY fetch, but may be
- returned with a BODYSTRUCTURE fetch. Extension
- data, if present, must be in the defined order.
-
- The extension data of a non-multipart body part are
- in the following order:
-
-
-
-
-Crispin [Page 48]
-
-RFC 1730 IMAP4 December 1994
-
-
- body MD5
- A string giving the content MD5 value as defined
- in [MIME-1].
-
- Any following extension data are not yet defined in
- this version of the protocol, and would be as
- described above under multipart extension data.
-
- ENVELOPE A parenthesized list that describes the envelope
- structure of a message. This is computed by the
- server by parsing the [RFC-822] header into the
- component parts, defaulting various fields as
- necessary.
-
- The fields of the envelope structure are in the
- following order: date, subject, from, sender,
- reply-to, to, cc, bcc, in-reply-to, and message-id.
- The date, subject, in-reply-to, and message-id
- fields are strings. The from, sender, reply-to,
- to, cc, and bcc fields are parenthesized lists of
- address structures.
-
- An address structure is a parenthesized list that
- describes an electronic mail address. The fields
- of an address structure are in the following order:
- personal name, [SMTP] at-domain-list (source
- route), mailbox name, and host name.
-
- [RFC-822] group syntax is indicated by a special
- form of address structure in which the host name
- field is NIL. If the mailbox name field is also
- NIL, this is an end of group marker (semi-colon in
- RFC 822 syntax). If the mailbox name field is
- non-NIL, this is a start of group marker, and the
- mailbox name field holds the group name phrase.
-
- Any field of an envelope or address structure that
- is not applicable is presented as NIL. Note that
- the server must default the reply-to and sender
- fields from the from field; a client is not
- expected to know to do this.
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 49]
-
-RFC 1730 IMAP4 December 1994
-
-
- FLAGS A parenthesized list of flags that are set for this
- message. This may include keywords as well as the
- following system flags:
-
- \Seen Message has been read
-
- \Answered Message has been answered
-
- \Flagged Message is "flagged" for urgent/special
- attention
-
- \Deleted Message is "deleted" for removal by
- later EXPUNGE
-
- \Draft Message has not completed composition
- (marked as a draft).
-
- as well as the following special flag, which may be
- fetched but not stored:
-
- \Recent Message has arrived since the previous
- time this mailbox was selected.
-
- INTERNALDATE A string containing the date and time of final
- delivery of the message as defined by [SMTP].
-
- RFC822 A string expressing the message in [RFC-822]
- format. The header portion of the message must be
- 7-bit. 8-bit characters are permitted only in the
- non-header portion of the message only if there are
- [MIME-1] data in the message that identify the
- character set of the message.
-
- RFC822.HEADER A string expressing the [RFC-822] format header of
- the message, including the delimiting blank line
- between the header and the body. The entire string
- must be 7-bit; 8-bit characters are not permitted
- in headers. RFC822.HEADER is used to return data
- for the RFC822.HEADER, RFC822.HEADER.LINES, and
- RFC822.HEADER.LINES.NOT FETCH data items. Note
- that a blank line is always included regardless of
- header line restrictions.
-
- RFC822.SIZE A number expressing the number of octets in the
- message in [RFC-822] format.
-
-
-
-
-
-
-Crispin [Page 50]
-
-RFC 1730 IMAP4 December 1994
-
-
- RFC822.TEXT A string expressing the text body of the message,
- omitting the [RFC-822] header. 8-bit characters
- are permitted only if there are [MIME-1] data in
- the message that identify the character set of the
- message.
-
- UID A number expressing the unique identifier of the
- message.
-
-
- Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
-
-
-7.3.5. Obsolete Responses
-
- In addition to the responses listed in here, client implementations
- MUST accept and implement the obsolete responses described in
- Appendix B.
-
-
-
-7.4. Server Responses - Command Continuation Request
-
- The command completion request response is indicated by a "+" token
- instead of a tag. This form of response indicates that the server is
- ready to accept the continuation of a command from the client. The
- remainder of this response is a line of text.
-
- This response is used in the AUTHORIZATION command to transmit server
- data to the client, and request additional client data. This
- response is also used if an argument to any command is a literal.
-
- The client is not permitted to send the octets of the literal unless
- the server indicates that it expects it. This permits the server to
- process commands and reject errors on a line-by-line basis. The
- remainder of the command, including the CRLF that terminates a
- command, follows the octets of the literal. If there are any
- additional command arguments the literal octets are followed by a
- space and those arguments.
-
- Example: C: A001 LOGIN {11}
- S: + Ready for additional command text
- C: FRED FOOBAR {7}
- S: + Ready for additional command text
- C: fat man
- S: A001 OK LOGIN completed
- C: A044 BLURDYBLOOP {102856}
- S: A044 BAD No such command as "BLURDYBLOOP"
-
-
-
-Crispin [Page 51]
-
-RFC 1730 IMAP4 December 1994
-
-
-8. Sample IMAP4 session
-
- The following is a transcript of an IMAP4 session. A long line in
- this sample is broken for editorial clarity.
-
- S: * OK IMAP4 Service Ready
- C: a001 login mrc secret
- S: a001 OK LOGIN completed
- C: a002 select inbox
- S: * 18 EXISTS
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- S: * 2 RECENT
- S: * OK [UNSEEN 17] Message 17 is the first unseen message
- S: * OK [UIDVALIDITY 3857529045] UIDs valid
- S: a002 OK [READ-WRITE] SELECT completed
- C: a003 fetch 12 full
- S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
- RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
- "IMAP4 WG mtg summary and minutes"
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- (("Terry Gray" NIL "gray" "cac.washington.edu"))
- ((NIL NIL "imap" "cac.washington.edu"))
- ((NIL NIL "minutes" "CNRI.Reston.VA.US")
- ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
- "<B27397-0100000@cac.washington.edu>")
- BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
- S: a003 OK FETCH completed
- C: a004 fetch 12 rfc822.header
- S: * 12 FETCH (RFC822.HEADER {346}
- S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
- S: From: Terry Gray <gray@cac.washington.edu>
- S: Subject: IMAP4 WG mtg summary and minutes
- S: To: imap@cac.washington.edu
- S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
- S: Message-Id: <B27397-0100000@cac.washington.edu>
- S: MIME-Version: 1.0
- S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
- S:
- S: )
- S: a004 OK FETCH completed
- C: a005 store 12 +flags \deleted
- S: * 12 FETCH (FLAGS (\Seen \Deleted))
- S: a005 OK +FLAGS completed
- C: a006 logout
- S: * BYE IMAP4 server terminating connection
- S: a006 OK LOGOUT completed
-
-
-
-
-Crispin [Page 52]
-
-RFC 1730 IMAP4 December 1994
-
-
-9. Formal Syntax
-
- The following syntax specification uses the augmented Backus-Naur
- Form (BNF) notation as specified in [RFC-822] with one exception; the
- delimiter used with the "#" construct is a single space (SPACE) and
- not a comma.
-
- Except as noted otherwise, all alphabetic characters are
- case-insensitive. The use of upper or lower case characters to
- define token strings is for editorial clarity only. Implementations
- MUST accept these strings in a case-insensitive fashion.
-
- Syntax marked as obsolete may be encountered with implementations
- written for an earlier version of this protocol (e.g. IMAP2). New
- implementations SHOULD accept obsolete syntax as input, but MUST NOT
- otherwise use such syntax.
-
- address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
- SPACE addr_host ")"
-
- addr_adl ::= nstring
-
- addr_host ::= nstring
- ;; NIL indicates [RFC-822] group syntax
-
- addr_mailbox ::= nstring
- ;; NIL indicates end of [RFC-822] group; if
- ;; non-NIL and addr_host is NIL, holds
- ;; [RFC-822] group name
-
- addr_name ::= nstring
-
- alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
- "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
- "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
- "Y" / "Z" /
- "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
- "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
- "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
- "y" / "z" /
- ;; Case-sensitive
-
- append ::= "APPEND" SPACE mailbox [SPACE flag_list]
- [SPACE date_time] SPACE literal
-
- astring ::= atom / string
-
-
-
-
-
-Crispin [Page 53]
-
-RFC 1730 IMAP4 December 1994
-
-
- atom ::= 1*ATOM_CHAR
-
- ATOM_CHAR ::= <any CHAR except atom_specials>
-
- atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /
- quoted_specials
-
- authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
-
- auth_type ::= atom
-
- base64 ::= *(4base64_char) [base64_terminal]
-
- base64_char ::= alpha / digit / "+" / "/"
-
- base64_terminal ::= (2base64_char "==") / (3base64_char "=")
-
- body ::= "(" body_type_1part / body_type_mpart ")"
-
- body_extension ::= nstring / number / "(" 1#body_extension ")"
- ;; Future expansion. Client implementations
- ;; MUST accept body_extension fields. Server
- ;; implementations MUST NOT generate
- ;; body_extension fields except as defined by
- ;; future standard or standards-track
- ;; revisions of this specification.
-
- body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension]
- ;; MUST NOT be returned on non-extensible
- ;; "BODY" fetch
-
- body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]]
- ;; MUST NOT be returned on non-extensible
- ;; "BODY" fetch
-
- body_fields ::= body_fld_param SPACE body_fld_id SPACE
- body_fld_desc SPACE body_fld_enc SPACE
- body_fld_octets
-
- body_fld_desc ::= nstring
-
- body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
- "QUOTED-PRINTABLE") <">) / string
-
- body_fld_id ::= nstring
-
- body_fld_lines ::= number
-
-
-
-
-Crispin [Page 54]
-
-RFC 1730 IMAP4 December 1994
-
-
- body_fld_md5 ::= nstring
-
- body_fld_octets ::= number
-
- body_fld_param ::= "(" 1#(string string) ")" / nil
-
- body_fld_subtyp ::= string
-
- body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
- [SPACE body_ext_1part]
-
- body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
- "MESSAGE" / "VIDEO") <">) / string) SPACE
- body_fld_subtyp SPACE body_fields
- ;; MESSAGE subtype MUST NOT be "RFC822"
-
- body_type_mpart ::= 1*body SPACE body_fld_subtyp
- [SPACE body_ext_mpart]
-
- body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE
- body_fields SPACE envelope SPACE body SPACE
- body_fld_lines
-
- body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE
- body_fields SPACE body_fld_lines
-
- capability ::= atom
- ;; Must begin with "X" or be registered with
- ;; IANA as standard or standards-track
-
- capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
-
- CHAR ::= <any 7-bit US-ASCII character except NUL,
- 0x01 - 0x7f>
-
- CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff>
-
- command ::= tag SPACE (command_any / command_auth /
- command_nonauth / command_select) CRLF
- ;; Modal based on state
-
- command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
- ;; Valid in all states
-
- command_auth ::= append / create / delete / examine / find / list /
- lsub / rename / select / subscribe / unsubscribe /
- ;; Valid only in Authenticated or Selected state
-
-
-
-
-Crispin [Page 55]
-
-RFC 1730 IMAP4 December 1994
-
-
- command_nonauth ::= login / authenticate
- ;; Valid only when in Non-Authenticated state
-
- command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /
- copy / fetch / partial / store / uid / search
- ;; Valid only when in Selected state
-
- continue_req ::= "+" SPACE (resp_text / base64)
-
- copy ::= "COPY" SPACE set SPACE mailbox
-
- CR ::= <ASCII CR, carriage return, 0x0C>
-
- create ::= "CREATE" SPACE mailbox
- ;; Use of INBOX gives a NO error
-
- CRLF ::= CR LF
-
- CTL ::= <any ASCII control character and DEL,
- 0x00 - 0x1f, 0x7f>
-
- date ::= date_text / <"> date_text <">
-
- date_day ::= 1*2digit
- ;; Day of month
-
- date_day_fixed ::= (SPACE digit) / 2digit
- ;; Fixed-format version of date_day
-
- date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
- "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
-
- date_text ::= date_day "-" date_month "-" (date_year /
- date_year_old)
-
- date_year ::= 4digit
-
- date_year_old ::= 2digit
- ;; OBSOLETE, (year - 1900)
-
- date_time ::= <"> (date_time_new / date_time_old) <">
-
- date_time_new ::= date_day_fixed "-" date_month "-" date_year
- SPACE time SPACE zone
-
- date_time_old ::= date_day_fixed "-" date_month "-" date_year_old
- SPACE time "-" zone_old
- ;; OBSOLETE
-
-
-
-Crispin [Page 56]
-
-RFC 1730 IMAP4 December 1994
-
-
- delete ::= "DELETE" SPACE mailbox
- ;; Use of INBOX gives a NO error
-
- digit ::= "0" / digit_nz
-
- digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
- "9"
-
- envelope ::= "(" env_date SPACE env_subject SPACE env_from
- SPACE env_sender SPACE env_reply-to SPACE env_to
- SPACE env_cc SPACE env_bcc SPACE env_in-reply-to
- SPACE env_message-id ")"
-
- env_bcc ::= "(" 1*address ")" / nil
-
- env_cc ::= "(" 1*address ")" / nil
-
- env_date ::= nstring
-
- env_from ::= "(" 1*address ")" / nil
-
- env_in-reply-to ::= nstring
-
- env_message-id ::= nstring
-
- env_reply-to ::= "(" 1*address ")" / nil
-
- env_sender ::= "(" 1*address ")" / nil
-
- env_subject ::= nstring
-
- env_to ::= "(" 1*address ")" / nil
-
- examine ::= "EXAMINE" SPACE mailbox
-
- fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
- "FAST" / fetch_att / "(" 1#fetch_att ")")
-
- fetch_att ::= "BODY" / "BODYSTRUCTURE" /
- "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /
- "FLAGS" / "INTERNALDATE" / "UID" /
- "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /
- (".HEADER" [".LINES" [".NOT"] SPACE header_list])
-
- find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
- list_mailbox
- ;; OBSOLETE
-
-
-
-
-Crispin [Page 57]
-
-RFC 1730 IMAP4 December 1994
-
-
- flag ::= "\Answered" / "\Flagged" / "\Deleted" /
- "\Seen" / "\Draft" / flag_keyword /
- flag_extension
-
- flag_extension ::= "\" atom
- ;; Future expansion. Client implementations
- ;; MUST accept flag_extension flags. Server
- ;; implementations MUST NOT generate
- ;; flag_extension flags except as defined by
- ;; future standard or standards-track
- ;; revisions of this specification.
-
- flag_keyword ::= atom
-
- flag_list ::= "(" #flag ")"
-
- greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
-
- header_line ::= astring
-
- header_list ::= "(" 1#header_line ")"
-
- LF ::= <ASCII LF, line feed, 0x0A>
-
- list ::= "LIST" SPACE mailbox SPACE list_mailbox
-
- list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string
-
- list_wildcards ::= "%" / "*"
-
- literal ::= "{" number "}" CRLF *CHAR8
- ;; Number represents the number of CHAR8 octets
-
- login ::= "LOGIN" SPACE userid SPACE password
-
- lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox
-
- mailbox ::= "INBOX" / astring
- ;; INBOX is case-insensitive; other names may be
- ;; case-sensitive depending on implementation.
-
- mailbox_data ::= "FLAGS" SPACE flag_list /
- "LIST" SPACE mailbox_list /
- "LSUB" SPACE mailbox_list /
- "MAILBOX" SPACE text /
- "SEARCH" [SPACE 1#nz_number] /
- number SPACE "EXISTS" / number SPACE "RECENT"
-
-
-
-
-Crispin [Page 58]
-
-RFC 1730 IMAP4 December 1994
-
-
- mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /
- "\Noselect" / "\Unmarked" / flag_extension) ")"
- SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
-
- message_data ::= nz_number SPACE ("EXPUNGE" /
- ("FETCH" SPACE msg_fetch) / msg_obsolete)
-
- msg_fetch ::= "(" 1#("BODY" SPACE body /
- "BODYSTRUCTURE" SPACE body /
- "BODY[" section "]" SPACE nstring /
- "ENVELOPE" SPACE envelope /
- "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
- "INTERNALDATE" SPACE date_time /
- "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
- "RFC822.SIZE" SPACE number /
- "UID" SPACE uniqueid) ")"
-
- msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch)
- ;; OBSOLETE untagged data responses
-
- nil ::= "NIL"
-
- nstring ::= string / nil
-
- number ::= 1*digit
- ;; Unsigned 32-bit integer
- ;; (0 <= n < 4,294,967,296)
-
- nz_number ::= digit_nz *digit
- ;; Non-zero unsigned 32-bit integer
- ;; (0 < n < 4,294,967,296)
-
- partial ::= "PARTIAL" SPACE nz_number SPACE
- ("BODY" [".PEEK"] "[" section "]" /
- "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")
- SPACE number SPACE number
-
- password ::= astring
-
- quoted ::= <"> *QUOTED_CHAR <">
-
- QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> /
- "\" quoted_specials
-
- quoted_specials ::= <"> / "\"
-
- rename ::= "RENAME" SPACE mailbox SPACE mailbox
- ;; Use of INBOX as a destination gives a NO error
-
-
-
-Crispin [Page 59]
-
-RFC 1730 IMAP4 December 1994
-
-
- response ::= *response_data response_done
-
- response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
- mailbox_data / message_data / capability_data)
- CRLF
-
- response_done ::= response_tagged / response_fatal
-
- response_fatal ::= "*" SPACE resp_cond_bye CRLF
-
- response_tagged ::= tag SPACE resp_cond_state CRLF
-
- resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
- ;; Authentication condition
-
- resp_cond_bye ::= "BYE" SPACE resp_text
- ;; Server will disconnect condition
-
- resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
- ;; Status condition
-
- resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
-
- resp_text_code ::= "ALERT" / "PARSE" /
- "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
- "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
- "UIDVALIDITY" SPACE nz_number /
- "UNSEEN" SPACE nz_number /
- atom [SPACE 1*<any TEXT_CHAR except "]">]
-
- search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
- search_criteria
- ;; Character set must be registered with IANA
- ;; as a MIME character set
-
- search_criteria ::= 1#search_key
-
- search_key ::= search_new / search_old
-
- search_new ::= "DRAFT" /
- "HEADER" SPACE header_line SPACE astring /
- "LARGER" SPACE number / "NOT" SPACE search_key /
- "OR" SPACE search_key SPACE search_key /
- "SENTBEFORE" SPACE date / "SENTON" SPACE date /
- "SENTSINCE" SPACE date / "SMALLER" SPACE number /
- "UID" SPACE set / "UNDRAFT" / set /
- "(" search_criteria ")"
- ;; New in IMAP4
-
-
-
-Crispin [Page 60]
-
-RFC 1730 IMAP4 December 1994
-
-
- search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
- "BEFORE" SPACE date / "BODY" SPACE astring /
- "CC" SPACE astring / "DELETED" / "FLAGGED" /
- "FROM" SPACE astring /
- "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
- "ON" SPACE date / "RECENT" / "SEEN" /
- "SINCE" SPACE date / "SUBJECT" SPACE astring /
- "TEXT" SPACE astring / "TO" SPACE astring /
- "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
- "UNKEYWORD" SPACE flag_keyword / "UNSEEN"
- ;; Defined in [IMAP2]
-
- section ::= "0" / nz_number ["." section]
-
- select ::= "SELECT" SPACE mailbox
-
- sequence_num ::= nz_number / "*"
- ;; * is the largest number in use. For message
- ;; sequence numbers, it is the number of messages
- ;; in the mailbox. For unique identifiers, it is
- ;; the unique identifier of the last message in
- ;; the mailbox.
-
- set ::= sequence_num / (sequence_num ":" sequence_num) /
- (set "," set)
- ;; Identifies a set of messages. For message
- ;; sequence numbers, these are consecutive
- ;; numbers from 1 to the number of messages in
- ;; the mailbox
- ;; Comma delimits individual numbers, colon
- ;; delimits between two numbers inclusive.
- ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
- ;; 14,15 for a mailbox with 15 messages.
-
- SPACE ::= <ASCII SP, space, 0x20>
-
- store ::= "STORE" SPACE set SPACE store_att_flags
-
- store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
- (flag_list / #flag)
-
- string ::= quoted / literal
-
- subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs
-
- subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
- ;;OBSOLETE
-
-
-
-
-Crispin [Page 61]
-
-RFC 1730 IMAP4 December 1994
-
-
- tag ::= 1*<any ATOM_CHAR except "+">
-
- text ::= 1*TEXT_CHAR
-
- text_mime2 ::= "=?" <charset> "?" <encoding> "?"
- <encoded-text> "?="
- ;; Syntax defined in [MIME-2]
-
- TEXT_CHAR ::= <any CHAR except CR and LF>
-
- time ::= 2digit ":" 2digit ":" 2digit
- ;; Hours minutes seconds
-
- uid ::= "UID" SPACE (copy / fetch / search / store)
- ;; Unique identifiers used instead of message
- ;; sequence numbers
-
- uniqueid ::= nz_number
- ;; Strictly ascending
-
- unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
-
- unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
- ;;OBSOLETE
-
- userid ::= astring
-
- x_command ::= "X" atom <experimental command arguments>
-
- zone ::= ("+" / "-") 4digit
- ;; Signed four-digit value of hhmm representing
- ;; hours and minutes west of Greenwich (that is,
- ;; (the amount that the given time differs from
- ;; Universal Time). Subtracting the timezone
- ;; from the given time will give the UT form.
- ;; The Universal Time zone is "+0000".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 62]
-
-RFC 1730 IMAP4 December 1994
-
-
- zone_old ::= "UT" / "GMT" / "Z" / ;; +0000
- "AST" / "EDT" / ;; -0400
- "EST" / "CDT" / ;; -0500
- "CST" / "MDT" / ;; -0600
- "MST" / "PDT" / ;; -0700
- "PST" / "YDT" / ;; -0800
- "YST" / "HDT" / ;; -0900
- "HST" / "BDT" / ;; -1000
- "BST" / ;; -1100
- "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
- "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
- "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
- "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12
- ;; OBSOLETE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 63]
-
-RFC 1730 IMAP4 December 1994
-
-
-10. Author's Note
-
- This document is a revision or rewrite of earlier documents, and
- supercedes the protocol specification in those documents: IMAP4
- Internet drafts, the IMAP2bis Internet drafts, unpublished
- IMAP2bis.TXT document, RFC 1176, and RFC 1064.
-
-
-11. Security Considerations
-
- IMAP4 protocol transactions, including electronic mail data, are sent
- in the clear over the network unless the optional privacy protection
- is negotiated in the AUTHENTICATE command.
-
- A server error message for an AUTHENTICATE command which fails due to
- invalid credentials should not detail why the credentials are
- invalid.
-
- Use of the LOGIN command sends passwords in the clear. This can be
- avoided by using the AUTHENTICATE command instead.
-
- A server error message for a failing LOGIN command should not specify
- that the user name, as opposed to the password, is invalid.
-
- Additional security considerations are discussed in the section
- discussing the AUTHENTICATE and LOGIN commands.
-
-
-12. Author's Address
-
- Mark R. Crispin
- Networks and Distributed Computing, JE-30
- University of Washington
- Seattle, WA 98195
-
- Phone: (206) 543-5762
-
- EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 64]
-
-RFC 1730 IMAP4 December 1994
-
-
-Appendices
-
-A. Obsolete Commands
-
- The following commands are OBSOLETE. It is NOT required to support
- any of these commands in new server implementations. These commands
- are documented here for the benefit of implementors who may wish to
- support them for compatibility with old client implementations.
-
- The section headings of these commands are intended to correspond
- with where they would be located in the main document if they were
- not obsoleted.
-
-
-A.6.3.OBS.1. FIND ALL.MAILBOXES Command
-
- Arguments: mailbox name with possible wildcards
-
- Data: untagged responses: MAILBOX
-
- Result: OK - find completed
- NO - find failure: can't list that name
- BAD - command unknown or arguments invalid
-
- The FIND ALL.MAILBOXES command returns a subset of names from the
- complete set of all names available to the user. It returns zero
- or more untagged MAILBOX replies. The mailbox argument to FIND
- ALL.MAILBOXES is similar to that for LIST with an empty reference,
- except that the characters "%" and "?" match a single character.
-
- Example: C: A002 FIND ALL.MAILBOXES *
- S: * MAILBOX blurdybloop
- S: * MAILBOX INBOX
- S: A002 OK FIND ALL.MAILBOXES completed
-
-
-A.6.3.OBS.2. FIND MAILBOXES Command
-
- Arguments: mailbox name with possible wildcards
-
- Data: untagged responses: MAILBOX
-
- Result: OK - find completed
- NO - find failure: can't list that name
- BAD - command unknown or arguments invalid
-
- The FIND MAILBOXES command returns a subset of names from the set
- of names that the user has declared as being "active" or
-
-
-
-Crispin [Page 65]
-
-RFC 1730 IMAP4 December 1994
-
-
- "subscribed". It returns zero or more untagged MAILBOX replies.
- The mailbox argument to FIND MAILBOXES is similar to that for LSUB
- with an empty reference, except that the characters "%" and "?"
- match a single character.
-
- Example: C: A002 FIND MAILBOXES *
- S: * MAILBOX blurdybloop
- S: * MAILBOX INBOX
- S: A002 OK FIND MAILBOXES completed
-
-
-A.6.3.OBS.3. SUBSCRIBE MAILBOX Command
-
- Arguments: mailbox name
-
- Data: no specific data for this command
-
- Result: OK - subscribe completed
- NO - subscribe failure: can't subscribe to that name
- BAD - command unknown or arguments invalid
-
- The SUBSCRIBE MAILBOX command is identical in effect to the
- SUBSCRIBE command. A server which implements this command must be
- able to distinguish between a SUBSCRIBE MAILBOX command and a
- SUBSCRIBE command with a mailbox name argument of "MAILBOX".
-
- Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
- S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
- completed
- C: A003 SUBSCRIBE MAILBOX
- S: A003 OK SUBSCRIBE to MAILBOX completed
-
-
-A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command
-
- Arguments: mailbox name
-
- Data: no specific data for this command
-
- Result: OK - unsubscribe completed
- NO - unsubscribe failure: can't unsubscribe that name
- BAD - command unknown or arguments invalid
-
- The UNSUBSCRIBE MAILBOX command is identical in effect to the
- UNSUBSCRIBE command. A server which implements this command must
- be able to distinguish between a UNSUBSCRIBE MAILBOX command and
- an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
-
-
-
-
-Crispin [Page 66]
-
-RFC 1730 IMAP4 December 1994
-
-
- Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
- S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
- completed
- C: A003 UNSUBSCRIBE MAILBOX
- S: A003 OK UNSUBSCRIBE from MAILBOX completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 67]
-
-RFC 1730 IMAP4 December 1994
-
-
-B. Obsolete Responses
-
- The following responses are OBSOLETE. Except as noted below, these
- responses MUST NOT be transmitted by new server implementations.
-
- The section headings of these responses are intended to correspond
- with where they would be located in the main document if they were
- not obsoleted.
-
-
-B.7.2.OBS.1. MAILBOX Response
-
- Data: name
-
- The MAILBOX response MUST NOT be transmitted by server
- implementations except in response to the obsolete FIND MAILBOXES
- and FIND ALL.MAILBOXES commands. Client implementations that do
- not use these commands MAY ignore this response. It is documented
- here for the benefit of implementors who may wish to support it
- for compatibility with old client implementations.
-
- This response occurs as a result of the FIND MAILBOXES and FIND
- ALL.MAILBOXES commands. It returns a single name that matches the
- FIND specification. There are no attributes or hierarchy
- delimiter.
-
- Example: S: * MAILBOX blurdybloop
-
-
-B.7.3.OBS.1. COPY Response
-
- Data: none
-
- The COPY response MUST NOT be transmitted by new server
- implementations. Client implementations MUST ignore the COPY
- response. It is documented here for the benefit of client
- implementors who may encounter this response from old server
- implementations.
-
- In some experimental versions of this protocol, this response was
- returned in response to a COPY command to indicate on a
- per-message basis that the message was copied successfully.
-
- Example: S: * 44 COPY
-
-
-
-
-
-
-
-Crispin [Page 68]
-
-RFC 1730 IMAP4 December 1994
-
-
-B.7.3.OBS.2. STORE Response
-
- Data: message data
-
- The STORE response MUST NOT be transmitted by new server
- implementations. Client implementations MUST treat the STORE
- response as equivalent to the FETCH response. It is documented
- here for the benefit of client implementors who may encounter this
- response from old server implementations.
-
- In some experimental versions of this protocol, this response was
- returned instead of FETCH in response to a STORE command to report
- the new value of the flags.
-
- Example: S: * 69 STORE (FLAGS (\Deleted))
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 69]
-
-RFC 1730 IMAP4 December 1994
-
-
-C. References
-
-
- [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
- Carnegie-Mellon University, December 1994.
-
- [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and
- IMAP2bis", RFC 1732, University of Washington, December 1994.
-
- [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected
- IMAP4 Clients", Work in Progress.
-
- [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in
- IMAP4", RFC 1733, University of Washington, December 1994.
-
- [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work
- in Progress.
-
- [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
- RFC 1176, University of Washington, August 1990.
-
- [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in
- Progress.
-
- [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet
- Mail Extensions) Part One: Mechanisms for Specifying and Describing
- the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
- September 1993.
-
- [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
- Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
- University of Tennessee, September 1993.
-
- [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, University of Delaware, August 1982.
-
- [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,
- RFC 821, USC/Information Sciences Institute, August 1982.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 70]
-
-RFC 1730 IMAP4 December 1994
-
-
-E. IMAP4 Keyword Index
-
-
- +FLAGS <flag list> (store command data item) ............... 34
- +FLAGS.SILENT <flag list> (store command data item) ........ 34
- -FLAGS <flag list> (store command data item) ............... 34
- -FLAGS.SILENT <flag list> (store command data item) ........ 34
- ALERT (response code) ...................................... 39
- ALL (fetch item) ........................................... 29
- ALL (search key) ........................................... 27
- ANSWERED (search key) ...................................... 27
- APPEND (command) ........................................... 22
- AUTHENTICATE (command) ..................................... 12
- BAD (response) ............................................. 41
- BCC <string> (search key) .................................. 27
- BEFORE <date> (search key) ................................. 27
- BODY (fetch item) .......................................... 29
- BODY (fetch result) ........................................ 46
- BODY <string> (search key) ................................. 27
- BODY.PEEK[<section>] (fetch item) .......................... 30
- BODYSTRUCTURE (fetch item) ................................. 31
- BODYSTRUCTURE (fetch result) ............................... 47
- BODY[<section>] (fetch item) ............................... 29
- BODY[section] (fetch result) ............................... 46
- BYE (response) ............................................. 41
- CAPABILITY (command) ....................................... 10
- CAPABILITY (response) ...................................... 42
- CC <string> (search key) ................................... 27
- CHECK (command) ............................................ 23
- CLOSE (command) ............................................ 24
- COPY (command) ............................................. 34
- COPY (response) ............................................ 68
- CREATE (command) ........................................... 17
- DELETE (command) ........................................... 18
- DELETED (search key) ....................................... 27
- DRAFT (search key) ......................................... 27
- ENVELOPE (fetch item) ...................................... 31
- ENVELOPE (fetch result) .................................... 49
- EXAMINE (command) .......................................... 16
- EXISTS (response) .......................................... 45
- EXPUNGE (command) .......................................... 25
- EXPUNGE (response) ......................................... 45
- FAST (fetch item) .......................................... 31
- FETCH (command) ............................................ 29
- FETCH (response) ........................................... 46
- FIND ALL.MAILBOXES (command) ............................... 65
- FIND MAILBOXES (command) ................................... 65
- FLAGGED (search key) ....................................... 27
- FLAGS (fetch item) ......................................... 31
-
-
-
-Crispin [Page 71]
-
-RFC 1730 IMAP4 December 1994
-
-
-
- FLAGS (fetch result) ....................................... 50
- FLAGS (response) ........................................... 44
- FLAGS <flag list> (store command data item) ................ 34
- FLAGS.SILENT <flag list> (store command data item) ......... 34
- FROM <string> (search key) ................................. 27
- FULL (fetch item) .......................................... 31
- HEADER <field-name> <string> (search key) .................. 27
- INTERNALDATE (fetch item) .................................. 31
- INTERNALDATE (fetch result) ................................ 50
- KEYWORD <flag> (search key) ................................ 27
- LARGER <n> (search key) .................................... 27
- LIST (command) ............................................. 20
- LIST (response) ............................................ 43
- LOGIN (command) ............................................ 14
- LOGOUT (command) ........................................... 11
- LSUB (command) ............................................. 22
- LSUB (response) ............................................ 44
- MAILBOX (response) ......................................... 68
- NEW (search key) ........................................... 27
- NO (response) .............................................. 40
- NOOP (command) ............................................. 11
- NOT <search-key> (search key) .............................. 28
- OK (response) .............................................. 40
- OLD (search key) ........................................... 28
- ON <date> (search key) ..................................... 28
- OR <search-key1> <search-key2> (search key) ................ 28
- PARSE (response code) ...................................... 39
- PARTIAL (command) .......................................... 32
- PERMANENTFLAGS (response code) ............................. 39
- PREAUTH (response) ......................................... 41
- READ-ONLY (response code) .................................. 39
- READ-WRITE (response code) ................................. 39
- RECENT (response) .......................................... 45
- RECENT (search key) ........................................ 28
- RENAME (command) ........................................... 18
- RFC822 (fetch item) ........................................ 31
- RFC822 (fetch result) ...................................... 50
- RFC822.HEADER (fetch item) ................................. 31
- RFC822.HEADER (fetch result) ............................... 50
- RFC822.HEADER.LINES <header_list> (fetch item) ............. 31
- RFC822.HEADER.LINES.NOT <header_list> (fetch item) ......... 32
- RFC822.PEEK (fetch item) ................................... 31
- RFC822.SIZE (fetch item) ................................... 32
- RFC822.SIZE (fetch result) ................................. 50
- RFC822.TEXT (fetch item) ................................... 32
- RFC822.TEXT (fetch result) ................................. 51
- RFC822.TEXT.PEEK (fetch item) .............................. 32
- SEARCH (command) ........................................... 25
-
-
-
-Crispin [Page 72]
-
-RFC 1730 IMAP4 December 1994
-
-
-
- SEARCH (response) .......................................... 44
- SEEN (search key) .......................................... 28
- SELECT (command) ........................................... 15
- SENTBEFORE <date> (search key) ............................. 28
- SENTON <date> (search key) ................................. 28
- SENTSINCE <date> (search key) .............................. 28
- SINCE <date> (search key) .................................. 28
- SMALLER <n> (search key) ................................... 28
- STORE (command) ............................................ 33
- STORE (response) ........................................... 69
- SUBJECT <string> (search key) .............................. 28
- SUBSCRIBE (command) ........................................ 19
- SUBSCRIBE MAILBOX (command) ................................ 66
- TEXT <string> (search key) ................................. 28
- TO <string> (search key) ................................... 28
- TRYCREATE (response code) .................................. 39
- UID (command) .............................................. 35
- UID (fetch item) ........................................... 32
- UID (fetch result) ......................................... 51
- UID <message set> (search key) ............................. 28
- UIDVALIDITY (response code) ................................ 40
- UNANSWERED (search key) .................................... 29
- UNDELETED (search key) ..................................... 29
- UNDRAFT (search key) ....................................... 29
- UNFLAGGED (search key) ..................................... 29
- UNKEYWORD <flag> (search key) .............................. 29
- UNSEEN (response code) ..................................... 40
- UNSEEN (search key) ........................................ 29
- UNSUBSCRIBE (command) ...................................... 19
- UNSUBSCRIBE MAILBOX (command) .............................. 66
- X<atom> (command) .......................................... 37
- \Answered (system flag) .................................... 50
- \Deleted (system flag) ..................................... 50
- \Draft (system flag) ....................................... 50
- \Flagged (system flag) ..................................... 50
- \Marked (mailbox name attribute) ........................... 43
- \Noinferiors (mailbox name attribute) ...................... 43
- \Noselect (mailbox name attribute) ......................... 43
- \Recent (system flag) ...................................... 50
- \Seen (system flag) ........................................ 50
- \Unmarked (mailbox name attribute) ......................... 43
-
-
-
-
-
-
-
-
-
-
-Crispin [Page 73]
-
diff --git a/RFC/rfc1731.txt b/RFC/rfc1731.txt deleted file mode 100644 index 42215dec..00000000 --- a/RFC/rfc1731.txt +++ /dev/null @@ -1,339 +0,0 @@ -
-
-
-
-
-
-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 deleted file mode 100644 index cfae89c0..00000000 --- a/RFC/rfc1732.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -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 deleted file mode 100644 index f37f29e0..00000000 --- a/RFC/rfc1734.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -Network Working Group J. Myers -Request for Comments: 1734 Carnegie Mellon -Category: Standards Track December 1994 - - - POP3 AUTHentication command - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - - -1. Introduction - - This document describes the optional AUTH command, for indicating an - authentication mechanism to the server, performing an authentication - protocol exchange, and optionally negotiating a protection mechanism - for subsequent protocol interactions. The authentication and - protection mechanisms used by the POP3 AUTH command are those used by - IMAP4. - - -2. The AUTH command - - AUTH mechanism - - Arguments: - a string identifying an IMAP4 authentication mechanism, - such as defined by [IMAP4-AUTH]. Any use of the string - "imap" used in a server authentication identity in the - definition of an authentication mechanism is replaced with - the string "pop". - - Restrictions: - may only be given in the AUTHORIZATION state - - Discussion: - The AUTH command indicates an authentication mechanism to - the server. If the server supports the requested - authentication mechanism, it performs an authentication - protocol exchange to authenticate and identify the user. - Optionally, it also negotiates a protection mechanism for - subsequent protocol interactions. If the requested - authentication mechanism is not supported, the server - - - -Myers [Page 1] - -RFC 1734 POP3 AUTH December 1994 - - - should reject the AUTH command by sending a negative - response. - - The authentication protocol exchange consists of a series - of server challenges and client answers that are specific - to the authentication mechanism. A server challenge, - otherwise known as a ready response, is a line consisting - of a "+" character followed by a single space and a BASE64 - encoded string. The client answer consists of a line - containing a BASE64 encoded string. If the client wishes - to cancel an authentication exchange, it should issue a - line with a single "*". If the server receives such an - answer, it must reject the AUTH command by sending a - negative response. - - A protection mechanism provides integrity and privacy - protection to the protocol session. If a protection - mechanism is negotiated, it is applied to all subsequent - data sent over the connection. The protection mechanism - takes effect immediately following the CRLF that concludes - the authentication exchange for the client, and the CRLF of - the positive response for the server. Once the protection - mechanism is in effect, the stream of command and response - octets is processed into buffers of ciphertext. Each - buffer is transferred over the connection as a stream of - octets prepended with a four octet field in network byte - order that represents the length of the following data. - The maximum ciphertext buffer length is defined by the - protection mechanism. - - The server is not required to support any particular - authentication mechanism, nor are authentication mechanisms - required to support any protection mechanisms. If an AUTH - command fails with a negative response, the session remains - in the AUTHORIZATION state and client may try another - authentication mechanism by issuing another AUTH command, - or may attempt to authenticate by using the USER/PASS or - APOP commands. In other words, the client may request - authentication types in decreasing order of preference, - with the USER/PASS or APOP command as a last resort. - - Should the client successfully complete the authentication - exchange, the POP3 server issues a positive response and - the POP3 session enters the TRANSACTION state. - - Possible Responses: - +OK maildrop locked and ready - -ERR authentication exchange failed - - - -Myers [Page 2] - -RFC 1734 POP3 AUTH December 1994 - - - - Examples: - S: +OK POP3 server ready - C: AUTH KERBEROS_V4 - S: + AmFYig== - C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT - +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd - WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh - S: + or//EoAADZI= - C: DiAF5A4gA+oOIALuBkAAmw== - S: +OK Kerberos V4 authentication successful - ... - C: AUTH FOOBAR - S: -ERR Unrecognized authentication type - - Note: the line breaks in the first client answer are - for editorial clarity and are not in real authentica- - tors. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers [Page 3] - -RFC 1734 POP3 AUTH December 1994 - - -3. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in RFC 822. - - Except as noted otherwise, all alphabetic characters are case- - insensitive. The use of upper or lower case characters to define - token strings is for editorial clarity only. Implementations MUST - accept these strings in a case-insensitive fashion. - - ATOM_CHAR ::= <any CHAR except atom_specials> - - atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" / - <"> / "\" - - auth ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64) - CRLF - - auth_type ::= 1*ATOM_CHAR - - base64 ::= *(4base64_CHAR) [base64_terminal] - - base64_char ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / - "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / - "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / - "Y" / "Z" / - "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / - "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / - "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / - "y" / "z" / - "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / - "8" / "9" / "+" / "/" - ;; Case-sensitive - - base64_terminal ::= (2base64_char "==") / (3base64_char "=") - - CHAR ::= <any 7-bit US-ASCII character except NUL, - 0x01 - 0x7f> - - continue_req ::= "+" SPACE base64 CRLF - - CR ::= <ASCII CR, carriage return, 0x0C> - - CRLF ::= CR LF - - CTL ::= <any ASCII control character and DEL, - 0x00 - 0x1f, 0x7f> - - - - -Myers [Page 4] - -RFC 1734 POP3 AUTH December 1994 - - - LF ::= <ASCII LF, line feed, 0x0A> - - SPACE ::= <ASCII SP, space, 0x20> - - TAB ::= <ASCII HT, tab, 0x09> - - - -4. References - - [IMAP4-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731, - Carnegie Mellon, December 1994. - - - -5. Security Considerations - - Security issues are discussed throughout this memo. - - - -6. Author's Address - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave - Pittsburgh, PA 15213 - - EMail: jgm+@cmu.edu - - - - - - - - - - - - - - - - - - - - - - -Myers [Page 5] - diff --git a/RFC/rfc1870.txt b/RFC/rfc1870.txt deleted file mode 100644 index e24ccec6..00000000 --- a/RFC/rfc1870.txt +++ /dev/null @@ -1,507 +0,0 @@ -
-
-
-
-
-
-Network Working Group J. Klensin, WG Chair
-Request For Comments: 1870 MCI
-STD: 10 N. Freed, Editor
-Obsoletes: 1653 Innosoft International, Inc.
-Category: Standards Track K. Moore
- University of Tennessee
- November 1995
-
-
- SMTP Service Extension
- for Message Size Declaration
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-1. Abstract
-
- This memo defines an extension to the SMTP service whereby an SMTP
- client and server may interact to give the server an opportunity to
- decline to accept a message (perhaps temporarily) based on the
- client's estimate of the message size.
-
-2. Introduction
-
- The MIME extensions to the Internet message protocol provide for the
- transmission of many kinds of data which were previously unsupported
- in Internet mail. One expected result of the use of MIME is that
- SMTP will be expected to carry a much wider range of message sizes
- than was previously the case. This has an impact on the amount of
- resources (e.g. disk space) required by a system acting as a server.
-
- This memo uses the mechanism defined in [5] to define extensions to
- the SMTP service whereby a client ("sender-SMTP") may declare the
- size of a particular message to a server ("receiver-SMTP"), after
- which the server may indicate to the client that it is or is not
- willing to accept the message based on the declared message size and
- whereby a server ("receiver-SMTP") may declare the maximum message
- size it is willing to accept to a client ("sender-SMTP").
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 1]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-3. Framework for the Size Declaration Extension
-
- The following service extension is therefore defined:
-
- (1) the name of the SMTP service extension is "Message Size
- Declaration";
-
- (2) the EHLO keyword value associated with this extension is "SIZE";
-
- (3) one optional parameter is allowed with this EHLO keyword value, a
- decimal number indicating the fixed maximum message size in bytes
- that the server will accept. The syntax of the parameter is as
- follows, using the augmented BNF notation of [2]:
-
- size-param ::= [1*DIGIT]
-
- A parameter value of 0 (zero) indicates that no fixed maximum
- message size is in force. If the parameter is omitted no
- information is conveyed about the server's fixed maximum message
- size;
-
- (4) one optional parameter using the keyword "SIZE" is added to the
- MAIL FROM command. The value associated with this parameter is a
- decimal number indicating the size of the message that is to be
- transmitted. The syntax of the value is as follows, using the
- augmented BNF notation of [2]:
-
- size-value ::= 1*20DIGIT
-
- (5) the maximum length of a MAIL FROM command line is increased by 26
- characters by the possible addition of the SIZE keyword and
- value;
-
- (6) no additional SMTP verbs are defined by this extension.
-
- The remainder of this memo specifies how support for the extension
- affects the behavior of an SMTP client and server.
-
-4. The Message Size Declaration service extension
-
- An SMTP server may have a fixed upper limit on message size. Any
- attempt by a client to transfer a message which is larger than this
- fixed upper limit will fail. In addition, a server normally has
- limited space with which to store incoming messages. Transfer of a
- message may therefore also fail due to a lack of storage space, but
- might succeed at a later time.
-
-
-
-
-
-Klensin, et al Standards Track [Page 2]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
- A client using the unextended SMTP protocol defined in [1], can only
- be informed of such failures after transmitting the entire message to
- the server (which discards the transferred message). If, however,
- both client and server support the Message Size Declaration service
- extension, such conditions may be detected before any transfer is
- attempted.
-
- An SMTP client wishing to relay a large content may issue the EHLO
- command to start an SMTP session, to determine if the server supports
- any of several service extensions. If the server responds with code
- 250 to the EHLO command, and the response includes the EHLO keyword
- value SIZE, then the Message Size Declaration extension is supported.
-
- If a numeric parameter follows the SIZE keyword value of the EHLO
- response, it indicates the size of the largest message that the
- server is willing to accept. Any attempt by a client to transfer a
- message which is larger than this limit will be rejected with a
- permanent failure (552) reply code.
-
- A server that supports the Message Size Declaration extension will
- accept the extended version of the MAIL command described below.
- When supported by the server, a client may use the extended MAIL
- command (instead of the MAIL command as defined in [1]) to declare an
- estimate of the size of a message it wishes to transfer. The server
- may then return an appropriate error code if it determines that an
- attempt to transfer a message of that size would fail.
-
-5. Definitions
-
- The message size is defined as the number of octets, including CR-LF
- pairs, but not the SMTP DATA command's terminating dot or doubled
- quoting dots, to be transmitted by the SMTP client after receiving
- reply code 354 to the DATA command.
-
- The fixed maximum message size is defined as the message size of the
- largest message that a server is ever willing to accept. An attempt
- to transfer any message larger than the fixed maximum message size
- will always fail. The fixed maximum message size may be an
- implementation artifact of the SMTP server, or it may be chosen by
- the administrator of the server.
-
- The declared message size is defined as a client's estimate of the
- message size for a particular message.
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 3]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-6. The extended MAIL command
-
- The extended MAIL command is issued by a client when it wishes to
- inform a server of the size of the message to be sent. The extended
- MAIL command is identical to the MAIL command as defined in [1],
- except that a SIZE parameter appears after the address.
-
- The complete syntax of this extended command is defined in [5]. The
- esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by
- the syntax for size-value shown above.
-
- The value associated with the SIZE parameter is a decimal
- representation of the declared message size in octets. This number
- should include the message header, body, and the CR-LF sequences
- between lines, but not the SMTP DATA command's terminating dot or
- doubled quoting dots. Only one SIZE parameter may be specified in a
- single MAIL command.
-
- Ideally, the declared message size is equal to the true message size.
- However, since exact computation of the message size may be
- infeasable, the client may use a heuristically-derived estimate.
- Such heuristics should be chosen so that the declared message size is
- usually larger than the actual message size. (This has the effect of
- making the counting or non-counting of SMTP DATA dots largely an
- academic point.)
-
- NOTE: Servers MUST NOT use the SIZE parameter to determine end of
- content in the DATA command.
-
-6.1 Server action on receipt of the extended MAIL command
-
- Upon receipt of an extended MAIL command containing a SIZE parameter,
- a server should determine whether the declared message size exceeds
- its fixed maximum message size. If the declared message size is
- smaller than the fixed maximum message size, the server may also wish
- to determine whether sufficient resources are available to buffer a
- message of the declared message size and to maintain it in stable
- storage, until the message can be delivered or relayed to each of its
- recipients.
-
- A server may respond to the extended MAIL command with any of the
- error codes defined in [1] for the MAIL command. In addition, one of
- the following error codes may be returned:
-
- (1) If the server currently lacks sufficient resources to accept a
- message of the indicated size, but may be able to accept the
- message at a later time, it responds with code "452 insufficient
- system storage".
-
-
-
-Klensin, et al Standards Track [Page 4]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
- (2) If the indicated size is larger than the server's fixed maximum
- message size, the server responds with code "552 message size
- exceeds fixed maximium message size".
-
- A server is permitted, but not required, to accept a message which
- is, in fact, larger than declared in the extended MAIL command, such
- as might occur if the client employed a size-estimation heuristic
- which was inaccurate.
-
-6.2 Client action on receiving response to extended MAIL command
-
- The client, upon receiving the server's response to the extended MAIL
- command, acts as follows:
-
- (1) If the code "452 insufficient system storage" is returned, the
- client should next send either a RSET command (if it wishes to
- attempt to send other messages) or a QUIT command. The client
- should then repeat the attempt to send the message to the server
- at a later time.
-
- (2) If the code "552 message exceeds fixed maximum message size" is
- received, the client should immediately send either a RSET command
- (if it wishes to attempt to send additional messages), or a QUIT
- command. The client should then declare the message undeliverable
- and return appropriate notification to the sender (if a sender
- address was present in the MAIL command).
-
- A successful (250) reply code in response to the extended MAIL
- command does not constitute an absolute guarantee that the message
- transfer will succeed. SMTP clients using the extended MAIL command
- must still be prepared to handle both temporary and permanent error
- reply codes (including codes 452 and 552), either immediately after
- issuing the DATA command, or after transfer of the message.
-
-6.3 Messages larger than the declared size.
-
- Once a server has agreed (via the extended MAIL command) to accept a
- message of a particular size, it should not return a 552 reply code
- after the transfer phase of the DATA command, unless the actual size
- of the message transferred is greater than the declared message size.
- A server may also choose to accept a message which is somewhat larger
- than the declared message size.
-
- A client is permitted to declare a message to be smaller than its
- actual size. However, in this case, a successful (250) reply code is
- no assurance that the server will accept the message or has
- sufficient resources to do so. The server may reject such a message
- after its DATA transfer.
-
-
-
-Klensin, et al Standards Track [Page 5]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-6.4 Per-recipient rejection based on message size.
-
- A server that implements this extension may return a 452 or 552 reply
- code in response to a RCPT command, based on its unwillingness to
- accept a message of the declared size for a particular recipient.
-
- (1) If a 452 code is returned, the client may requeue the message for
- later delivery to the same recipient.
-
- (2) If a 552 code is returned, the client may not requeue the message
- for later delivery to the same recipient.
-
-7. Minimal usage
-
- A "minimal" client may use this extension to simply compare its
- (perhaps estimated) size of the message that it wishes to relay, with
- the server's fixed maximum message size (from the parameter to the
- SIZE keyword in the EHLO response), to determine whether the server
- will ever accept the message. Such an implementation need not
- declare message sizes via the extended MAIL command. However,
- neither will it be able to discover temporary limits on message size
- due to server resource limitations, nor per-recipient limitations on
- message size.
-
- A minimal server that employs this service extension may simply use
- the SIZE keyword value to inform the client of the size of the
- largest message it will accept, or to inform the client that there is
- no fixed limit on message size. Such a server must accept the
- extended MAIL command and return a 552 reply code if the client's
- declared size exceeds its fixed size limit (if any), but it need not
- detect "temporary" limitations on message size.
-
- The numeric parameter to the EHLO SIZE keyword is optional. If the
- parameter is omitted entirely it indicates that the server does not
- advertise a fixed maximum message size. A server that returns the
- SIZE keyword with no parameter in response to the EHLO command may
- not issue a positive (250) response to an extended MAIL command
- containing a SIZE specification without first checking to see if
- sufficient resources are available to transfer a message of the
- declared size, and to retain it in stable storage until it can be
- relayed or delivered to its recipients. If possible, the server
- should actually reserve sufficient storage space to transfer the
- message.
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 6]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-8. Example
-
- The following example illustrates the use of size declaration with
- some permanent and temporary failures.
-
- S: <wait for connection on TCP port 25>
- C: <open connection to server>
- S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
- C: EHLO ymir.claremont.edu
- S: 250-sigurd.innosoft.com
- S: 250-EXPN
- S: 250-HELP
- S: 250 SIZE 1000000
- C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000
- S: 250 Address Ok.
- C: RCPT TO:<ned@innosoft.com>
- S: 250 ned@innosoft.com OK; can accomodate 500000 byte message
- C: RCPT TO:<ned@ymir.claremont.edu>
- S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU
- C: RCPT TO:<ned@hmcvax.claremont.edu>
- S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU
- C: DATA
- S: 354 Send message, ending in CRLF.CRLF.
- ...
- C: .
- S: 250 Some recipients OK
- C: QUIT
- S: 221 Goodbye
-
-9. Security Considerations
-
- The size declaration extensions described in this memo can
- conceivably be used to facilitate crude service denial attacks.
- Specifically, both the information contained in the SIZE parameter
- and use of the extended MAIL command make it somewhat quicker and
- easier to devise an efficacious service denial attack. However,
- unless implementations are very weak, these extensions do not create
- any vulnerability that has not always existed with SMTP. In addition,
- no issues are addressed involving trusted systems and possible
- release of information via the mechanisms described in this RFC.
-
-10. Acknowledgements
-
- This document was derived from an earlier Working Group work in
- progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot
- Lear, Marshall T. Rose, and Einar Stefferud provided extensive
- comments in response to earlier works in progress of both this and
- the previous memo.
-
-
-
-Klensin, et al Standards Track [Page 7]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-11. References
-
- [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
- USC/Information Sciences Institute, August 1982.
-
- [2] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, UDEL, August 1982.
-
- [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
- Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
-
- [4] Moore, K., "Representation of Non-ASCII Text in Internet Message
- Headers", RFC 1522, University of Tennessee, September 1993.
-
- [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
- "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft
- International, Inc., Dover Beach Consulting, Inc., Network
- Management Associates, Inc., Brandenburg Consulting, November
- 1995.
-
- [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
- 974, BBN, January 1986.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 8]
-
-RFC 1870 SMTP Size Declaration November 1995
-
-
-12. Chair, Editor, and Author Addresses
-
- John Klensin, WG Chair
- MCI
- 2100 Reston Parkway
- Reston, VA 22091
-
- Phone: +1 703 715-7361
- Fax: +1 703 715-7436
- EMail: klensin@mci.net
-
-
- Ned Freed, Editor
- Innosoft International, Inc.
- 1050 East Garvey Avenue South
- West Covina, CA 91790
- USA
-
- Phone: +1 818 919 3600
- Fax: +1 818 919 3614
- EMail: ned@innosoft.com
-
-
- Keith Moore
- Computer Science Dept.
- University of Tennessee
- 107 Ayres Hall
- Knoxville, TN 37996-1301
- USA
-
- EMail: moore@cs.utk.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin, et al Standards Track [Page 9]
-
diff --git a/RFC/rfc1891.txt b/RFC/rfc1891.txt deleted file mode 100644 index 23b58ba9..00000000 --- a/RFC/rfc1891.txt +++ /dev/null @@ -1,1739 +0,0 @@ - - - - - - -Network Working Group K. Moore -Request for Comments: 1891 University of Tennessee -Category: Standards Track January 1996 - - - SMTP Service Extension - for Delivery Status Notifications - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1. Abstract - - This memo defines an extension to the SMTP service, which allows an - SMTP client to specify (a) that delivery status notifications (DSNs) - should be generated under certain conditions, (b) whether such - notifications should return the contents of the message, and (c) - additional information, to be returned with a DSN, that allows the - sender to identify both the recipient(s) for which the DSN was - issued, and the transaction in which the original message was sent. - - Any questions, comments, and reports of defects or ambiguities in - this specification may be sent to the mailing list for the NOTARY - working group of the IETF, using the address - <notifications@cs.utk.edu>. Requests to subscribe to the mailing - list should be addressed to <notifications-request@cs.utk.edu>. - Implementors of this specification are encouraged to subscribe to the - mailing list, so that they will quickly be informed of any problems - which might hinder interoperability. - - NOTE: This document is a Proposed Standard. If and when this - protocol is submitted for Draft Standard status, any normative text - (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in - this document will be re-evaluated in light of implementation - experience, and are thus subject to change. - -2. Introduction - - The SMTP protocol [1] requires that an SMTP server provide - notification of delivery failure, if it determines that a message - cannot be delivered to one or more recipients. Traditionally, such - notification consists of an ordinary Internet mail message (format - defined by [2]), sent to the envelope sender address (the argument of - - - -Moore Standards Track [Page 1] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - the SMTP MAIL command), containing an explanation of the error and at - least the headers of the failed message. - - Experience with large mail distribution lists [3] indicates that such - messages are often insufficient to diagnose problems, or even to - determine at which host or for which recipients a problem occurred. - In addition, the lack of a standardized format for delivery - notifications in Internet mail makes it difficult to exchange such - notifications with other message handling systems. - - Such experience has demonstrated a need for a delivery status - notification service for Internet electronic mail, which: - -(a) is reliable, in the sense that any DSN request will either be - honored at the time of final delivery, or result in a response - that indicates that the request cannot be honored, - -(b) when both success and failure notifications are requested, - provides an unambiguous and nonconflicting indication of whether - delivery of a message to a recipient succeeded or failed, - -(c) is stable, in that a failed attempt to deliver a DSN should never - result in the transmission of another DSN over the network, - -(d) preserves sufficient information to allow the sender to identify - both the mail transaction and the recipient address which caused - the notification, even when mail is forwarded or gatewayed to - foreign environments, and - -(e) interfaces acceptably with non-SMTP and non-822-based mail - systems, both so that notifications returned from foreign mail - systems may be useful to Internet users, and so that the - notification requests from foreign environments may be honored. - Among the requirements implied by this goal are the ability to - request non-return-of-content, and the ability to specify whether - positive delivery notifications, negative delivery notifications, - both, or neither, should be issued. - - In an attempt to provide such a service, this memo uses the mechanism - defined in [4] to define an extension to the SMTP protocol. Using - this mechanism, an SMTP client may request that an SMTP server issue - or not issue a delivery status notification (DSN) under certain - conditions. The format of a DSN is defined in [5]. - - - - - - - - -Moore Standards Track [Page 2] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -3. Framework for the Delivery Status Notification Extension - - The following service extension is therefore defined: - -(1) The name of the SMTP service extension is "Delivery Status - Notification"; - -(2) the EHLO keyword value associated with this extension is "DSN", - the meaning of which is defined in section 4 of this memo; - -(3) no parameters are allowed with this EHLO keyword value; - -(4) two optional parameters are added to the RCPT command, and two - optional parameters are added to the MAIL command: - - An optional parameter for the RCPT command, using the - esmtp-keyword "NOTIFY", (to specify the conditions under which a - delivery status notification should be generated), is defined in - section 5.1, - - An optional parameter for the RCPT command, using the - esmtp-keyword "ORCPT", (used to convey the "original" - (sender-specified) recipient address), is defined in section 5.2, - and - - An optional parameter for the MAIL command, using the - esmtp-keyword "RET", (to request that DSNs containing an - indication of delivery failure either return the entire contents - of a message or only the message headers), is defined in section - 5.3, - - An optional parameter for the MAIL command, using the - esmtp-keyword "ENVID", (used to propagate an identifier for this - message transmission envelope, which is also known to the sender - and will, if present, be returned in any DSNs issued for this - transmission), is defined in section 5.4; - -(5) no additional SMTP verbs are defined by this extension. - - The remainder of this memo specifies how support for the extension - effects the behavior of a message transfer agent. - -4. The Delivery Status Notification service extension - - An SMTP client wishing to request a DSN for a message may issue the - EHLO command to start an SMTP session, to determine if the server - supports any of several service extensions. If the server responds - with code 250 to the EHLO command, and the response includes the EHLO - - - -Moore Standards Track [Page 3] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - keyword DSN, then the Delivery Status Notification extension (as - described in this memo) is supported. - - Ordinarily, when an SMTP server returns a positive (2xx) reply code - in response to a RCPT command, it agrees to accept responsibility for - either delivering the message to the named recipient, or sending a - notification to the sender of the message indicating that delivery - has failed. However, an extended SMTP ("ESMTP") server which - implements this service extension will accept an optional NOTIFY - parameter with the RCPT command. If present, the NOTIFY parameter - alters the conditions for generation of delivery status notifications - from the default (issue notifications only on failure) specified in - [1]. The ESMTP client may also request (via the RET parameter) - whether the entire contents of the original message should be - returned (as opposed to just the headers of that message), along with - the DSN. - - In general, an ESMTP server which implements this service extension - will propagate delivery status notification requests when relaying - mail to other SMTP-based MTAs which also support this extension, and - make a "best effort" to ensure that such requests are honored when - messages are passed into other environments. - - In order that any delivery status notifications thus generated will - be meaningful to the sender, any ESMTP server which supports this - extension will attempt to propagate the following information to any - other MTAs that are used to relay the message, for use in generating - DSNs: - -(a) for each recipient, a copy of the original recipient address, as - used by the sender of the message. - - This address need not be the same as the mailbox specified in the - RCPT command. For example, if a message was originally addressed - to A@B.C and later forwarded to A@D.E, after such forwarding has - taken place, the RCPT command will specify a mailbox of A@D.E. - However, the original recipient address remains A@B.C. - - Also, if the message originated from an environment which does not - use Internet-style user@domain addresses, and was gatewayed into - SMTP, the original recipient address will preserve the original - form of the recipient address. - -(b) for the entire SMTP transaction, an envelope identification - string, which may be used by the sender to associate any delivery - status notifications with the transaction used to send the - original message. - - - - -Moore Standards Track [Page 4] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -5. Additional parameters for RCPT and MAIL commands - - The extended RCPT and MAIL commands are issued by a client when it - wishes to request a DSN from the server, under certain conditions, - for a particular recipient. The extended RCPT and MAIL commands are - identical to the RCPT and MAIL commands defined in [1], except that - one or more of the following parameters appear after the sender or - recipient address, respectively. The general syntax for extended - SMTP commands is defined in [4]. - - NOTE: Although RFC 822 ABNF is used to describe the syntax of these - parameters, they are not, in the language of that document, - "structured field bodies". Therefore, while parentheses MAY appear - within an emstp-value, they are not recognized as comment delimiters. - - The syntax for "esmtp-value" in [4] does not allow SP, "=", control - characters, or characters outside the traditional ASCII range of 1- - 127 decimal to be transmitted in an esmtp-value. Because the ENVID - and ORCPT parameters may need to convey values outside this range, - the esmtp-values for these parameters are encoded as "xtext". - "xtext" is formally defined as follows: - - xtext = *( xchar / hexchar ) - - xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, - except for "+" and "=". - -; "hexchar"s are intended to encode octets that cannot appear -; as ASCII characters within an esmtp-value. - - hexchar = ASCII "+" immediately followed by two upper case - hexadecimal digits - -When encoding an octet sequence as xtext: - -+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", - MAY be encoded as itself. (A CHAR in this range MAY instead be - encoded as a "hexchar", at the implementor's discretion.) - -+ ASCII CHARs that fall outside the range above must be encoded as - "hexchar". - -5.1 The NOTIFY parameter of the ESMTP RCPT command - - A RCPT command issued by a client may contain the optional esmtp- - keyword "NOTIFY", to specify the conditions under which the SMTP - server should generate DSNs for that recipient. If the NOTIFY - esmtp-keyword is used, it MUST have an associated esmtp-value, - - - -Moore Standards Track [Page 5] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - formatted according to the following rules, using the ABNF of RFC - 822: - - notify-esmtp-value = "NEVER" / 1#notify-list-element - - notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" - -Notes: - -a. Multiple notify-list-elements, separated by commas, MAY appear in a - NOTIFY parameter; however, the NEVER keyword MUST appear by itself. - -b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled - in any combination of upper and lower case letters. - -The meaning of the NOTIFY parameter values is generally as follows: - -+ A NOTIFY parameter value of "NEVER" requests that a DSN not be - returned to the sender under any conditions. - -+ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" - keywords requests that a DSN be issued on successful delivery or - delivery failure, respectively. - -+ A NOTIFY parameter value containing the keyword "DELAY" indicates the - sender's willingness to receive "delayed" DSNs. Delayed DSNs may be - issued if delivery of a message has been delayed for an unusual amount - of time (as determined by the MTA at which the message is delayed), - but the final delivery status (whether successful or failure) cannot - be determined. The absence of the DELAY keyword in a NOTIFY parameter - requests that a "delayed" DSN NOT be issued under any conditions. - - The actual rules governing interpretation of the NOTIFY parameter are - given in section 6. - - For compatibility with SMTP clients that do not use the NOTIFY - facility, the absence of a NOTIFY parameter in a RCPT command may be - interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. - -5.2 The ORCPT parameter to the ESMTP RCPT command - - The ORCPT esmtp-keyword of the RCPT command is used to specify an - "original" recipient address that corresponds to the actual recipient - to which the message is to be delivered. If the ORCPT esmtp-keyword - is used, it MUST have an associated esmtp-value, which consists of - the original recipient address, encoded according to the rules below. - The ABNF for the ORCPT parameter is: - - - - -Moore Standards Track [Page 6] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - orcpt-parameter = "ORCPT=" original-recipient-address - - original-recipient-address = addr-type ";" xtext - - addr-type = atom - - The "addr-type" portion MUST be an IANA-registered electronic mail - address-type (as defined in [5]), while the "xtext" portion contains - an encoded representation of the original recipient address using the - rules in section 5 of this document. The entire ORCPT parameter MAY - be up to 500 characters in length. - - When initially submitting a message via SMTP, if the ORCPT parameter - is used, it MUST contain the same address as the RCPT TO address - (unlike the RCPT TO address, the ORCPT parameter will be encoded as - xtext). Likewise, when a mailing list submits a message via SMTP to - be distributed to the list subscribers, if ORCPT is used, the ORCPT - parameter MUST match the new RCPT TO address of each recipient, not - the address specified by the original sender of the message.) - - The "addr-type" portion of the original-recipient-address is used to - indicate the "type" of the address which appears in the ORCPT - parameter value. However, the address associated with the ORCPT - keyword is NOT constrained to conform to the syntax rules for that - "addr-type". - - Ideally, the "xtext" portion of the original-recipient-address should - contain, in encoded form, the same sequence of characters that the - sender used to specify the recipient. However, for a message - gatewayed from an environment (such as X.400) in which a recipient - address is not a simple string of printable characters, the - representation of recipient address must be defined by a - specification for gatewaying between DSNs and that environment. - -5.3 The RET parameter of the ESMTP MAIL command - - The RET esmtp-keyword on the extended MAIL command specifies whether - or not the message should be included in any failed DSN issued for - this message transmission. If the RET esmtp-keyword is used, it MUST - have an associated esmtp-value, which is one of the following - keywords: - - FULL requests that the entire message be returned in any "failed" - delivery status notification issued for this recipient. - - HDRS requests that only the headers of the message be returned. - - - - - -Moore Standards Track [Page 7] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - The FULL and HDRS keywords may be spelled in any combination of upper - and lower case letters. - - If no RET parameter is supplied, the MTA MAY return either the - headers of the message or the entire message for any DSN containing - indication of failed deliveries. - - Note that the RET parameter only applies to DSNs that indicate - delivery failure for at least one recipient. If a DSN contains no - indications of delivery failure, only the headers of the message - should be returned. - -5.4 The ENVID parameter to the ESMTP MAIL command - - The ENVID esmtp-keyword of the SMTP MAIL command is used to specify - an "envelope identifier" to be transmitted along with the message and - included in any DSNs issued for any of the recipients named in this - SMTP transaction. The purpose of the envelope identifier is to allow - the sender of a message to identify the transaction for which the DSN - was issued. - - The ABNF for the ENVID parameter is: - - envid-parameter = "ENVID=" xtext - - The ENVID esmtp-keyword MUST have an associated esmtp-value. No - meaning is assigned by the mail system to the presence or absence of - this parameter or to any esmtp-value associated with this parameter; - the information is used only by the sender or his user agent. The - ENVID parameter MAY be up to 100 characters in length. - -5.5 Restrictions on the use of Delivery Status Notification parameters - - The RET and ENVID parameters MUST NOT appear more than once each in - any single MAIL command. If more than one of either of these - parameters appears in a MAIL command, the ESMTP server SHOULD respond - with "501 syntax error in parameters or arguments". - - The NOTIFY and ORCPT parameters MUST NOT appear more than once in any - RCPT command. If more than one of either of these parameters appears - in a RCPT command, the ESMTP server SHOULD respond with "501 syntax - error in parameters or arguments". - -6. Conformance requirements - - The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer - Agents (MTAs) when accepting, relaying, or gatewaying mail, as well - as User Agents (UAs) when submitting mail to the mail transport - - - -Moore Standards Track [Page 8] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - system. The DSN extension to SMTP may be used to allow UAs to convey - the sender's requests as to when DSNs should be issued. A UA which - claims to conform to this specification must meet certain - requirements as described below. - - Typically, a message transfer agent (MTA) which supports SMTP will - assume, at different times, both the role of a SMTP client and an - SMTP server, and may also provide local delivery, gatewaying to - foreign environments, forwarding, and mailing list expansion. An MTA - which, when acting as an SMTP server, issues the DSN keyword in - response to the EHLO command, MUST obey the rules below for a - "conforming SMTP client" when acting as a client, and a "conforming - SMTP server" when acting as a server. The term "conforming MTA" - refers to an MTA which conforms to this specification, independent of - its role of client or server. - -6.1 SMTP protocol interactions - - The following rules apply to SMTP transactions in which any of the - ENVID, NOTIFY, RET, or ORCPT keywords are used: - -(a) If an SMTP client issues a MAIL command containing a valid ENVID - parameter and associated esmtp-value and/or a valid RET parameter - and associated esmtp-value, a conforming SMTP server MUST return - the same reply-code as it would to the same MAIL command without - the ENVID and/or RET parameters. A conforming SMTP server MUST - NOT refuse a MAIL command based on the absence or presence of - valid ENVID or RET parameters, or on their associated - esmtp-values. - - However, if the associated esmtp-value is not valid (i.e. contains - illegal characters), or if there is more than one ENVID or RET - parameter in a particular MAIL command, the server MUST issue the - reply-code 501 with an appropriate message (e.g. "syntax error in - parameter"). - -(b) If an SMTP client issues a RCPT command containing any valid - NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST - return the same response as it would to the same RCPT command - without those NOTIFY and/or ORCPT parameters. A conforming SMTP - server MUST NOT refuse a RCPT command based on the presence or - absence of any of these parameters. - - However, if any of the associated esmtp-values are not valid, or - if there is more than one of any of these parameters in a - particular RCPT command, the server SHOULD issue the response "501 - syntax error in parameter". - - - - -Moore Standards Track [Page 9] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -6.2 Handling of messages received via SMTP - - This section describes how a conforming MTA should handle any - messages received via SMTP. - - NOTE: A DSN MUST NOT be returned to the sender for any message for - which the return address from the SMTP MAIL command was NULL ("<>"), - even if the sender's address is available from other sources (e.g. - the message header). However, the MTA which would otherwise issue a - DSN SHOULD inform the local postmaster of delivery failures through - some appropriate mechanism that will not itself result in the - generation of DSNs. - - DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to - be sent with a NULL return address ("reverse-path"). This creates an - interesting situation when a message arrives with one or more - nonfunctional recipient addresses in addition to a nonfunctional - return address. When delivery to one of the recipient addresses - fails, the MTA will attempt to send a nondelivery notification to the - return address, setting the return address on the notification to - NULL. When the delivery of this notification fails, the MTA - attempting delivery of that notification sees a NULL return address. - If that MTA were not to inform anyone of the situation, the original - message would be silently lost. Furthermore, a nonfunctional return - address is often indicative of a configuration problem in the - sender's MTA. Reporting the condition to the local postmaster may - help to speed correction of such errors. - -6.2.1 Relay of messages to other conforming SMTP servers - - The following rules govern the behavior of a conforming MTA, when - relaying a message which was received via the SMTP protocol, to an - SMTP server that supports the Delivery Status Notification service - extension: - -(a) Any ENVID parameter included in the MAIL command when a message was - received, MUST also appear on the MAIL command with which the - message is relayed, with the same associated esmtp-value. If no - ENVID parameter was included in the MAIL command when the message - was received, the ENVID parameter MUST NOT be supplied when the - message is relayed. - -(b) Any RET parameter included in the MAIL command when a message was - received, MUST also appear on the MAIL command with which the - message is relayed, with the same associated esmtp-value. If no RET - parameter was included in the MAIL command when the message was - received, the RET parameter MUST NOT supplied when the message is - relayed. - - - -Moore Standards Track [Page 10] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -(c) If the NOTIFY parameter was supplied for a recipient when the - message was received, the RCPT command issued when the message is - relayed MUST also contain the NOTIFY parameter along with its - associated esmtp-value. If the NOTIFY parameter was not supplied - for a recipient when the message was received, the NOTIFY parameter - MUST NOT be supplied for that recipient when the message is relayed. - -(d) If any ORCPT parameter was present in the RCPT command for a - recipient when the message was received, an ORCPT parameter with the - identical original-recipient-address MUST appear in the RCPT command - issued for that recipient when relaying the message. (For example, - the MTA therefore MUST NOT change the case of any alphabetic - characters in an ORCPT parameter.) - - If no ORCPT parameter was present in the RCPT command when the - message was received, an ORCPT parameter MAY be added to the RCPT - command when the message is relayed. If an ORCPT parameter is added - by the relaying MTA, it MUST contain the recipient address from the - RCPT command used when the message was received by that MTA. - -6.2.2 Relay of messages to non-conforming SMTP servers - - The following rules govern the behavior of a conforming MTA (in the - role of client), when relaying a message which was received via the - SMTP protocol, to an SMTP server that does not support the Delivery - Status Notification service extension: - -(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when - relaying the message. - -(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp- - value containing the keyword SUCCESS, and the SMTP server returns a - success (2xx) reply-code in response to the RCPT command, the client - MUST issue a "relayed" DSN for that recipient. - -(c) If the NOTIFY parameter was supplied for a recipient with an esmtp- - value containing the keyword FAILURE, and the SMTP server returns a - permanent failure (5xx) reply-code in response to the RCPT command, - the client MUST issue a "failed" DSN for that recipient. - -(d) If the NOTIFY parameter was supplied for a recipient with an esmtp- - value of NEVER, the client MUST NOT issue a DSN for that recipient, - regardless of the reply-code returned by the SMTP server. However, - if the server returned a failure (5xx) reply-code, the client MAY - inform the local postmaster of the delivery failure via an - appropriate mechanism that will not itself result in the generation - of DSNs. - - - - -Moore Standards Track [Page 11] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - When attempting to relay a message to an SMTP server that does not - support this extension, and if NOTIFY=NEVER was specified for some - recipients of that message, a conforming SMTP client MAY relay the - message for those recipients in a separate SMTP transaction, using - an empty reverse-path in the MAIL command. This will prevent DSNs - from being issued for those recipients by MTAs that conform to [1]. - -(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP - server returns a success (2xx) reply-code in response to a RCPT - command, the client MUST NOT issue any DSN for that recipient. - -(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP - server returns a permanent failure (5xx) reply-code in response to a - RCPT command, the client MUST issue a "failed" DSN for that - recipient. - -6.2.3 Local delivery of messages - - The following rules govern the behavior of a conforming MTA upon - successful delivery of a message that was received via the SMTP - protocol, to a local recipient's mailbox: - - "Delivery" means that the message has been placed in the recipient's - mailbox. For messages which are transmitted to a mailbox for later - retrieval via IMAP [6], POP [7] or a similar message access protocol, - "delivery" occurs when the message is made available to the IMAP - (POP, etc.) service, rather than when the message is retrieved by the - recipient's user agent. - - Similarly, for a recipient address which corresponds to a mailing - list exploder, "delivery" occurs when the message is made available - to that list exploder, even though the list exploder might refuse to - deliver that message to the list recipients. - -(a) If the NOTIFY parameter was supplied for that recipient, with an - esmtp-value containing the SUCCESS keyword, the MTA MUST issue a - "delivered" DSN for that recipient. - -(b) If the NOTIFY parameter was supplied for that recipient which did - not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for - that recipient. - -(c) If the NOTIFY parameter was not supplied for that recipient, the MTA - MUST NOT issue a DSN. - - - - - - - -Moore Standards Track [Page 12] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -6.2.4 Gatewaying a message into a foreign environment - - The following rules govern the behavior of a conforming MTA, when - gatewaying a message that was received via the SMTP protocol, into a - foreign (non-SMTP) environment: - -(a) If the the foreign environment is capable of issuing appropriate - notifications under the conditions requested by the NOTIFY - parameter, and the conforming MTA can ensure that any notification - thus issued will be translated into a DSN and delivered to the - original sender, then the MTA SHOULD gateway the message into the - foreign environment, requesting notification under the desired - conditions, without itself issuing a DSN. - -(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the - destination environment cannot return an appropriate notification on - successful delivery, the MTA SHOULD issue a "relayed" DSN for that - recipient. - -(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a - DSN MUST NOT be issued. If possible, the MTA SHOULD direct the - destination environment to not issue delivery notifications for that - recipient. - -(d) If the NOTIFY parameter was not supplied for a particular recipient, - a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD - attempt to ensure that appropriate notification will be provided by - the foreign mail environment if eventual delivery failure occurs, - and that no notification will be issued on successful delivery. - -(e) When gatewaying a message into a foreign environment, the return-of- - content conditions specified by any RET parameter are nonbinding; - however, the MTA SHOULD attempt to honor the request using whatever - mechanisms exist in the foreign environment. - -6.2.5 Delays in delivery - - If a conforming MTA receives a message via the SMTP protocol, and is - unable to deliver or relay the message to one or more recipients for - an extended length of time (to be determined by the MTA), it MAY - issue a "delayed" DSN for those recipients, subject to the following - conditions: - -(a) If the NOTIFY parameter was supplied for a recipient and its value - included the DELAY keyword, a "delayed" DSN MAY be issued. - -(b) If the NOTIFY parameter was not supplied for a recipient, a - "delayed" DSN MAY be issued. - - - -Moore Standards Track [Page 13] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -(c) If the NOTIFY parameter was supplied which did not contain the DELAY - keyword, a "delayed" DSN MUST NOT be issued. - - NOTE: Although delay notifications are common in present-day - electronic mail, a conforming MTA is never required to issue - "delayed" DSNs. The DELAY keyword of the NOTIFY parameter is - provided to allow the SMTP client to specifically request (by - omitting the DELAY parameter) that "delayed" DSNs NOT be issued. - -6.2.6 Failure of a conforming MTA to deliver a message - - The following rules govern the behavior of a conforming MTA which - received a message via the SMTP protocol, and is unable to deliver a - message to a recipient specified in the SMTP transaction: - -(a) If a NOTIFY parameter was supplied for the recipient with an esmtp- - keyword containing the value FAILURE, a "failed" DSN MUST be issued - by the MTA. - -(b) If a NOTIFY parameter was supplied for the recipient which did not - contain the value FAILURE, a DSN MUST NOT be issued for that - recipient. However, the MTA MAY inform the local postmaster of the - delivery failure via some appropriate mechanism which does not - itself result in the generation of DSNs. - -(c) If no NOTIFY parameter was supplied for the recipient, a "failed" - DSN MUST be issued. - - NOTE: Some MTAs are known to forward undeliverable messages to the - local postmaster or "dead letter" mailbox. This is still considered - delivery failure, and does not diminish the requirement to issue a - "failed" DSN under the conditions defined elsewhere in this memo. If - a DSN is issued for such a recipient, the Action value MUST be - "failed". - -6.2.7 Forwarding, aliases, and mailing lists - - Delivery of a message to a local email address usually causes the - message to be stored in the recipient's mailbox. However, MTAs - commonly provide a facility where a local email address can be - designated as an "alias" or "mailing list"; delivery to that address - then causes the message to be forwarded to each of the (local or - remote) recipient addresses associated with the alias or list. It is - also common to allow a user to optionally "forward" her mail to one - or more alternate addresses. If this feature is enabled, her mail is - redistributed to those addresses instead of being deposited in her - mailbox. - - - - -Moore Standards Track [Page 14] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - Following the example of [9] (section 5.3.6), this document defines - the difference between an "alias" and "mailing list" as follows: When - forwarding a message to the addresses associated with an "alias", the - envelope return address (e.g. SMTP MAIL FROM) remains intact. - However, when forwarding a message to the addresses associated with a - "mailing list", the envelope return address is changed to that of the - administrator of the mailing list. This causes DSNs and other - nondelivery reports resulting from delivery to the list members to be - sent to the list administrator rather than the sender of the original - message. - - The DSN processing for aliases and mailing lists is as follows: - -6.2.7.1 mailing lists - - When a message is delivered to a list submission address (i.e. placed - in the list's mailbox for incoming mail, or accepted by the process - that redistributes the message to the list subscribers), this is - considered final delivery for the original message. If the NOTIFY - parameter for the list submission address contained the SUCCESS - keyword, a "delivered" DSN MUST be returned to the sender of the - original message. - - NOTE: Some mailing lists are able to reject message submissions, - based on the content of the message, the sender's address, or some - other criteria. While the interface between such a mailing list and - its MTA is not well-defined, it is important that DSNs NOT be issued - by both the MTA (to report successful delivery to the list), and the - list (to report message rejection using a "failure" DSN.) - - However, even if a "delivered" DSN was issued by the MTA, a mailing - list which rejects a message submission MAY notify the sender that - the message was rejected using an ordinary message instead of a DSN. - - Whenever a message is redistributed to an mailing list, - -(a) The envelope return address is rewritten to point to the list - maintainer. This address MAY be that of a process that recognizes - DSNs and processes them automatically, but it MUST forward - unrecognized messages to the human responsible for the list. - -(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the - redistributed message MUST NOT be derived from those of the original - message. - -(c) The NOTIFY and RET parameters MAY be specified by the local - postmaster or the list administrator. If ORCPT parameters are - supplied during redistribution to the list subscribers, they SHOULD - - - -Moore Standards Track [Page 15] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - contain the addresses of the list subscribers in the format used by - the mailing list. - -6.2.7.2 single-recipient aliases - - Under normal circumstances, when a message arrives for an "alias" - which has a single forwarding address, a DSN SHOULD NOT be issued. - Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with - the message as it is redistributed to the forwarding address. - -6.2.7.3 multiple-recipient aliases - - An "alias" with multiple recipient addresses may be handled in any of - the following ways: - -(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when - relaying the message to any of the forwarding addresses. If the - NOTIFY parameter for the alias contained the SUCCESS keyword, the - MTA issues a "relayed" DSN. (In effect, the MTA treats the message - as if it were being relayed into an environment that does not - support DSNs.) - -(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent - requests if the message is gatewayed) are propagated to EXACTLY one - of the forwarding addresses. No DSN is issued. (This is - appropriate when aliasing is used to forward a message to a - "vacation" auto-responder program in addition to the local mailbox.) - -(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding - addresses associated with that alias. The NOTIFY parameter is - propagated to the forwarding addresses, except that it any SUCCESS - keyword is removed. If the original NOTIFY parameter for the alias - contained the SUCCESS keyword, an "expanded" DSN is issued for the - alias. If the NOTIFY parameter for the alias did not contain the - SUCCESS keyword, no DSN is issued for the alias. - -6.2.7.4 confidential forwarding addresses - - If it is desired to maintain the confidentiality of a recipient's - forwarding address, the forwarding may be treated as if it were a - mailing list. A DSN will be issued, if appropriate, upon "delivery" - to the recipient address specified by the sender. When the message - is forwarded it will have a new envelope return address. Any DSNs - which result from delivery failure of the forwarded message will not - be returned to the original sender of the message and thus not expose - the recipient's forwarding address. - - - - - -Moore Standards Track [Page 16] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -6.2.8 DSNs describing delivery to multiple recipients - - A single DSN may describe attempts to deliver a message to multiple - recipients of that message. If a DSN is issued for some recipients - in an SMTP transaction and not for others according to the rules - above, the DSN SHOULD NOT contain information for recipients for whom - DSNs would not otherwise have been issued. - -6.3 Handling of messages from other sources - - For messages which originated from "local" users (whatever that - means), the specifications under which DSNs should be generated can - be communicated to the MTA via any protocol agreed on between the - sender's mail composer (user agent) and the MTA. The local MTA can - then either relay the message, or issue appropriate delivery status - notifications. However, if such requests are transmitted within the - message itself (for example in the message headers), the requests - MUST be removed from the message before it is transmitted via SMTP. - - For messages gatewayed from non-SMTP sources and further relayed by - SMTP, the gateway SHOULD, using the SMTP extensions described here, - attempt to provide the delivery reporting conditions expected by the - source mail environment. If appropriate, any DSNs returned to the - source environment SHOULD be translated into the format expected in - that environment. - -6.4 Implementation limits - - A conforming MTA MUST accept ESMTP parameters of at least the - following sizes: - - (a) ENVID parameter: 100 characters. - - (b) NOTIFY parameter: 28 characters. - - (c) ORCPT parameter: 500 characters. - - (d) RET parameter: 8 characters. - - The maximum sizes for the ENVID and ORCPT parameters are intended to - be adequate for the transmission of "foreign" envelope identifier and - original recipient addresses. However, user agents which use SMTP as - a message submission protocol SHOULD NOT generate ENVID parameters - which are longer than 38 characters in length. - - A conforming MTA MUST be able to accept SMTP command-lines which are - at least 1036 characters long (530 characters for the ORCPT and - NOTIFY parameters of the RCPT command, in addition to the 512 - - - -Moore Standards Track [Page 17] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - characters required by [1]). If other SMTP extensions are supported - by the MTA, the MTA MUST be able to accept a command-line large - enough for each SMTP command and any combination of ESMTP parameters - which may be used with that command. - -7. Format of delivery notifications - - The format of delivery status notifications is defined in [5], which - uses the framework defined in [8]. Delivery status notifications are - to be returned to the sender of the original message as outlined - below. - -7.1 SMTP Envelope to be used with delivery status notifications - - The DSN sender address (in the SMTP MAIL command) MUST be a null - reverse-path ("<>"), as required by section 5.3.3 of [9]. The DSN - recipient address (in the RCPT command) is copied from the MAIL - command which accompanied the message for which the DSN is being - issued. When transmitting a DSN via SMTP, the RET parameter MUST NOT - be used. The NOTIFY parameter MAY be used, but its value MUST be - NEVER. The ENVID parameter (with a newly generated envelope-id) - and/or ORCPT parameter MAY be used. - -7.2 Contents of the DSN - - A DSN is transmitted as a MIME message with a top-level content-type - of multipart/report (as defined in [5]). - - The multipart/report content-type may be used for any of several - kinds of reports generated by the mail system. When multipart/report - is used to convey a DSN, the report-type parameter of the - multipart/report content-type is "delivery-status". - - As described in [8], the first component of a multipart/report - content-type is a human readable explanation of the report. For a - DSN, the second component of the multipart/report is of content-type - message/delivery-status (defined in [5]). The third component of the - multipart/report consists of the original message or some portion - thereof. When the value of the RET parameter is FULL, the full - message SHOULD be returned for any DSN which conveys notification of - delivery failure. (However, if the length of the message is greater - than some implementation-specified length, the MTA MAY return only - the headers even if the RET parameter specified FULL.) If a DSN - contains no notifications of delivery failure, the MTA SHOULD return - only the headers. - - The third component must have an appropriate content-type label. - Issues concerning selection of the content-type are discussed in [8]. - - - -Moore Standards Track [Page 18] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -7.3 Message/delivery-status fields - - The message/delivery-status content-type defines a number of fields, - with general specifications for their contents. The following - requirements for any DSNs generated in response to a message received - by the SMTP protocol by a conforming SMTP server, are in addition to - the requirements defined in [5] for the message/delivery-status type. - - When generating a DSN for a message which was received via the SMTP - protocol, a conforming MTA will generate the following fields of the - message/delivery-status body part: - -(a) if an ENVID parameter was present on the MAIL command, an Original- - Envelope-ID field MUST be supplied, and the value associated with - the ENVID parameter must appear in that field. If the message was - received via SMTP with no ENVID parameter, the Original-Envelope-ID - field MUST NOT be supplied. - - Since the ENVID parameter is encoded as xtext, but the Original- - Envelope-ID header is NOT encoded as xtext, the MTA must decode the - xtext encoding when copying the ENVID value to the Original- - Envelope-ID field. - -(b) The Reporting-MTA field MUST be supplied. If Reporting MTA can - determine its fully-qualified Internet domain name, the MTA-name- - type subfield MUST be "dns", and the field MUST contain the fully- - qualified domain name of the Reporting MTA. If the fully-qualified - Internet domain name of the Reporting MTA is not known (for example, - for an SMTP server which is not directly connected to the Internet), - the Reporting-MTA field may contain any string identifying the MTA, - however, in this case the MTA-name-type subfield MUST NOT be "dns". - A MTA-name-type subfield value of "x-local-hostname" is suggested. - -(c) Other per-message fields as defined in [5] MAY be supplied as - appropriate. - -(d) If the ORCPT parameter was provided for this recipient, the - Original-Recipient field MUST be supplied, with its value taken from - the ORCPT parameter. If no ORCPT parameter was provided for this - recipient, the Original-Recipient field MUST NOT appear. - -(e) The Final-Recipient field MUST be supplied. It MUST contain the - recipient address from the message envelope. If the message was - received via SMTP, the address-type will be "rfc822". - -(f) The Action field MUST be supplied. - - - - - -Moore Standards Track [Page 19] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -(g) The Status field MUST be supplied, using a status-code from [10]. - If there is no specific code which suitably describes a delivery - failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent - failure) MUST be used. - -(h) For DSNs resulting from attempts to relay a message to one or more - recipients via SMTP, the Remote-MTA field MUST be supplied for each - of those recipients. The mta-name-type subfields of those Remote- - MTA fields will be "dns". - -(i) For DSNs resulting from attempts to relay a message to one or more - recipients via SMTP, the Diagnostic-Code MUST be supplied for each - of those recipients. The diagnostic-type subfield will be "smtp". - See section 9.2(a) of this document for a description of the "smtp" - diagnostic-code. - -(j) For DSNs resulting from attempts to relay a message to one or more - recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be - supplied for each recipient, which contains the address of that - recpient which was presented to the remote SMTP server. - -(k) Other per-recipient fields defined in [5] MAY appear, as - appropriate. - -8. Acknowledgments - - The author wishes to thank Eric Allman, Harald Alvestrand, Jim - Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned - Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios - Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall - Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for - improvement of this document. - - - - - - - - - - - - - - - - - - - -Moore Standards Track [Page 20] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -9. Appendix - Type-Name Definitions - - The following type names are defined for use in DSN fields generated - by conforming SMTP-based MTAs: - -9.1 "rfc822" address-type - - The "rfc822" address-type is to be used when reporting Internet - electronic mail address in the Original-Recipient and Final-Recipient - DSN fields. - -(a) address-type name: rfc822 - -(b) syntax for mailbox addresses - - RFC822 mailbox addresses are generally expected to be of the form - - [route] addr-spec - - where "route" and "addr-spec" are defined in [2], and the "domain" - portions of both "route" and "addr-spec" are fully-qualified domain - names that are registered in the DNS. However, an MTA MUST NOT - modify an address obtained from the message envelope to force it to - conform to syntax rules. - -(c) If addresses of this type are not composed entirely of graphic -characters from the US-ASCII repertoire, a specification for how they -are to be encoded as graphic US-ASCII characters in a DSN Original- -Recipient or Final-Recipient DSN field. - - RFC822 addresses consist entirely of graphic characters from the US- - ASCII repertoire, so no translation is necessary. - -9.2 "smtp" diagnostic-type - - The "smtp" diagnostic-type is to be used when reporting SMTP reply- - codes in Diagnostic-Code DSN fields. - -(a) diagnostic-type name: SMTP - -(b) A description of the syntax to be used for expressing diagnostic -codes of this type as graphic characters from the US-ASCII repertoire. - - An SMTP diagnostic-code is of the form - - *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text - - - - - -Moore Standards Track [Page 21] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - - For a single-line SMTP reply to an SMTP command, the diagnostic-code - SHOULD be an exact transcription of the reply. For multi-line SMTP - replies, it is necessary to insert a SPACE before each line after - the first. For example, an SMTP reply of: - - 550-mailbox unavailable - 550 user has moved with no forwarding address - - could appear as follows in a Diagnostic-Code DSN field: - - Diagnostic-Code: smtp ; 550-mailbox unavailable - 550 user has moved with no forwarding address - -(c) A list of valid diagnostic codes of this type and the meaning of -each code. - - SMTP reply-codes are currently defined in [1], [4], and [9]. - Additional codes may be defined by other RFCs. - -9.3 "dns" MTA-name-type - - The "dns" MTA-name-type should be used in the Reporting-MTA field. - An MTA-name of type "dns" is a fully-qualified domain name. The name - must be registered in the DNS, and the address Postmaster@{mta-name} - must be valid. - -(a) MTA-name-type name: dns - -(b) A description of the syntax of MTA names of this type, using BNF, -regular expressions, ASN.1, or other non-ambiguous language. - - MTA names of type "dns" SHOULD be valid Internet domain names. If - such domain names are not available, a domain-literal containing the - internet protocol address is acceptable. Such domain names - generally conform to the following syntax: - - domain = real-domain / domain-literal - - real-domain = sub-domain *("." sub-domain) - - sub-domain = atom - - domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]" - - where "atom" and "DIGIT" are defined in [2]. - - - - - - -Moore Standards Track [Page 22] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -(c) If MTA names of this type do not consist entirely of graphic -characters from the US-ASCII repertoire, a specification for how an MTA -name of this type should be expressed as a sequence of graphic US-ASCII -characters. - - MTA names of type "dns" consist entirely of graphic US-ASCII - characters, so no translation is needed. - -10. Appendix - Example - - This example traces the flow of a single message addressed to - multiple recipients. The message is sent by Alice@Pure-Heart.ORG to - Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, - Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a - variety of per-recipient options. The message is successfully - delivered to Bob, Dana (via a gateway), Eric, and Fred. Delivery - fails for Carol and George. - - NOTE: Formatting rules for RFCs require that no line be longer than - 72 characters. Therefore, in the following examples, some SMTP - commands longer than 72 characters are printed on two lines, with the - first line ending in "\". In an actual SMTP transaction, such a - command would be sent as a single line (i.e. with no embedded CRLFs), - and without the "\" character that appears in these examples. - -10.1 Submission - - Alice's user agent sends the message to the SMTP server at Pure- - Heart.ORG. Note that while this example uses SMTP as a mail - submission protocol, other protocols could also be used. - -<<< 220 Pure-Heart.ORG SMTP server here ->>> EHLO Pure-Heart.ORG -<<< 250-Pure-Heart.ORG -<<< 250-DSN -<<< 250-EXPN -<<< 250 SIZE ->>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 -<<< 250 <Alice@Pure-Heart.ORG> sender ok ->>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \ - ORCPT=rfc822;Bob@Big-Bucks.COM -<<< 250 <Bob@Big-Bucks.COM> recipient ok ->>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \ - ORCPT=rfc822;Carol@Ivory.EDU -<<< 250 <Carol@Ivory.EDU> recipient ok ->>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \ - ORCPT=rfc822;Dana@Ivory.EDU -<<< 250 <Dana@Ivory.EDU> recipient ok - - - -Moore Standards Track [Page 23] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - ->>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \ - ORCPT=rfc822;Eric@Bombs.AF.MIL -<<< 250 <Eric@Bombs.AF.MIL> recipient ok ->>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER -<<< 250 <Fred@Bombs.AF.MIL> recipient ok ->>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \ - ORCPT=rfc822;George@Tax-ME.GOV -<<< 250 <George@Tax-ME.GOV> recipient ok ->>> DATA -<<< 354 okay, send message ->>> (message goes here) ->>> . -<<< 250 message accepted ->>> QUIT -<<< 221 goodbye - -10.2 Relay to Big-Bucks.COM - - The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM. - (For the purpose of this example, mail.Big-Bucks.COM is the primary - mail exchanger for Big-Bucks.COM). - -<<< 220 mail.Big-Bucks.COM says hello ->>> EHLO Pure-Heart.ORG -<<< 250-mail.Big-Bucks.COM -<<< 250 DSN ->>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 -<<< 250 sender okay ->>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \ - ORCPT=rfc822;Bob@Big-Bucks.COM -<<< 250 recipient okay ->>> DATA -<<< 354 send message ->>> (message goes here) ->>> . -<<< 250 message received ->>> QUIT -<<< 221 bcnu - -10.3 Relay to Ivory.EDU - - The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as - it happens) is a gateway to a LAN-based mail system that accepts SMTP - mail and supports the DSN extension. - -<<< 220 Ivory.EDU gateway to FooMail(tm) here ->>> EHLO Pure-Heart.ORG -<<< 250-Ivory.EDU - - - -Moore Standards Track [Page 24] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -<<< 250 DSN ->>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 -<<< 250 ok ->>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \ - ORCPT=rfc822;Carol@Ivory.EDU -<<< 550 error - no such recipient ->>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \ - ORCPT=rfc822;Dana@Ivory.EDU -<<< 250 recipient ok ->>> DATA -<<< 354 send message, end with '.' ->>> (message goes here) ->>> . -<<< 250 message received ->>> QUIT -<<< 221 bye - - Note that since the Ivory.EDU refused to accept mail for - Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the - sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN. - -10.4 Relay to Bombs.AF.MIL - - The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which - does not support the SMTP extension. Because the sender specified - NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure- - Heart.ORG chooses to send the message for that recipient in a - separate transaction with a reverse-path of <>. - -<<< 220-Bombs.AF.MIL reporting for duty. -<<< 220 Electronic mail is to be used for official business only. ->>> EHLO Pure-Heart.ORG -<<< 502 command not implemented ->>> RSET -<<< 250 reset ->>> HELO Pure-Heart.ORG -<<< 250 Bombs.AF.MIL ->>> MAIL FROM:<Alice@Pure-Heart.ORG> -<<< 250 ok ->>> RCPT TO:<Eric@Bombs.AF.MIL> -<<< 250 ok ->>> DATA -<<< 354 send message ->>> (message goes here) ->>> . -<<< 250 message accepted ->>> MAIL FROM:<> -<<< 250 ok - - - -Moore Standards Track [Page 25] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - ->>> RCPT TO:<Fred@Bombs.AF.MIL> -<<< 250 ok ->>> DATA -<<< 354 send message ->>> (message goes here) ->>> . -<<< 250 message accepted ->>> QUIT -<<< 221 Bombs.AF.MIL closing connection - -10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV - - The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV. (this - step is not shown). MTA Tax-ME.GOV then forwards the message to - Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Pure-Heart.ORG - support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all - retain their original values. - -<<< 220 BoonDoggle.GOV says hello ->>> EHLO Pure-Heart.ORG -<<< 250-mail.Big-Bucks.COM -<<< 250 DSN ->>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159 -<<< 250 sender okay ->>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \ - ORCPT=rfc822;George@Tax-ME.GOV -<<< 250 recipient okay ->>> DATA -<<< 354 send message ->>> (message goes here) ->>> . -<<< 250 message received ->>> QUIT -<<< 221 bcnu - - - - - - - - - - - - - - - - - -Moore Standards Track [Page 26] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -10.6 "Delivered" DSN for Bob@Big-Bucks.COM - - MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big- - Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big- - Bucks.COM issues the following DSN, and sends it to Alice@Pure- - Heart.ORG. - -To: Alice@Pure-Heart.ORG -From: postmaster@mail.Big-Bucks.COM -Subject: Delivery Notification (success) for Bob@Big-Bucks.COM -Content-Type: multipart/report; report-type=delivery-status; - boundary=abcde -MIME-Version: 1.0 - ---abcde -Content-type: text/plain; charset=us-ascii - -Your message (id QQ314159) was successfully delivered to -Bob@Big-Bucks.COM. - ---abcde -Content-type: message/delivery-status - -Reporting-MTA: dns; mail.Big-Bucks.COM -Original-Envelope-ID: QQ314159 - -Original-Recipient: rfc822;Bob@Big-Bucks.COM -Final-Recipient: rfc822;Bob@Big-Bucks.COM -Action: delivered -Status: 2.0.0 - ---abcde -Content-type: message/rfc822 - -(headers of returned message go here) - ---abcde-- - - - - - - - - - - - - - - -Moore Standards Track [Page 27] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -10.7 Failed DSN for Carol@Ivory.EDU - - Because delivery to Carol failed and the sender specified - NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP - client to which the failure was reported via SMTP) issues the - following DSN. - -To: Alice@Pure-Heart.ORG -From: postmaster@Pure-Heart.ORG -Subject: Delivery Notification (failure) for Carol@Ivory.EDU -Content-Type: multipart/report; report-type=delivery-status; - boundary=bcdef -MIME-Version: 1.0 - ---bcdef -Content-type: text/plain; charset=us-ascii - -Your message (id QQ314159) could not be delivered to -Carol@Ivory.EDU. - -A transcript of the session follows: - -(while talking to Ivory.EDU) ->>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE -<<< 550 error - no such recipient - ---bcdef -Content-type: message/delivery-status - -Reporting-MTA: dns; Pure-Heart.ORG -Original-Envelope-ID: QQ314159 - -Original-Recipient: rfc822;Carol@Ivory.EDU -Final-Recipient: rfc822;Carol@Ivory.EDU -SMTP-Remote-Recipient: Carol@Ivory.EDU -Diagnostic-Code: smtp; 550 error - no such recipient -Action: failed -Status: 5.0.0 - ---bcdef -Content-type: message/rfc822 - -(headers of returned message go here) - ---bcdef-- - - - - - - -Moore Standards Track [Page 28] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -10.8 Relayed DSN For Dana@Ivory.EDU - - Although the mail gateway Ivory.EDU supports the DSN SMTP extension, - the LAN mail system attached to its other side does not generate - positive delivery confirmations. So Ivory.EDU issues a "relayed" - DSN: - -To: Alice@Pure-Heart.ORG -From: postmaster@Ivory.EDU -Subject: mail relayed for Dana@Ivory.EDU -Content-Type: multipart/report; report-type=delivery-status; - boundary=cdefg -MIME-Version: 1.0 - ---cdefg -Content-type: text/plain; charset=us-ascii - -Your message (addressed to Dana@Ivory.EDU) was successfully -relayed to: - -ymail!Dana - -by the FooMail gateway at Ivory.EDU. - -Unfortunately, the remote mail system does not support -confirmation of actual delivery. Unless delivery to ymail!Dana -fails, this will be the only delivery status notification sent. - ---cdefg -Content-type: message/delivery-status - -Reporting-MTA: dns; Ivory.EDU -Original-Envelope-ID: QQ314159 - -Original-Recipient: rfc822;Dana@Ivory.EDU -Final-Recipient: rfc822;Dana@Ivory.EDU -Action: relayed -Status: 2.0.0 - ---cdefg -Content-type: message/rfc822 - -(headers of returned message go here) - ---cdefg-- - - - - - - -Moore Standards Track [Page 29] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -10.9 Failure notification for Sam@Boondoggle.GOV - - The message originally addressed to George@Tax-ME.GOV was forwarded - to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to - deliver the message due to a lack of disk space in Sam's mailbox. - After trying for several days, Boondoggle.GOV returned the following - DSN: - -To: Alice@BigHeart.ORG -From: Postmaster@Boondoggle.GOV -Subject: Delivery failure for Sam@Boondoggle.GOV -Content-Type: multipart/report; report-type=delivery-status; - boundary=defgh -MIME-Version: 1.0 - ---defgh -Your message, originally addressed to George@Tax-ME.GOV, and forwarded -from there to Sam@Boondoggle.GOV could not be delivered, for the -following reason: - -write error to mailbox, disk quota exceeded - ---defgh -Content-type: message/delivery-status - -Reporting-MTA: Boondoggle.GOV -Original-Envelope-ID: QQ314159 - -Original-Recipient: rfc822;George@Tax-ME.GOV -Final-Recipient: rfc822;Sam@Boondoggle.GOV -Action: failed -Status: 4.2.2 (disk quota exceeded) - ---defgh -Content-type: message/rfc822 - -(headers of returned message go here) - ---defgh-- - - - - - - - - - - - - -Moore Standards Track [Page 30] - -RFC 1891 SMTP Delivery Status Notifications January 1996 - - -11. References - - [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - - [2] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - - [3] Westine, A., and J. Postel, "Problems with the Maintenance of - Large Mailing Lists.", RFC 1211, USC/Information Sciences - Institute, March 1991. - - [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, - "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach - Consulting, Inc., Network Management Associates, Inc., Silicon - Graphics, Inc., July 1994. - - [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for - Delivery Status Notifications", RFC 1894, University of Tennessee, - Octel Network Services, January 1996. - - [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC - 1730, University of Washington, 20 December 1994. - - [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC - 1725, Carnegie Mellon, Dover Beach Consulting, November 1994. - - [8] Vaudreuil, G., "The Multipart/Report Content Type for the - Reporting of Mail System Administrative Messages", RFC 1892, Octel - Network Services, January 1996. - - [9] Braden, R., Editor, "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, IETF, October 1989. - - [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, - Octel Network Services, January 1996. - -12. Author's Address - - Keith Moore - University of Tennessee - 107 Ayres Hall - Knoxville, TN 37996-1301 - USA - - EMail: moore@cs.utk.edu - - - - - -Moore Standards Track [Page 31] - diff --git a/RFC/rfc1892.txt b/RFC/rfc1892.txt deleted file mode 100644 index c4bdbd5f..00000000 --- a/RFC/rfc1892.txt +++ /dev/null @@ -1,227 +0,0 @@ - - - - - - -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 deleted file mode 100644 index 9ca4efb5..00000000 --- a/RFC/rfc1893.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -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 deleted file mode 100644 index f1fc90d4..00000000 --- a/RFC/rfc1894.txt +++ /dev/null @@ -1,2187 +0,0 @@ - - - - - - -Network Working Group K. Moore -Request for Comments: 1894 University of Tennessee -Category: Standards Track G. Vaudreuil - Octel Network Services - January 1996 - - - An Extensible Message Format for Delivery Status Notifications - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This memo defines a MIME content-type that may be used by a message - transfer agent (MTA) or electronic mail gateway to report the result - of an attempt to deliver a message to one or more recipients. This - content-type is intended as a machine-processable replacement for the - various types of delivery status notifications currently used in - Internet electronic mail. - - Because many messages are sent between the Internet and other - messaging systems (such as X.400 or the so-called "LAN-based" - systems), the DSN protocol is designed to be useful in a multi- - protocol messaging environment. To this end, the protocol described - in this memo provides for the carriage of "foreign" addresses and - error codes, in addition to those normally used in Internet mail. - Additional attributes may also be defined to support "tunneling" of - foreign notifications through Internet mail. - - Any questions, comments, and reports of defects or ambiguities in - this specification may be sent to the mailing list for the NOTARY - working group of the IETF, using the address - <notifications@cs.utk.edu>. Requests to subscribe to the mailing - list should be addressed to <notifications-request@cs.utk.edu>. - Implementors of this specification are encouraged to subscribe to the - mailing list, so that they will quickly be informed of any problems - which might hinder interoperability. - - NOTE: This document is a Proposed Standard. If and when this - protocol is submitted for Draft Standard status, any normative text - (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in - this document will be re-evaluated in light of implementation - - - -Moore & Vaudreuil Standards Track [Page 1] - -RFC 1894 Delivery Status Notifications January 1996 - - - experience, and are thus subject to change. - -1. Introduction - - This memo defines a MIME [1] content-type for delivery status - notifications (DSNs). A DSN can be used to notify the sender of a - message of any of several conditions: failed delivery, delayed - delivery, successful delivery, or the gatewaying of a message into an - environment that may not support DSNs. The "message/delivery-status" - content-type defined herein is intended for use within the framework - of the "multipart/report" content type defined in [2]. - - This memo defines only the format of the notifications. An extension - to the Simple Message Transfer Protocol (SMTP) [3] to fully support - such notifications is the subject of a separate memo [4]. - -1.1 Purposes - - The DSNs defined in this memo are expected to serve several purposes: - -(a) Inform human beings of the status of message delivery processing, as - well as the reasons for any delivery problems or outright failures, - in a manner which is largely independent of human language; - -(b) Allow mail user agents to keep track of the delivery status of - messages sent, by associating returned DSNs with earlier message - transmissions; - -(c) Allow mailing list exploders to automatically maintain their - subscriber lists when delivery attempts repeatedly fail; - -(d) Convey delivery and non-delivery notifications resulting from - attempts to deliver messages to "foreign" mail systems via a - gateway; - -(e) Allow "foreign" notifications to be tunneled through a MIME-capable - message system and back into the original messaging system that - issued the original notification, or even to a third messaging - system; - -(f) Allow language-independent, yet reasonably precise, indications of - the reason for the failure of a message to be delivered (once status - codes of sufficient precision are defined); and - -(g) Provide sufficient information to remote MTA maintainers (via - "trouble tickets") so that they can understand the nature of - reported errors. This feature is used in the case that failure to - deliver a message is due to the malfunction of a remote MTA and the - - - -Moore & Vaudreuil Standards Track [Page 2] - -RFC 1894 Delivery Status Notifications January 1996 - - - sender wants to report the problem to the remote MTA administrator. - -1.2 Requirements - - These purposes place the following constraints on the notification - protocol: - -(a) It must be readable by humans as well as being machine-parsable. - -(b) It must provide enough information to allow message senders (or the - user agents) to unambiguously associate a DSN with the message that - was sent and the original recipient address for which the DSN is - issued (if such information is available), even if the message was - forwarded to another recipient address. - -(c) It must be able to preserve the reason for the success or failure of - a delivery attempt in a remote messaging system, using the - "language" (mailbox addresses and status codes) of that remote - system. - -(d) It must also be able to describe the reason for the success or - failure of a delivery attempt, independent of any particular human - language or of the "language" of any particular mail system. - -(e) It must preserve enough information to allow the maintainer of a - remote MTA to understand (and if possible, reproduce) the conditions - that caused a delivery failure at that MTA. - -(f) For any notifications issued by foreign mail systems, which are - translated by a mail gateway to the DSN format, the DSN must - preserve the "type" of the foreign addresses and error codes, so - that these may be correctly interpreted by gateways. - - A DSN contains a set of per-message fields which identify the message - and the transaction during which the message was submitted, along - with other fields that apply to all delivery attempts described by - the DSN. The DSN also includes a set of per-recipient fields to - convey the result of the attempt to deliver the message to each of - one or more recipients. - -1.3 Terminology - - A message may be transmitted through several message transfer agents - (MTAs) on its way to a recipient. For a variety of reasons, - recipient addresses may be rewritten during this process, so each MTA - may potentially see a different recipient address. Depending on the - purpose for which a DSN is used, different formats of a particular - recipient address will be needed. - - - -Moore & Vaudreuil Standards Track [Page 3] - -RFC 1894 Delivery Status Notifications January 1996 - - - Several DSN fields are defined in terms of the view from a particular - MTA in the transmission. The MTAs are assigned the following names: - - (a) Original MTA - - The Original MTA is the one to which the message is submitted for - delivery by the sender of the message. - - (b) Reporting MTA - - For any DSN, the Reporting MTA is the one which is reporting the - results of delivery attempts described in the DSN. - - If the delivery attempts described occurred in a "foreign" (non- - Internet) mail system, and the DSN was produced by translating the - foreign notice into DSN format, the Reporting MTA will still identify - the "foreign" MTA where the delivery attempts occurred. - - (c) Received-From MTA - - The Received-From MTA is the MTA from which the Reporting MTA - received the message, and accepted responsibility for delivery of the - message. - - (d) Remote MTA - - If an MTA determines that it must relay a message to one or more - recipients, but the message cannot be transferred to its "next hop" - MTA, or if the "next hop" MTA refuses to accept responsibility for - delivery of the message to one or more of its intended recipients, - the relaying MTA may need to issue a DSN on behalf of the recipients - for whom the message cannot be delivered. In this case the relaying - MTA is the Reporting MTA, and the "next hop" MTA is known as the - Remote MTA. - - - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 4] - -RFC 1894 Delivery Status Notifications January 1996 - - -Figure 1 illustrates the relationship between the various MTAs. - - -+-----+ +--------+ +---------+ +---------+ +------+ -| | | | |Received-| | | | | -| | => |Original| => ... => | From | => |Reporting| ===> |Remote| -| user| | MTA | | MTA | | MTA | <No! | MTA | -|agent| +--------+ +---------+ +----v----+ +------+ -| | | -| | <-------------------------------------------+ -+-----+ (DSN returned to sender by Reporting MTA) - - - Figure 1. Original, Received-From, Reporting and Remote MTAs - - - Each of these MTAs may provide information which is useful in a DSN: - -+ Ideally, the DSN will contain the address of each recipient as - originally specified to the Original MTA by the sender of the message. - This version of the address is needed (rather than a forwarding - address or some modified version of the original address) so that the - sender may compare the recipient address in the DSN with the address - in the sender's records (e.g. an address book for an individual, the - list of subscribers for a mailing list) and take appropriate action. - - Similarly, the DSN might contain an "envelope identifier" that was - known to both the sender's user agent and the Original MTA at the time - of message submission, and which, if included in the DSN, can be used - by the sender to keep track of which messages were or were not - delivered. - -+ If a message was (a) forwarded to a different address than that - specified by the sender, (b) gatewayed to a different mail system than - that used by the sender, or (c) subjected to address rewriting during - transmission, the "final" form of the recipient address (i.e. the one - seen by the Reporting MTA) will be different than the original - (sender-specified) recipient address. Just as the sender's user agent - (or the sender) prefers the original recipient address, so the "final" - address is needed when reporting a problem to the postmaster of the - site where message delivery failed, because only the final recipient - address will allow her to reproduce the conditions that caused the - failure. - -+ A "failed" DSN should contain the most accurate explanation for the - delivery failure that is available. For ease of interpretation, this - information should be a format which is independent of the mail - transport system that issued the DSN. However, if a foreign error - - - -Moore & Vaudreuil Standards Track [Page 5] - -RFC 1894 Delivery Status Notifications January 1996 - - - code is translated into some transport-independent format, some - information may be lost. It is therefore desirable to provide both a - transport-independent status code and a mechanism for reporting - transport-specific codes. Depending on the circumstances that - produced delivery failure, the transport-specific code might be - obtained from either the Reporting MTA or the Remote MTA. - - Since different values for "recipient address" and "delivery status - code" are needed according to the circumstance in which a DSN will be - used, and since the MTA that issues the DSN cannot anticipate those - circumstances, the DSN format described here may contain both the - original and final forms of a recipient address, and both a - transport-independent and a transport-specific indication of delivery - status. - - Extension fields may also be added by the Reporting MTA as needed to - provide additional information for use in a trouble ticket or to - preserve information for tunneling of foreign delivery reports - through Internet DSNs. - - The Original, Reporting, and Remote MTAs may exist in very different - environments and use dissimilar transport protocols, MTA names, - address formats, and delivery status codes. DSNs therefore do not - assume any particular format for mailbox addresses, MTA names, or - transport-specific status codes. Instead, the various DSN fields - that carry such quantities consist of a "type" subfield followed by a - subfield whose contents are ordinary text characters, and the format - of which is indicated by the "type" subfield. This allows a DSN to - convey these quantities regardless of format. - -2. Format of a Delivery Status Notification - - A DSN is a MIME message with a top-level content-type of - multipart/report (defined in [2]). When a multipart/report content - is used to transmit a DSN: - -(a) The report-type parameter of the multipart/report content is - "delivery-status". - -(b) The first component of the multipart/report contains a human- - readable explanation of the DSN, as described in [2]. - -(c) The second component of the multipart/report is of content-type - message/delivery-status, described in section 2.1 of this document. - -(d) If the original message or a portion of the message is to be - returned to the sender, it appears as the third component of the - multipart/report. - - - -Moore & Vaudreuil Standards Track [Page 6] - -RFC 1894 Delivery Status Notifications January 1996 - - - NOTE: For delivery status notifications gatewayed from foreign - systems, the headers of the original message may not be available. - In this case the third component of the DSN may be omitted, or it - may contain "simulated" RFC 822 headers which contain equivalent - information. In particular, it is very desirable to preserve the - subject, date, and message-id (or equivalent) fields from the - original message. - - The DSN MUST be addressed (in both the message header and the - transport envelope) to the return address from the transport envelope - which accompanied the original message for which the DSN was - generated. (For a message that arrived via SMTP, the envelope return - address appears in the MAIL FROM command.) - - The From field of the message header of the DSN SHOULD contain the - address of a human who is responsible for maintaining the mail system - at the Reporting MTA site (e.g. Postmaster), so that a reply to the - DSN will reach that person. Exception: if a DSN is translated from a - foreign delivery report, and the gateway performing the translation - cannot determine the appropriate address, the From field of the DSN - MAY be the address of a human who is responsible for maintaining the - gateway. - - The envelope sender address of the DSN SHOULD be chosen to ensure - that no delivery status reports will be issued in response to the DSN - itself, and MUST be chosen so that DSNs will not generate mail loops. - Whenever an SMTP transaction is used to send a DSN, the MAIL FROM - command MUST use a NULL return address, i.e. "MAIL FROM:<>". - - A particular DSN describes the delivery status for exactly one - message. However, an MTA MAY report on the delivery status for - several recipients of the same message in a single DSN. Due to the - nature of the mail transport system (where responsibility for - delivery of a message to its recipients may be split among several - MTAs, and delivery to any particular recipient may be delayed), - multiple DSNs may be still be issued in response to a single message - submission. - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 7] - -RFC 1894 Delivery Status Notifications January 1996 - - -2.1 The message/delivery-status content-type - - The message/delivery-status content-type is defined as follows: - - MIME type name: message - MIME subtype name: delivery-status - Optional parameters: none - Encoding considerations: "7bit" encoding is sufficient and - MUST be used to maintain readability - when viewed by non-MIME mail - readers. - Security considerations: discussed in section 4 of this memo. - - The message/delivery-status report type for use in the - multipart/report is "delivery-status". - - The body of a message/delivery-status consists of one or more - "fields" formatted according to the ABNF of RFC 822 header "fields" - (see [6]). The per-message fields appear first, followed by a blank - line. Following the per-message fields are one or more groups of - per-recipient fields. Each group of per-recipient fields is preceded - by a blank line. Using the ABNF of RFC 822, the syntax of the - message/delivery-status content is as follows: - - delivery-status-content = - per-message-fields 1*( CRLF per-recipient-fields ) - - The per-message fields are described in section 2.2. The per- - recipient fields are described in section 2.3. - - -2.1.1 General conventions for DSN fields - - Since these fields are defined according to the rules of RFC 822, the - same conventions for continuation lines and comments apply. - Notification fields may be continued onto multiple lines by beginning - each additional line with a SPACE or HTAB. Text which appears in - parentheses is considered a comment and not part of the contents of - that notification field. Field names are case-insensitive, so the - names of notification fields may be spelled in any combination of - upper and lower case letters. Comments in DSN fields may use the - "encoded-word" construct defined in [7]. - - A number of DSN fields are defined to have a portion of a field body - of "xtext". "xtext" is used to allow encoding sequences of octets - which contain values outside the range [1-127 decimal] of traditional - ASCII characters, and also to allow comments to be inserted in the - data. Any octet may be encoded as "+" followed by two upper case - - - -Moore & Vaudreuil Standards Track [Page 8] - -RFC 1894 Delivery Status Notifications January 1996 - - - hexadecimal digits. (The "+" character MUST be encoded as "+2B".) - With certain exceptions, octets that correspond to ASCII characters - may be represented as themselves. SPACE and HTAB characters are - ignored. Comments may be included by enclosing them in parenthesis. - Except within comments, encoded-words such as defined in [7] may NOT - be used in xtext. - - "xtext" is formally defined as follows: - - xtext = *( xchar / hexchar / linear-white-space / comment ) - - xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, - except for "+", "\" and "(". - - "hexchar"s are intended to encode octets that cannot be represented - as plain text, either because they are reserved, or because they are - non-printable. However, any octet value may be represented by a - "hexchar". - - hexchar = ASCII "+" immediately followed by two upper case - hexadecimal digits - - When encoding an octet sequence as xtext: - - + Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\", - and "(", MAY be encoded as itself. (Some CHARs in this range may - also be encoded as "hexchar"s, at the implementor's discretion.) - - + ASCII CHARs that fall outside the range above must be encoded as - "hexchar". - - + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line - lengths from becoming excessive. - - + Comments MAY be added to clarify the meaning for human readers. - -2.1.2 "*-type" subfields - - Several DSN fields consist of a "-type" subfield, followed by a - semicolon, followed by "*text". For these fields, the keyword used - in the address-type, diagnostic-type, or MTA-name-type subfield - indicates the expected format of the address, status-code, or MTA- - name which follows. - - - - - - - - -Moore & Vaudreuil Standards Track [Page 9] - -RFC 1894 Delivery Status Notifications January 1996 - - - The "-type" subfields are defined as follows: - -(a) An "address-type" specifies the format of a mailbox address. For - example, Internet mail addresses use the "rfc822" address-type. - - address-type = atom - -(b) A "diagnostic-type" specifies the format of a status code. For - example, when a DSN field contains a reply code reported via the - Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is - used. - - diagnostic-type = atom - -(c) An "MTA-name-type" specifies the format of an MTA name. For - example, for an SMTP server on an Internet host, the MTA name is the - domain name of that host, and the "dns" MTA-name-type is used. - - mta-name-type = atom - - Values for address-type, diagnostic-type, and MTA-name-type are - case-insensitive. Thus address-type values of "RFC822" and "rfc822" - are equivalent. - - The Internet Assigned Numbers Authority (IANA) will maintain a - registry of address-types, diagnostic-types, and MTA-name-types, - along with descriptions of the meanings and acceptable values of - each, or a reference to a one or more specifications that provide - such descriptions. (The "rfc822" address-type, "smtp" diagnostic- - type, and "dns" MTA-name-type are defined in [4].) Registration - forms for address-type, diagnostic-type, and MTA-name-type appear in - section 8 of this document. - - IANA will not accept registrations for any address-type, diagnostic- - type, or MTA-name-type name that begins with "X-". These type names - are reserved for experimental use. - -2.1.3 Lexical tokens imported from RFC 822 - - The following lexical tokens, defined in [6], are used in the ABNF - grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear- - white-space, SPACE, text. The date-time lexical token is defined in - [8]. - - - - - - - - -Moore & Vaudreuil Standards Track [Page 10] - -RFC 1894 Delivery Status Notifications January 1996 - - -2.2 Per-Message DSN Fields - - Some fields of a DSN apply to all of the delivery attempts described - by that DSN. These fields may appear at most once in any DSN. These - fields are used to correlate the DSN with the original message - transaction and to provide additional information which may be useful - to gateways. - - per-message-fields = - [ original-envelope-id-field CRLF ] - reporting-mta-field CRLF - [ dsn-gateway-field CRLF ] - [ received-from-mta-field CRLF ] - [ arrival-date-field CRLF ] - *( extension-field CRLF ) - -2.2.1 The Original-Envelope-Id field - - The optional Original-Envelope-Id field contains an "envelope - identifier" which uniquely identifies the transaction during which - the message was submitted, and was either (a) specified by the sender - and supplied to the sender's MTA, or (b) generated by the sender's - MTA and made available to the sender when the message was submitted. - Its purpose is to allow the sender (or her user agent) to associate - the returned DSN with the specific transaction in which the message - was sent. - - If such an envelope identifier was present in the envelope which - accompanied the message when it arrived at the Reporting MTA, it - SHOULD be supplied in the Original-Envelope-Id field of any DSNs - issued as a result of an attempt to deliver the message. Except when - a DSN is issued by the sender's MTA, an MTA MUST NOT supply this - field unless there is an envelope-identifier field in the envelope - which accompanied this message on its arrival at the Reporting MTA. - - The Original-Envelope-Id field is defined as follows: - - original-envelope-id-field = - "Original-Envelope-Id" ":" envelope-id - - envelope-id = *text - - There may be at most one Original-Envelope-Id field per DSN. - - The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the - original case and spelling of the envelope-id. - - - - - -Moore & Vaudreuil Standards Track [Page 11] - -RFC 1894 Delivery Status Notifications January 1996 - - - NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from - the message header. The Message-Id identifies the content of the - message, while the Original-Envelope-Id identifies the transaction in - which the message is sent. - -2.2.2 The Reporting-MTA DSN field - - reporting-mta-field = - "Reporting-MTA" ":" mta-name-type ";" mta-name - - mta-name = *text - - The Reporting-MTA field is defined as follows: - - A DSN describes the results of attempts to deliver, relay, or gateway - a message to one or more recipients. In all cases, the Reporting-MTA - is the MTA which attempted to perform the delivery, relay, or gateway - operation described in the DSN. This field is required. - - Note that if an SMTP client attempts to relay a message to an SMTP - server and receives an error reply to a RCPT command, the client is - responsible for generating the DSN, and the client's domain name will - appear in the Reporting-MTA field. (The server's domain name will - appear in the Remote-MTA field.) - - Note that the Reporting-MTA is not necessarily the MTA which actually - issued the DSN. For example, if an attempt to deliver a message - outside of the Internet resulted in a nondelivery notification which - was gatewayed back into Internet mail, the Reporting-MTA field of the - resulting DSN would be that of the MTA that originally reported the - delivery failure, not that of the gateway which converted the foreign - notification into a DSN. See Figure 2. - - - - - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 12] - -RFC 1894 Delivery Status Notifications January 1996 - - -sender's environment recipient's environment -............................ .......................................... - : : - (1) : : (2) - +-----+ +--------+ +--------+ +---------+ +---------+ +------+ - | | | | | | |Received-| | | | | - | |=>|Original|=>| |->| From |->|Reporting|-->|Remote| - | user| | MTA | | | | MTA | | MTA |<No| MTA | - |agent| +--------+ |Gateway | +---------+ +----v----+ +------+ - | | | | | - | | <============| |<-------------------+ - +-----+ | |(4) (3) - +--------+ - : : -...........................: :......................................... - - Figure 2. DSNs in the presence of gateways - - (1) message is gatewayed into recipient's environment - (2) attempt to relay message fails - (3) reporting-mta (in recipient's environment) returns nondelivery - notification - (4) gateway translates foreign notification into a DSN - - - - The mta-name portion of the Reporting-MTA field is formatted - according to the conventions indicated by the mta-name-type subfield. - If an MTA functions as a gateway between dissimilar mail environments - and thus is known by multiple names depending on the environment, the - mta-name subfield SHOULD contain the name used by the environment - from which the message was accepted by the Reporting-MTA. - - Because the exact spelling of an MTA name may be significant in a - particular environment, MTA names are CASE-SENSITIVE. - -2.2.3 The DSN-Gateway field - - The DSN-Gateway field indicates the name of the gateway or MTA which - translated a foreign (non-Internet) delivery status notification into - this DSN. This field MUST appear in any DSN which was translated by - a gateway from a foreign system into DSN format, and MUST NOT appear - otherwise. - - dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name - - - - - - -Moore & Vaudreuil Standards Track [Page 13] - -RFC 1894 Delivery Status Notifications January 1996 - - - For gateways into Internet mail, the MTA-name-type will normally be - "smtp", and the mta-name will be the Internet domain name of the - gateway. - -2.2.4 The Received-From-MTA DSN field - - The optional Received-From-MTA field indicates the name of the MTA - from which the message was received. - - received-from-mta-field = - "Received-From-MTA" ":" mta-name-type ";" mta-name - - If the message was received from an Internet host via SMTP, the - contents of the mta-name subfield SHOULD be the Internet domain name - supplied in the HELO or EHLO command, and the network address used by - the SMTP client SHOULD be included as a comment enclosed in - parentheses. (In this case, the MTA-name-type will be "smtp".) - - The mta-name portion of the Received-From-MTA field is formatted - according to the conventions indicated by the MTA-name-type subfield. - - Since case is significant in some mail systems, the exact spelling, - including case, of the MTA name SHOULD be preserved. - -2.2.5 The Arrival-Date DSN field - - The optional Arrival-Date field indicates the date and time at which - the message arrived at the Reporting MTA. If the Last-Attempt-Date - field is also provided in a per-recipient field, this can be used to - determine the interval between when the message arrived at the - Reporting MTA and when the report was issued for that recipient. - - arrival-date-field = "Arrival-Date" ":" date-time - - The date and time are expressed in RFC 822 'date-time' format, as - modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used. - -2.3 Per-Recipient DSN fields - - A DSN contains information about attempts to deliver a message to one - or more recipients. The delivery information for any particular - recipient is contained in a group of contiguous per-recipient fields. - Each group of per-recipient fields is preceded by a blank line. - - - - - - - - -Moore & Vaudreuil Standards Track [Page 14] - -RFC 1894 Delivery Status Notifications January 1996 - - - The syntax for the group of per-recipient fields is as follows: - - - per-recipient-fields = - [ original-recipient-field CRLF ] - final-recipient-field CRLF - action-field CRLF - status-field CRLF - [ remote-mta-field CRLF ] - [ diagnostic-code-field CRLF ] - [ last-attempt-date-field CRLF ] - [ will-retry-until-field CRLF ] - *( extension-field CRLF ) - -2.3.1 Original-Recipient field - - The Original-Recipient field indicates the original recipient address - as specified by the sender of the message for which the DSN is being - issued. - - original-recipient-field = - "Original-Recipient" ":" address-type ";" generic-address - - generic-address = *text - - The address-type field indicates the type of the original recipient - address. If the message originated within the Internet, the - address-type field field will normally be "rfc822", and the address - will be according to the syntax specified in [6]. The value - "unknown" should be used if the Reporting MTA cannot determine the - type of the original recipient address from the message envelope. - - This field is optional. It should be included only if the sender- - specified recipient address was present in the message envelope, such - as by the SMTP extensions defined in [4]. This address is the same - as that provided by the sender and can be used to automatically - correlate DSN reports and message transactions. - -2.3.2 Final-Recipient field - - The Final-Recipient field indicates the recipient for which this set - of per-recipient fields applies. This field MUST be present in each - set of per-recipient data. - - - - - - - - -Moore & Vaudreuil Standards Track [Page 15] - -RFC 1894 Delivery Status Notifications January 1996 - - - The syntax of the field is as follows: - - final-recipient-field = - "Final-Recipient" ":" address-type ";" generic-address - - The generic-address subfield of the Final-Recipient field MUST - contain the mailbox address of the recipient (from the transport - envelope) as it was when the message was accepted for delivery by the - Reporting MTA. - - The Final-Recipient address may differ from the address originally - provided by the sender, because it may have been transformed during - forwarding and gatewaying into an totally unrecognizable mess. - However, in the absence of the optional Original-Recipient field, the - Final-Recipient field and any returned content may be the only - information available with which to correlate the DSN with a - particular message submission. - - The address-type subfield indicates the type of address expected by - the reporting MTA in that context. Recipient addresses obtained via - SMTP will normally be of address-type "rfc822". - - NOTE: The Reporting MTA is not expected to ensure that the address - actually conforms to the syntax conventions of the address-type. - Instead, it MUST report exactly the address received in the envelope, - unless that address contains characters such as CR or LF which may - not appear in a DSN field. - - Since mailbox addresses (including those used in the Internet) may be - case sensitive, the case of alphabetic characters in the address MUST - be preserved. - -2.3.3 Action field - - The Action field indicates the action performed by the Reporting-MTA - as a result of its attempt to deliver the message to this recipient - address. This field MUST be present for each recipient named in the - DSN. - - The syntax for the action-field is: - - action-field = "Action" ":" action-value - - action-value = - "failed" / "delayed" / "delivered" / "relayed" / "expanded" - - - - - - -Moore & Vaudreuil Standards Track [Page 16] - -RFC 1894 Delivery Status Notifications January 1996 - - - The action-value may be spelled in any combination of upper and lower - case characters. - -"failed" indicates that the message could not be delivered to the - recipient. The Reporting MTA has abandoned any attempts to - deliver the message to this recipient. No further - notifications should be expected. - -"delayed" indicates that the Reporting MTA has so far been unable to - deliver or relay the message, but it will continue to - attempt to do so. Additional notification messages may be - issued as the message is further delayed or successfully - delivered, or if delivery attempts are later abandoned. - -"delivered" indicates that the message was successfully delivered to - the recipient address specified by the sender, which - includes "delivery" to a mailing list exploder. It does - not indicate that the message has been read. This is a - terminal state and no further DSN for this recipient should - be expected. - -"relayed" indicates that the message has been relayed or gatewayed - into an environment that does not accept responsibility for - generating DSNs upon successful delivery. This action- - value SHOULD NOT be used unless the sender has requested - notification of successful delivery for this recipient. - -"expanded" indicates that the message has been successfully delivered - to the recipient address as specified by the sender, and - forwarded by the Reporting-MTA beyond that destination to - multiple additional recipient addresses. An action-value - of "expanded" differs from "delivered" in that "expanded" - is not a terminal state. Further "failed" and/or "delayed" - notifications may be provided. - - Using the terms "mailing list" and "alias" as defined in - [4], section 7.2.7: An action-value of "expanded" is only - to be used when the message is delivered to a multiple- - recipient "alias". An action-value of "expanded" SHOULD - NOT be used with a DSN issued on delivery of a message to a - "mailing list". - - NOTE ON ACTION VS. STATUS CODES: Although the 'action' field might - seem to be redundant with the 'status' field, this is not the case. - In particular, a "temporary failure" ("4") status code could be used - with an action-value of either "delayed" or "failed". For example, - assume that an SMTP client repeatedly tries to relay a message to the - mail exchanger for a recipient, but fails because a query to a domain - - - -Moore & Vaudreuil Standards Track [Page 17] - -RFC 1894 Delivery Status Notifications January 1996 - - - name server timed out. After a few hours, it might issue a "delayed" - DSN to inform the sender that the message had not yet been delivered. - After a few days, the MTA might abandon its attempt to deliver the - message and return a "failed" DSN. The status code (which would - begin with a "4" to indicate "temporary failure") would be the same - for both DSNs. - - Another example for which the action and status codes may appear - contradictory: If an MTA or mail gateway cannot deliver a message - because doing so would entail conversions resulting in an - unacceptable loss of information, it would issue a DSN with the - 'action' field of "failure" and a status code of 'XXX'. If the - message had instead been relayed, but with some loss of information, - it might generate a DSN with the same XXX status-code, but with an - action field of "relayed". - -2.3.4 Status field - - The per-recipient Status field contains a transport-independent - status code which indicates the delivery status of the message to - that recipient. This field MUST be present for each delivery attempt - which is described by a DSN. - - The syntax of the status field is: - - status-field = "Status" ":" status-code - - status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT - - ; White-space characters and comments are NOT allowed within a - ; status-code, though a comment enclosed in parentheses MAY follow - ; the last numeric subfield of the status-code. Each numeric - ; subfield within the status-code MUST be expressed without - ; leading zero digits. - - Status codes thus consist of three numerical fields separated by ".". - The first sub-field indicates whether the delivery attempt was - successful (2 = success, 4 = persistent temporary failure, 5 = - permanent failure). The second sub-field indicates the probable - source of any delivery anomalies, and the third sub-field denotes a - precise error condition, if known. - - The initial set of status-codes is defined in [5]. - - - - - - - - -Moore & Vaudreuil Standards Track [Page 18] - -RFC 1894 Delivery Status Notifications January 1996 - - -2.3.5 Remote-MTA field - - The value associated with the Remote-MTA DSN field is a printable - ASCII representation of the name of the "remote" MTA that reported - delivery status to the "reporting" MTA. - - remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name - - NOTE: The Remote-MTA field preserves the "while talking to" - information that was provided in some pre-existing nondelivery - reports. - - This field is optional. It MUST NOT be included if no remote MTA was - involved in the attempted delivery of the message to that recipient. - -2.3.6 Diagnostic-Code field - - For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field - contains the actual diagnostic code issued by the mail transport. - Since such codes vary from one mail transport to another, the - diagnostic-type subfield is needed to specify which type of - diagnostic code is represented. - - diagnostic-code-field = - "Diagnostic-Code" ":" diagnostic-type ";" *text - - NOTE: The information in the Diagnostic-Code field may be somewhat - redundant with that from the Status field. The Status field is - needed so that any DSN, regardless of origin, may be understood by - any user agent or gateway that parses DSNs. Since the Status code - will sometimes be less precise than the actual transport diagnostic - code, the Diagnostic-Code field is provided to retain the latter - information. Such information may be useful in a trouble ticket sent - to the administrator of the Reporting MTA, or when tunneling foreign - nondelivery reports through DSNs. - - If the Diagnostic Code was obtained from a Remote MTA during an - attempt to relay the message to that MTA, the Remote-MTA field should - be present. When interpreting a DSN, the presence of a Remote-MTA - field indicates that the Diagnostic Code was issued by the Remote - MTA. The absence of a Remote-MTA indicates that the Diagnostic Code - was issued by the Reporting MTA. - - In addition to the Diagnostic-Code itself, additional textual - description of the diagnostic, MAY appear in a comment enclosed in - parentheses. - - - - - -Moore & Vaudreuil Standards Track [Page 19] - -RFC 1894 Delivery Status Notifications January 1996 - - - This field is optional, because some mail systems supply no - additional information beyond that which is returned in the 'action' - and 'status' fields. However, this field SHOULD be included if - transport-specific diagnostic information is available. - -2.3.7 Last-Attempt-Date field - - The Last-Attempt-Date field gives the date and time of the last - attempt to relay, gateway, or deliver the message (whether successful - or unsuccessful) by the Reporting MTA. This is not necessarily the - same as the value of the Date field from the header of the message - used to transmit this delivery status notification: In cases where - the DSN was generated by a gateway, the Date field in the message - header contains the time the DSN was sent by the gateway and the DSN - Last-Attempt-Date field contains the time the last delivery attempt - occurred. - - last-attempt-date-field = "Last-Attempt-Date" ":" date-time - - This field is optional. It MUST NOT be included if the actual date - and time of the last delivery attempt are not available (which might - be the case if the DSN were being issued by a gateway). - - The date and time are expressed in RFC 822 'date-time' format, as - modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used. - - 3.2.1.5 final-log-id field - - The "final-log-id" field gives the final-log-id of the message that - was used by the final-mta. This can be useful as an index to the - final-mta's log entry for that delivery attempt. - - final-log-id-field = "Final-Log-ID" ":" *text - - This field is optional. - -2.3.8 Will-Retry-Until field - - For DSNs of type "delayed", the Will-Retry-Until field gives the date - after which the Reporting MTA expects to abandon all attempts to - deliver the message to that recipient. The Will-Retry-Until field is - optional for "delay" DSNs, and MUST NOT appear in other DSNs. - - will-retry-until-field = "Will-Retry-Until" ":" date-time - - The date and time are expressed in RFC 822 'date-time' format, as - modified by [8]. Numeric timezones ([+/-]HHMM format) MUST be used. - - - - -Moore & Vaudreuil Standards Track [Page 20] - -RFC 1894 Delivery Status Notifications January 1996 - - -2.4 Extension fields - - Additional per-message or per-recipient DSN fields may be defined in - the future by later revisions or extensions to this specification. - Extension-field names beginning with "X-" will never be defined as - standard fields; such names are reserved for experimental use. DSN - field names NOT beginning with "X-" MUST be registered with the - Internet Assigned Numbers Authority (IANA) and published in an RFC. - - Extension DSN fields may be defined for the following reasons: - - (a) To allow additional information from foreign delivery status - reports to be tunneled through Internet DSNs. The names of such - DSN fields should begin with an indication of the foreign - environment name (e.g. X400-Physical-Forwarding-Address). - - (b) To allow the transmission of diagnostic information which is - specific to a particular mail transport protocol. The names of - such DSN fields should begin with an indication of the mail - transport being used (e.g. SMTP-Remote-Recipient-Address). Such - fields should be used for diagnostic purposes only and not by - user agents or mail gateways. - - (c) To allow transmission of diagnostic information which is specific - to a particular message transfer agent (MTA). The names of such - DSN fields should begin with an indication of the MTA - implementation which produced the DSN. (e.g. Foomail-Queue-ID). - - MTA implementors are encouraged to provide adequate information, via - extension fields if necessary, to allow an MTA maintainer to - understand the nature of correctable delivery failures and how to fix - them. For example, if message delivery attempts are logged, the DSN - might include information which allows the MTA maintainer to easily - find the log entry for a failed delivery attempt. - - If an MTA developer does not wish to register the meanings of such - extension fields, "X-" fields may be used for this purpose. To avoid - name collisions, the name of the MTA implementation should follow the - "X-", (e.g. "X-Foomail-Log-ID"). - -3. Conformance and Usage Requirements - - An MTA or gateway conforms to this specification if it generates DSNs - according to the protocol defined in this memo. For MTAs and - gateways that do not support requests for positive delivery - notification (such as in [4]), it is sufficient that delivery failure - reports use this protocol. - - - - -Moore & Vaudreuil Standards Track [Page 21] - -RFC 1894 Delivery Status Notifications January 1996 - - - A minimal implementation of this specification need generate only the - Reporting-MTA per-message field, and the Final-Recipient, Action, and - Status fields for each attempt to deliver a message to a recipient - described by the DSN. Generation of the other fields, when - appropriate, is strongly recommended. - - MTAs and gateways MUST NOT generate the Original-Recipient field of a - DSN unless the mail transfer protocol provides the address originally - specified by the sender at the time of submission. (Ordinary SMTP - does not make that guarantee, but the SMTP extension defined in [4] - permits such information to be carried in the envelope if it is - available.) - - Each sender-specified recipient address SHOULD result in at most one - "delivered" or "failed" DSN for that recipient. If a positive DSN is - requested (e.g. one using NOTIFY=SUCCESS in SMTP) for a recipient - that is forwarded to multiple recipients of an "alias" (as defined in - [4], section 7.2.7), the forwarding MTA SHOULD normally issue a - "expanded" DSN for the originally-specified recipient and not - propagate the request for a DSN to the forwarding addresses. - Alternatively, the forwarding MTA MAY relay the request for a DSN to - exactly one of the forwarding addresses and not propagate the request - to the others. - - By contrast, successful submission of a message to a mailing list - exploder is considered final delivery of the message. Upon delivery - of a message to a recipient address corresponding to a mailing list - exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly - as if the recipient address were that of an ordinary mailbox. - - NOTE: This is actually intended to make DSNs usable by mailing lists - themselves. Any message sent to a mailing list subscriber should - have its envelope return address pointing to the list maintainer [see - RFC 1123, section 5.3.7(E)]. Since DSNs are sent to the envelope - return address, all DSNs resulting from delivery to the recipients of - a mailing list will be sent to the list maintainer. The list - maintainer may elect to mechanically process DSNs upon receipt, and - thus automatically delete invalid addresses from the list. (See - section 7 of this memo.) - - This specification places no restrictions on the processing of DSNs - received by user agents or distribution lists. - -4. Security Considerations - - The following security considerations apply when using DSNs: - - - - - -Moore & Vaudreuil Standards Track [Page 22] - -RFC 1894 Delivery Status Notifications January 1996 - - -4.1 Forgery - - DSNs may be forged as easily as ordinary Internet electronic mail. - User agents and automatic mail handling facilities (such as mail - distribution list exploders) that wish to make automatic use of DSNs - should take appropriate precautions to minimize the potential damage - from denial-of-service attacks. - - Security threats related to forged DSNs include the sending of: - -(a) A falsified delivery notification when the message is not delivered - to the indicated recipient, -(b) A falsified non-delivery notification when the message was in fact - delivered to the indicated recipient, -(c) A falsified Final-Recipient address, -(d) A falsified Remote-MTA identification, -(e) A falsified relay notification when the message is "dead ended". -(f) Unsolicited DSNs - -4.2 Confidentiality - - Another dimension of security is confidentiality. There may be cases - in which a message recipient is autoforwarding messages but does not - wish to divulge the address to which the messages are autoforwarded. - The desire for such confidentiality will probably be heightened as - "wireless mailboxes", such as pagers, become more widely used as - autoforward addresses. - - MTA authors are encouraged to provide a mechanism which enables the - end user to preserve the confidentiality of a forwarding address. - Depending on the degree of confidentiality required, and the nature - of the environment to which a message were being forwarded, this - might be accomplished by one or more of: - -(a) issuing a "relayed" DSN (if a positive DSN was requested) when a - message is forwarded to a confidential forwarding address, and - disabling requests for positive DSNs for the forwarded message, - -(b) declaring the message to be delivered, issuing a "delivered" DSN, - re-sending the message to the confidential forwarding address, and - arranging for no DSNs to be issued for the re-sent message, - -(c) omitting "Remote-*" or extension fields of a DSN whenever they would - otherwise contain confidential information (such as a confidential - forwarding address), - -(d) for messages forwarded to a confidential address, setting the - envelope return address (e.g. SMTP MAIL FROM address) to the NULL - - - -Moore & Vaudreuil Standards Track [Page 23] - -RFC 1894 Delivery Status Notifications January 1996 - - - reverse-path ("<>") (so that no DSNs would be sent from a downstream - MTA to the original sender), - -(e) for messages forwarded to a confidential address, disabling delivery - notifications for the forwarded message (e.g. if the "next-hop" MTA - uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER - parameter to the RCPT command), or - -(f) when forwarding mail to a confidential address, having the - forwarding MTA rewrite the envelope return address for the forwarded - message and attempt delivery of that message as if the forwarding - MTA were the originator. On its receipt of final delivery status, - the forwarding MTA would issue a DSN to the original sender. - - In general, any optional DSN field may be omitted if the Reporting - MTA site determines that inclusion of the field would impose too - great a compromise of site confidentiality. The need for such - confidentiality must be balanced against the utility of the omitted - information in trouble reports and DSNs gatewayed to foreign - environments. - - Implementors are cautioned that many existing MTAs will send - nondelivery notifications to a return address in the message header - (rather than to the one in the envelope), in violation of SMTP and - other protocols. If a message is forwarded through such an MTA, no - reasonable action on the part of the forwarding MTA will prevent the - downstream MTA from compromising the forwarding address. Likewise, - if the recipient's MTA automatically responds to messages based on a - request in the message header (such as the nonstandard, but widely - used, Return-Receipt-To extension header), it will also compromise - the forwarding address. - -4.3 Non-Repudiation - - Within the framework of today's internet mail, the DSNs defined in - this memo provide valuable information to the mail user; however, - even a "failed" DSN can not be relied upon as a guarantee that a - message was not received by the recipient. Even if DSNs are not - actively forged, conditions exist under which a message can be - delivered despite the fact that a failure DSN was issued. - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 24] - -RFC 1894 Delivery Status Notifications January 1996 - - - For example, a race condition in the SMTP protocol allows for the - duplication of messages if the connection is dropped following a - completed DATA command, but before a response is seen by the SMTP - client. This will cause the SMTP client to retransmit the message, - even though the SMTP server has already accepted it.[9] If one of - those delivery attempts succeeds and the other one fails, a "failed" - DSN could be issued even though the message actually reached the - recipient. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 25] - -RFC 1894 Delivery Status Notifications January 1996 - - -5. Appendix - collected grammar - - NOTE: The following lexical tokens are defined in RFC 822: atom, - CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text. - The date-time lexical token is defined in [8]. - -action-field = "Action" ":" action-value - -action-value = - "failed" / "delayed" / "delivered" / "relayed" / "expanded" - -address-type = atom - -arrival-date-field = "Arrival-Date" ":" date-time - -delivery-status-content = - per-message-fields 1*( CRLF per-recipient-fields ) - -diagnostic-code-field = - "Diagnostic-Code" ":" diagnostic-type ";" *text - -diagnostic-type = atom - -dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name - -envelope-id = *text - -extension-field = extension-field-name ":" *text - -extension-field-name = atom - -final-recipient-field = - "Final-Recipient" ":" address-type ";" generic-address - -generic-address = *text - -last-attempt-date-field = "Last-Attempt-Date" ":" date-time - -mta-name = *text - -mta-name-type = atom - -original-envelope-id-field = - "Original-Envelope-Id" ":" envelope-id - -original-recipient-field = - "Original-Recipient" ":" address-type ";" generic-address - - - - -Moore & Vaudreuil Standards Track [Page 26] - -RFC 1894 Delivery Status Notifications January 1996 - - -per-message-fields = - [ original-envelope-id-field CRLF ] - reporting-mta-field CRLF - [ dsn-gateway-field CRLF ] - [ received-from-mta-field CRLF ] - [ arrival-date-field CRLF ] - *( extension-field CRLF ) - -per-recipient-fields = - [ original-recipient-field CRLF ] - final-recipient-field CRLF - action-field CRLF - status-field CRLF - [ remote-mta-field CRLF ] - [ diagnostic-code-field CRLF ] - [ last-attempt-date-field CRLF ] - [ will-retry-until-field CRLF ] - *( extension-field CRLF ) - -received-from-mta-field = - "Received-From-MTA" ":" mta-name-type ";" mta-name - -remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name - -reporting-mta-field = - "Reporting-MTA" ":" mta-name-type ";" mta-name - -status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT - - ; White-space characters and comments are NOT allowed within a - ; status-code, though a comment enclosed in parentheses MAY follow - ; the last numeric subfield of the status-code. Each numeric - ; subfield within the status-code MUST be expressed without - ; leading zero digits. - -status-field = "Status" ":" status-code - -will-retry-until-field = "Will-Retry-Until" ":" date-time - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 27] - -RFC 1894 Delivery Status Notifications January 1996 - - -6. Appendix - Guidelines for gatewaying DSNs - - NOTE: This section provides non-binding recommendations for the - construction of mail gateways that wish to provide semi-transparent - delivery reports between the Internet and another electronic mail - system. Specific DSN gateway requirements for a particular pair of - mail systems may be defined by other documents. - -6.1 Gatewaying from other mail systems to DSNs - - A mail gateway may issue a DSN to convey the contents of a "foreign" - delivery or non-delivery notification over Internet mail. When there - are appropriate mappings from the foreign notification elements to - DSN fields, the information may be transmitted in those DSN fields. - Additional information (such as might be useful in a trouble ticket - or needed to tunnel the foreign notification through the Internet) - may be defined in extension DSN fields. (Such fields should be given - names that identify the foreign mail protocol, e.g. X400-* for X.400 - NDN or DN protocol elements) - - The gateway must attempt to supply reasonable values for the - Reporting-MTA, Final-Recipient, Action, and Status fields. These - will normally be obtained by translating the values from the remote - delivery or non-delivery notification into their Internet-style - equivalents. However, some loss of information is to be expected. - For example, the set of status-codes defined for DSNs may not be - adequate to fully convey the delivery diagnostic code from the - foreign system. The gateway should assign the most precise code - which describes the failure condition, falling back on "generic" - codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0 - (permanent failure) when necessary. The actual foreign diagnostic - code should be retained in the Diagnostic-Code field (with an - appropriate diagnostic-type value) for use in trouble tickets or - tunneling. - - The sender-specified recipient address, and the original envelope-id, - if present in the foreign transport envelope, should be preserved in - the Original-Recipient and Original-Envelope-ID fields. - - The gateway should also attempt to preserve the "final" recipient - addresses and MTA names from the foreign system. Whenever possible, - foreign protocol elements should be encoded as meaningful printable - ASCII strings. - - For DSNs produced from foreign delivery or nondelivery notifications, - the name of the gateway MUST appear in the DSN-Gateway field of the - DSN. - - - - -Moore & Vaudreuil Standards Track [Page 28] - -RFC 1894 Delivery Status Notifications January 1996 - - -6.2 Gatewaying from DSNs to other mail systems - - It may be possible to gateway DSNs from the Internet into a foreign - mail system. The primary purpose of such gatewaying is to convey - delivery status information in a form that is usable by the - destination system. A secondary purpose is to allow "tunneling" of - DSNs through foreign mail systems, in case the DSN may be gatewayed - back into the Internet. - - In general, the recipient of the DSN (i.e., the sender of the - original message) will want to know, for each recipient: the closest - available approximation to the original recipient address, the - delivery status (success, failure, or temporary failure), and for - failed deliveries, a diagnostic code that describes the reason for - the failure. - - If possible, the gateway should attempt to preserve the Original- - Recipient address and Original-Envelope-ID (if present), in the - resulting foreign delivery status report. - - When reporting delivery failures, if the diagnostic-type subfield of - the Diagnostic-Code field indicates that the original diagnostic code - is understood by the destination environment, the information from - the Diagnostic-Code field should be used. Failing that, the - information in the Status field should be mapped into the closest - available diagnostic code used in the destination environment. - - If it is possible to tunnel a DSN through the destination - environment, the gateway specification may define a means of - preserving the DSN information in the delivery status reports used by - that environment. - - - - - - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 29] - -RFC 1894 Delivery Status Notifications January 1996 - - -7. Appendix - Guidelines for use of DSNs by mailing list exploders - - NOTE: This section pertains only to the use of DSNs by "mailing - lists" as defined in [4], section 7.2.7. - - DSNs are designed to be used by mailing list exploders to allow them - to detect and automatically delete recipients for whom mail delivery - fails repeatedly. - - When forwarding a message to list subscribers, the mailing list - exploder should always set the envelope return address (e.g. SMTP - MAIL FROM address) to point to a special address which is set up to - received nondelivery reports. A "smart" mailing list exploder can - therefore intercept such nondelivery reports, and if they are in the - DSN format, automatically examine them to determine for which - recipients a message delivery failed or was delayed. - - The Original-Recipient field should be used if available, since it - should exactly match the subscriber address known to the list. If - the Original-Recipient field is not available, the recipient field - may resemble the list subscriber address. Often, however, the list - subscriber will have forwarded his mail to a different address, or - the address may be subject to some re-writing, so heuristics may be - required to successfully match an address from the recipient field. - Care is needed in this case to minimize the possibility of false - matches. - - The reason for delivery failure can be obtained from the Status and - Action fields, and from the Diagnostic-Code field (if the status-type - is recognized). Reports for recipients with action values other than - "failed" can generally be ignored; in particular, subscribers should - not be removed from a list due to "delayed" reports. - - In general, almost any failure status code (even a "permanent" one) - can result from a temporary condition. It is therefore recommended - that a list exploder not delete a subscriber based on any single - failure DSN (regardless of the status code), but only on the - persistence of delivery failure over a period of time. - - However, some kinds of failures are less likely than others to have - been caused by temporary conditions, and some kinds of failures are - more likely to be noticed and corrected quickly than others. Once - more precise status codes are defined, it may be useful to - differentiate between the status codes when deciding whether to - delete a subscriber. For example, on a list with a high message - volume, it might be desirable to temporarily suspend delivery to a - recipient address which causes repeated "temporary" failures, rather - than simply deleting the recipient. The duration of the suspension - - - -Moore & Vaudreuil Standards Track [Page 30] - -RFC 1894 Delivery Status Notifications January 1996 - - - might depend on the type of error. On the other hand, a "user - unknown" error which persisted for several days could be considered a - reliable indication that address were no longer valid. - -8. Appendix - IANA registration forms for DSN types - - The forms below are for use when registering a new address-type, - diagnostic-type, or MTA-name-type with the Internet Assigned Numbers - Authority (IANA). Each piece of information requested by a - registration form may be satisfied either by providing the - information on the form itself, or by including a reference to a - published, publicly available specification which includes the - necessary information. IANA MAY reject DSN type registrations - because of incomplete registration forms, imprecise specifications, - or inappropriate type names. - - To register a DSN type, complete the applicable form below and send - it via Internet electronic mail to <IANA@IANA.ORG>. - -8.1 IANA registration form for address-type - - A registration for a DSN address-type MUST include the following - information: - -(a) The proposed address-type name. - -(b) The syntax for mailbox addresses of this type, specified using BNF, - regular expressions, ASN.1, or other non-ambiguous language. - -(c) If addresses of this type are not composed entirely of graphic - characters from the US-ASCII repertoire, a specification for how - they are to be encoded as graphic US-ASCII characters in a DSN - Original-Recipient or Final-Recipient DSN field. - -(d) [optional] A specification for how addresses of this type are to be - translated to and from Internet electronic mail addresses. - -8.2 IANA registration form for diagnostic-type - - A registration for a DSN address-type MUST include the following - information: - -(a) The proposed diagnostic-type name. - -(b) A description of the syntax to be used for expressing diagnostic - codes of this type as graphic characters from the US-ASCII - repertoire. - - - - -Moore & Vaudreuil Standards Track [Page 31] - -RFC 1894 Delivery Status Notifications January 1996 - - -(c) A list of valid diagnostic codes of this type and the meaning of - each code. - -(d) [optional] A specification for mapping from diagnostic codes of this - type to DSN status codes (as defined in [5]). - -8.3 IANA registration form for MTA-name-type - - A registration for a DSN MTA-name-type must include the following - information: - -(a) The proposed MTA-name-type name. - -(b) A description of the syntax of MTA names of this type, using BNF, - regular expressions, ASN.1, or other non-ambiguous language. - -(c) If MTA names of this type do not consist entirely of graphic - characters from the US-ASCII repertoire, a specification for how an - MTA name of this type should be expressed as a sequence of graphic - US-ASCII characters. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 32] - -RFC 1894 Delivery Status Notifications January 1996 - - -9. Appendix - Examples - - NOTE: These examples are provided as illustration only, and are not - considered part of the DSN protocol specification. If an example - conflicts with the protocol definition above, the example is wrong. - - Likewise, the use of *-type subfield names or extension fields in - these examples is not to be construed as a definition for those type - names or extension fields. - - These examples were manually translated from bounced messages using - whatever information was available. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 33] - -RFC 1894 Delivery Status Notifications January 1996 - - -9.1 This is a simple DSN issued after repeated attempts - to deliver a message failed. In this case, the DSN is - issued by the same MTA from which the message was originated. - - - Date: Thu, 7 Jul 1994 17:16:05 -0400 - From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU> - Message-Id: <199407072116.RAA14128@CS.UTK.EDU> - Subject: Returned mail: Cannot send message for 5 days - To: <owner-info-mime@cs.utk.edu> - MIME-Version: 1.0 - Content-Type: multipart/report; report-type=delivery-status; - boundary="RAA14128.773615765/CS.UTK.EDU" - - --RAA14128.773615765/CS.UTK.EDU - - The original message was received at Sat, 2 Jul 1994 17:10:28 -0400 - from root@localhost - - ----- The following addresses had delivery problems ----- - <louisl@larry.slip.umd.edu> (unrecoverable error) - - ----- Transcript of session follows ----- - <louisl@larry.slip.umd.edu>... Deferred: Connection timed out - with larry.slip.umd.edu. - Message could not be delivered for 5 days - Message will be deleted from queue - - --RAA14128.773615765/CS.UTK.EDU - content-type: message/delivery-status - - Reporting-MTA: dns; cs.utk.edu - - Original-Recipient: rfc822;louisl@larry.slip.umd.edu - Final-Recipient: rfc822;louisl@larry.slip.umd.edu - Action: failed - Status: 4.0.0 - Diagnostic-Code: smtp; 426 connection timed out - Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 - - --RAA14128.773615765/CS.UTK.EDU - content-type: message/rfc822 - - [original message goes here] - --RAA14128.773615765/CS.UTK.EDU-- - - - - - - -Moore & Vaudreuil Standards Track [Page 34] - -RFC 1894 Delivery Status Notifications January 1996 - - -9.2 This is another DSN issued by the sender's MTA, which - contains details of multiple delivery attempts. Some of - these were detected locally, and others by a remote MTA. - - - Date: Fri, 8 Jul 1994 09:21:47 -0400 - From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU> - Subject: Returned mail: User unknown - To: <owner-ups-mib@CS.UTK.EDU> - MIME-Version: 1.0 - Content-Type: multipart/report; report-type=delivery-status; - boundary="JAA13167.773673707/CS.UTK.EDU" - - --JAA13167.773673707/CS.UTK.EDU - content-type: text/plain; charset=us-ascii - - ----- The following addresses had delivery problems ----- - <arathib@vnet.ibm.com> (unrecoverable error) - <wsnell@sdcc13.ucsd.edu> (unrecoverable error) - - --JAA13167.773673707/CS.UTK.EDU - content-type: message/delivery-status - - Reporting-MTA: dns; cs.utk.edu - - Original-Recipient: rfc822;arathib@vnet.ibm.com - Final-Recipient: rfc822;arathib@vnet.ibm.com - Action: failed - Status: 5.0.0 (permanent failure) - Diagnostic-Code: smtp; - 550 'arathib@vnet.IBM.COM' is not a registered gateway user - Remote-MTA: dns; vnet.ibm.com - - Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com - Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com - Action: delayed - Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure) - - Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu - Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu - Action: failed - Status: 5.0.0 - Diagnostic-Code: smtp; 550 user unknown - Remote-MTA: dns; sdcc13.ucsd.edu - - --JAA13167.773673707/CS.UTK.EDU - content-type: message/rfc822 - - - - -Moore & Vaudreuil Standards Track [Page 35] - -RFC 1894 Delivery Status Notifications January 1996 - - - [original message goes here] - --JAA13167.773673707/CS.UTK.EDU-- - - -9.3 A delivery report generated by Message Router (MAILBUS) and - gatewayed by PMDF_MR to a DSN. In this case the gateway did not - have sufficient information to supply an original-recipient address. - - - - Disclose-recipients: prohibited - Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT) - From: Message Router Submission Agent <AMMGR@corp.timeplex.com> - Subject: Status of : Re: Battery current sense - To: owner-ups-mib@CS.UTK.EDU - Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com> - MIME-version: 1.0 - content-type: multipart/report; report-type=delivery-status; - boundary="84229080704991.122306.SYS30" - - --84229080704991.122306.SYS30 - content-type: text/plain - - Invalid address - nair_s - %DIR-E-NODIRMTCH, No matching Directory Entry found - - --84229080704991.122306.SYS30 - content-type: message/delivery-status - - Reporting-MTA: mailbus; SYS30 - - Final-Recipient: unknown; nair_s - Status: 5.0.0 (unknown permanent failure) - Action: failed - - --84229080704991.122306.SYS30-- - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 36] - -RFC 1894 Delivery Status Notifications January 1996 - - -9.4 A delay report from a multiprotocol MTA. Note that there is no - returned content, so no third body part appears in the DSN. - - From: <postmaster@nsfnet-relay.ac.uk> - Message-Id: <199407092338.TAA23293@CS.UTK.EDU> - Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk - id <g.12954-0@sun2.nsfnet-relay.ac.uk>; - Sun, 10 Jul 1994 00:36:51 +0100 - To: owner-info-mime@cs.utk.edu - Date: Sun, 10 Jul 1994 00:36:51 +0100 - Subject: WARNING: message delayed at "nsfnet-relay.ac.uk" - content-type: multipart/report; report-type=delivery-status; - boundary=foobar - - --foobar - content-type: text/plain - - The following message: - - UA-ID: Reliable PC (... - Q-ID: sun2.nsf:77/msg.11820-0 - - has not been delivered to the intended recipient: - - thomas@de-montfort.ac.uk - - despite repeated delivery attempts over the past 24 hours. - - The usual cause of this problem is that the remote system is - temporarily unavailable. - - Delivery will continue to be attempted up to a total elapsed - time of 168 hours, ie 7 days. - - You will be informed if delivery proves to be impossible - within this time. - - Please quote the Q-ID in any queries regarding this mail. - - --foobar - content-type: message/delivery-status - - Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk - - Final-Recipient: rfc822;thomas@de-montfort.ac.uk - Status: 4.0.0 (unknown temporary failure) - Action: delayed - - - - -Moore & Vaudreuil Standards Track [Page 37] - -RFC 1894 Delivery Status Notifications January 1996 - - - --foobar-- - -10. Acknowledgments - - The authors wish to thank the following people for their reviews of - earlier drafts of this document and their suggestions for - improvement: Eric Allman, Harald Alvestrand, Allan Cargille, Jim - Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko - Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark - Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory - Sheehan. - -11. References - -[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", - RFC 1521, Bellcore, Innosoft, September 1993. - -[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting - of Mail System Administrative Messages", RFC 1892, Octal Network - Services, January 1996. - -[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - USC/Information Sciences Institute, August 1982. - -[4] Moore, K., "SMTP Service Extension for Delivery Status - Notifications", RFC 1891, University of Tennessee, January 1996. - -[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octal - Network Services, January 1996. - -[6] Crocker, D., "Standard for the Format of ARPA Internet Text - Messages", STD 11, RFC 822, UDEL, August 1982. - -[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two: - Message Header Extensions for Non-Ascii Text", RFC 1522, University - of Tennessee, September 1993. - -[8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and - Support", STD 3, RFC 1123, USC/Information Sciences Institute, - October 1989. - -[9] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, BBN, - February 1988. - - - - - - - - -Moore & Vaudreuil Standards Track [Page 38] - -RFC 1894 Delivery Status Notifications January 1996 - - -11. Authors' Addresses - - Keith Moore - University of Tennessee - 107 Ayres Hall - Knoxville, TN 37996-1301 - USA - - EMail: moore@cs.utk.edu - Phone: +1 615 974 3126 - Fax: +1 615 974 8296 - - - Gregory M. Vaudreuil - Octel Network Services - 17080 Dallas Parkway - Dallas, TX 75248-1905 - USA - - EMail: Greg.Vaudreuil@Octel.Com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Moore & Vaudreuil Standards Track [Page 39] - diff --git a/RFC/rfc1938.txt b/RFC/rfc1938.txt deleted file mode 100644 index 5d3a9002..00000000 --- a/RFC/rfc1938.txt +++ /dev/null @@ -1,1011 +0,0 @@ - - - - - - -Network Working Group N. Haller -Request for Comments: 1938 Bellcore -Category: Standards Track C. Metz - Kaman Sciences Corporation - May 1996 - - - A One-Time Password System - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -1.0 ABSTRACT - - This document describes a one-time password authentication system - (OTP). The system provides authentication for system access (login) - and other applications requiring authentication that is secure - against passive attacks based on replaying captured reusable - passwords. OTP evolved from the S/KEY (S/KEY is a trademark of - Bellcore) One-Time Password System that was released by Bellcore and - is described in references [3] and [5]. - -2.0 OVERVIEW - - One form of attack on networked computing systems is eavesdropping on - network connections to obtain authentication information such as the - login IDs and passwords of legitimate users. Once this information is - captured, it can be used at a later time to gain access to the - system. One-time password systems are designed to counter this type - of attack, called a "replay attack" [4]. - - The authentication system described in this document uses a secret - pass-phrase to generate a sequence of one-time (single use) - passwords. With this system, the user's secret pass-phrase never - needs to cross the network at any time such as during authentication - or during pass-phrase changes. Thus, it is not vulnerable to replay - attacks. Added security is provided by the property that no secret - information need be stored on any system, including the server being - protected. - - The OTP system protects against external passive attacks against the - authentication subsystem. It does not prevent a network eavesdropper - from gaining access to private information and does not provide - - - -Haller & Metz Standards Track [Page 1] - -RFC 1938 A One-Time Password System May 1996 - - - protection against either "social engineering" or active attacks [9]. - -3.0 INTRODUCTION - - There are two entities in the operation of the OTP one-time password - system. The generator must produce the appropriate one-time password - from the user's secret pass-phrase and from information provided in - the challenge from the server. The server must send a challenge that - includes the appropriate generation parameters to the generator, must - verify the one-time password received, must store the last valid - one-time password it received, and must store the corresponding one- - time password sequence number. The server must also facilitate the - changing of the user's secret pass-phrase in a secure manner. - - The OTP system generator passes the user's secret pass-phrase, along - with a seed received from the server as part of the challenge, - through multiple iterations of a secure hash function to produce a - one-time password. After each successful authentication, the number - of secure hash function iterations is reduced by one. Thus, a unique - sequence of passwords is generated. The server verifies the one-time - password received from the generator by computing the secure hash - function once and comparing the result with the previously accepted - one-time password. This technique was first suggested by Leslie - Lamport [1]. - -4.0 REQUIREMENTS TERMINOLOGY - - In this document, the words that are used to define the significance - of each particular requirement are usually capitalized. These words - are: - - - MUST - - This word or the adjective "REQUIRED" means that the item is an - absolute requirement of the specification. - - - SHOULD - - This word or the adjective "RECOMMENDED" means that there might - exist valid reasons in particular circumstances to ignore this - item, but the full implications should be understood and the - case carefully weighed before taking a different course. - - - MAY - - This word or the adjective "OPTIONAL" means that this item is - truly optional. One vendor might choose to include the item - because a particular marketplace requires it or because it - - - -Haller & Metz Standards Track [Page 2] - -RFC 1938 A One-Time Password System May 1996 - - - enhances the product, for example; another vendor may omit the - same item. - -5.0 SECURE HASH FUNCTION - - The security of the OTP system is based on the non-invertability of a - secure hash function. Such a function must be tractable to compute in - the forward direction, but computationally infeasible to invert. - - The interfaces are currently defined for three such hash algorithms, - MD4 [2] and MD5 [6] by Ronald Rivest, and SHA [7] by NIST. All - conforming implementations of both server and generators MUST support - MD5. They SHOULD support SHA and MAY also support MD4. Clearly, the - generator and server must use the same algorithm in order to - interoperate. Other hash algorithms may be specified for use with - this system by publishing the appropriate interfaces. - - The secure hash algorithms listed above have the property that they - accept an input that is arbitrarily long and produce a fixed size - output. The OTP system folds this output to 64 bits using the - algorithms in the Appendix A. 64 bits is also the length of the one- - time passwords. This is believed to be long enough to be secure and - short enough to be entered manually (see below, Form of Output) when - necessary. - -6.0 GENERATION OF ONE-TIME PASSWORDS - - This section describes the generation of the one-time passwords. - This process consists of an initial step in which all inputs are - combined, a computation step where the secure hash function is - applied a specified number of times, and an output function where the - 64 bit one-time password is converted to a human readable form. - - Initial Step - - In principle, the user's secret pass-phrase may be of any length. - To reduce the risk from techniques such as exhaustive search or - dictionary attacks, character string pass-phrases MUST contain at - least 10 characters (see Form of Inputs below). All - implementations MUST support a pass-phrases of at least 63 - characters. The secret pass-phrase is frequently, but is not - required to be, textual information provided by a user. - - In this step, the pass phrase is concatenated with a seed that is - transmitted from the server in clear text. This non-secret seed - allows clients to use the same secret pass-phrase on multiple - machines (using different seeds) and to safely recycle their - secret pass-phrases by changing the seed. - - - -Haller & Metz Standards Track [Page 3] - -RFC 1938 A One-Time Password System May 1996 - - - The result of the concatenation is passed through the secure hash - function and then is reduced to 64 bits using one of the function - dependent algorithms shown in Appendix A. - - Computation Step - - A sequence of one-time passwords is produced by applying the - secure hash function multiple times to the output of the initial - step (called S). That is, the first one-time password to be used - is produced by passing S through the secure hash function a number - of times (N) specified by the user. The next one-time password to - be used is generated by passing S though the secure hash function - N-1 times. An eavesdropper who has monitored the transmission of a - one- time password would not be able to generate the next required - password because doing so would mean inverting the hash function. - - Form of Inputs - - The secret pass-phrase is seen only by the OTP generator. To allow - interchangeability of generators, all generators MUST support a - secret pass-phrase of 10 to 63 characters. Implementations MAY - support a longer pass-phrase, but such implementations risk the - loss of interchangeability with implementations supporting only - the minimum. - - The seed MUST consist of purely alphanumeric characters and MUST - be of one to 16 characters in length. The seed is a string of - characters that MUST not contain any blanks and SHOULD consist of - strictly alphanumeric characters from the ISO-646 Invariant Code - Set. The seed MUST be case insensitive and MUST be internally - converted to lower case before it is processed. - - The sequence number and seed together constitute a larger unit of - data called the challenge. The challenge gives the generator the - parameters it needs to calculate the correct one-time password - from the secret pass-phrase. The challenge MUST be in a standard - syntax so that automated generators can recognize the challenge in - context and extract these parameters. The syntax of the challenge - is: - - otp-<algorithm identifier> <sequence integer> <seed> - - The three tokens MUST be separated by a white space (defined as - any number of spaces and/or tabs) and the entire challenge string - MUST be terminated with either a space or a new line. The string - "otp-" MUST be in lower case. The algorithm identifier is case - sensitive (the existing identifiers are all lower case), and the - seed is case insensitive and converted before use to lower case. - - - -Haller & Metz Standards Track [Page 4] - -RFC 1938 A One-Time Password System May 1996 - - - If additional algorithms are defined, appropriate identifiers - (short, but not limited to three or four characters) must be - defined. The currently defined algorithm identifiers are: - - md4 MD4 Message Digest - md5 MD5 Message Digest - sha1 NIST Secure Hash Algorithm Revision 1 - - An example of an OTP challenge is: otp-md5 487 dog2 - - Form of Output - - The one-time password generated by the above procedure is 64 bits - in length. Entering a 64 bit number is a difficult and error prone - process. Some generators insert this password into the input - stream and some others make it available for system "cut and - paste." Still other arrangements require the one-time password to - be entered manually. The OTP system is designed to facilitate this - manual entry without impeding automatic methods. The one-time - password therefore MAY be converted to, and all servers MUST be - capable of accepting it as, a sequence of six short (1 to 4 - letter) easily typed words that only use characters from ISO-646 - IVCS. Each word is chosen from a dictionary of 2048 words; at 11 - bits per word, all one-time passwords may be encoded. - - The two extra bits in this encoding are used to store a checksum. - The 64 bits of key are broken down into pairs of bits, then these - pairs are summed together. The two least significant bits of this - sum are encoded in the last two bits of the six word sequence with - the least significant bit of the sum as the last bit encoded. All - OTP generators MUST calculate this checksum and all OTP servers - MUST verify this checksum explicitly as part of the operation of - decoding this representation of the one-time password. - - Generators that produce the six-word format MUST present the words - in upper case with single spaces used as separators. All servers - MUST accept six-word format without regard to case and white space - used as a separator. The two lines below represent the same one- - time password. The first is valid as output from a generator and - as input a server, the second is valid only as human input to a - server. - - OUST COAT FOAL MUG BEAK TOTE - oust coat foal mug beak tote - - Interoperability requires that all OTP servers and generators use - the same dictionary. The standard dictionary was originally - specified in the "S/KEY One Time Password System" that is - - - -Haller & Metz Standards Track [Page 5] - -RFC 1938 A One-Time Password System May 1996 - - - described in RFC 1760 [5]. This dictionary is included in this - document as Appendix C. - - To facilitate the implementation of smaller generators, - hexadecimal output is an acceptable alternative for the - presentation of the one-time password. All implementations of the - server software MUST accept case-insensitive hexadecimal as well - as six-word format. The hexadecimal digits may be separated by - white space so servers are REQUIRED to ignore all white space. If - the representation is partitioned by white space, leading zeros - must be retained. Examples of hexadecimal format are: - - Representation Value - - 3503785b369cda8b 0x3503785b369cda8b - e5cc a1b8 7c13 096b 0xe5cca1b87c13096b - C7 48 90 F4 27 7B A1 CF 0xc74890f4277ba1cf - 47 9 A68 28 4C 9D 0 1BC 0x479a68284c9d01bc - - In addition to accepting six-word and hexadecimal encodings of the - 64 bit one-time password, servers SHOULD accept the alternate - dictionary encoding described in Appendix B. The six words in - this encoding MUST not overlap the set of words in the standard - dictionary. To avoid ambiguity with the hexadecimal - representation, words in the alternate dictionary MUST not be - comprised solely of the letters A-F. Decoding words thus encoded - does not require any knowledge of the alternative dictionary used - so the acceptance of any alternate dictionary implies the - acceptance of all alternate dictionaries. Words in the - alternative dictionaries are case sensitive. Generators and - servers MUST preserve the case in the processing of these words. - - In summary, all conforming servers MUST accept six-word input that - uses the Standard Dictionary (RFC 1760 and Appendix C), MUST - accept hexadecimal encoding, and SHOULD accept six-word input that - uses the Alternative Dictionary technique (Appendix B). As there - is a remote possibility that a hexadecimal encoding of a one-time - password will look like a valid six-word standard dictionary - encoding, all implementations MUST use the following scheme. If a - six-word encoded one-time password is valid, it is accepted. - Otherwise, if the one-time password can be interpreted as - hexadecimal, and with that decoding it is valid, then it is - accepted. - - - - - - - - -Haller & Metz Standards Track [Page 6] - -RFC 1938 A One-Time Password System May 1996 - - -7.0 VERIFICATION OF ONE-TIME PASSWORDS - - An application on the server system that requires OTP authentication - is expected to issue an OTP challenge as described above. Given the - parameters from this challenge and the secret pass-phrase, the - generator can compute (or lookup) the one-time password that is - passed to the server to be verified. - - The server system has a database containing, for each user, the one- - time password from the last successful authentication or the first - OTP of a newly initialized sequence. To authenticate the user, the - server decodes the one-time password received from the generator into - a 64-bit key and then runs this key through the secure hash function - once. If the result of this operation matches the stored previous - OTP, the authentication is successful and the accepted one-time - password is stored for future use. - -8.0 PASS-PHRASE CHANGES - - Because the number of hash function applications executed by the - generator decreases by one each time, at some point the user must - reinitialize the system or be unable to authenticate. - - Although some installations may not permit users to initialize - remotely, implementations MUST provide a means to do so that does not - reveal the user's secret pass-phrase. One way is to provide a means - to reinitialize the sequence through explicit specification of the - first one-time password. - - When the sequence of one-time passwords is reinitialized, - implementations MUST verify that the seed or the pass-phrase is - changed. Installations SHOULD discourage any operation that sends - the secret pass-phrase over a network in clear-text as such practice - defeats the concept of a one-time password. - - Implementations MAY use the following technique for - [re]initialization: - - o The user picks a new seed and hash count (default values may - be offered). The user provides these, along with the - corresponding generated one-time password, to the host system. - - o The user MAY also provide the corresponding generated one - time password for count-1 as an error check. - - o The user SHOULD provide the generated one-time password for - the old seed and old hash count to protect an idle terminal - or workstation (this implies that when the count is 1, the - - - -Haller & Metz Standards Track [Page 7] - -RFC 1938 A One-Time Password System May 1996 - - - user can login but cannot then change the seed or count). - - In the future a specific protocol may be defined for reinitialization - that will permit smooth and possibly automated interoperation of all - hosts and generators. - -9.0 PROTECTION AGAINST RACE ATTACK - - All conforming server implementations MUST protect against the race - condition described in this section. A defense against this attack - is outlined; implementations MAY use this approach or MAY select an - alternative defense. - - It is possible for an attacker to listen to most of a one-time - password, guess the remainder, and then race the legitimate user to - complete the authentication. Multiple guesses against the last word - of the six-word format are likely to succeed. - - One possible defense is to prevent a user from starting multiple - simultaneous authentication sessions. This means that once the - legitimate user has initiated authentication, an attacker would be - blocked until the first authentication process has completed. In - this approach, a timeout is necessary to thwart a denial of service - attack. - -10.0 SECURITY CONSIDERATIONS - - This entire document discusses an authentication system that improves - security by limiting the danger of eavesdropping/replay attacks that - have been used against simple password systems [4]. - - The use of the OTP system only provides protections against passive - eavesdropping/replay attacks. It does not provide for the privacy of - transmitted data, and it does not provide protection against active - attacks. Active attacks against TCP connections are known to be - present in the current Internet [9]. - - The success of the OTP system to protect host systems is dependent on - the non-invertability of the secure hash functions used. To our - knowledge, none of the hash algorithms have been broken, but it is - generally believed [6] that MD4 is not as strong as MD5. If a server - supports multiple hash algorithms, it is only as secure as the - weakest algorithm. - - - - - - - - -Haller & Metz Standards Track [Page 8] - -RFC 1938 A One-Time Password System May 1996 - - -11.0 ACKNOWLEDGMENTS - - The idea behind OTP authentication was first proposed by Leslie - Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was - proposed by Phil Karn, who also wrote most of the Bellcore reference - implementation. - -12.0 REFERENCES - - [1] Leslie Lamport, "Password Authentication with Insecure - Communication", Communications of the ACM 24.11 (November - 1981), 770-772 - - [2] Rivest, R., "The MD4 Message-Digest Algorithm, RFC 1320", - MIT and RSA Data Security, Inc., April 1992. - - [3] Neil Haller, "The S/KEY One-Time Password System", Proceedings - of the ISOC Symposium on Network and Distributed System - Security, February 1994, San Diego, CA - - [4] Haller, N., and R. Atkinson, "On Internet Authentication", - RFC 1704, Bellcore and Naval Research Laboratory, October 1994. - - [5] Haller, N., "The S/KEY One-Time Password System", RFC 1760, - Bellcore, February 1995. - - [6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - MIT and RSA Data Security, Inc., April 1992. - - [7] National Institute of Standards and Technology (NIST), - "Announcing the Secure Hash Standard", FIPS 180-1, U.S. - Department of Commerce, April 1995. - - [8] International Standard - Information Processing -- ISO 7-bit - coded character set for information interchange (Invariant Code - Set), ISO-646, International Standards Organization, Geneva, - Switzerland, 1983 - - [9] Computer Emergency Response Team (CERT), "IP Spoofing and - Hijacked Terminal Connections", CA-95:01, January 1995. - Available via anonymous ftp from info.cert.org in - /pub/cert_advisories. - - - - - - - - - -Haller & Metz Standards Track [Page 9] - -RFC 1938 A One-Time Password System May 1996 - - -13.0 AUTHORS' ADDRESSES - - Neil Haller - Bellcore - MCC 1C-265B - 445 South Street - Morristown, NJ, 07960-6438, USA - - Phone: +1 201 829-4478 - Fax: +1 201 829-2504 - EMail: nmh@bellcore.com - - - Craig Metz - Kaman Sciences Corporation - For NRL Code 5544 - 4555 Overlook Avenue, S.W. - Washington, DC, 20375-5337, USA - - Phone: +1 202 404-7122 - Fax: +1 202 404-7942 - EMail: cmetz@cs.nrl.navy.mil - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Haller & Metz Standards Track [Page 10] - -RFC 1938 A One-Time Password System May 1996 - - -Appendix A - Interfaces to Secure Hash Algorithms - -MD4 Message Digest (see reference [2]) - - strcpy(buf,seed); - strcat(buf,passwd); - MDbegin(&md) - MDupdate(&md,(unsigned char *)buf,8*buflen); - - /* Fold result to 64 bits */ - md.buffer[0] ^= md.buffer[2]; - md.buffer[1] ^= md.buffer[3]; - - -MD5 Message Digest (see reference [6]) - - MD5_CTX mdCxt; - - strcpy(buf,seed); - strcat(buf,passwd); - - /* Crunch the key through MD5 */ - MD5Init(&mdCxt); - MD5Update(&mdCxt,(unsigned char *)bits,strlen(bits)); - MD5Update(&mdCxt,(unsigned char *)buf,buflen); - MD5Final(&mdCxt); - - /* Fold result to 64 bits */ - for( i = 0; i < 8; i++ ) - result[i] = mdCxt.digest[i] ^ mdCxt.digest[i+8]; - - -SHA Secure Hash Algorithm (see reference [7]) - - - /* Fold 160 bit result to 64 bits */ - md.buffer[0] ^= md.buffer[2]; - md.buffer[1] ^= md.buffer[3]; - md.buffer[0] ^= md.buffer[4]; - -Appendix B - Alternative Dictionary Algorithm - - The purpose of alternative dictionary encoding of the OTP one-time - password is to allow the use of language specific or friendly words. - As case translation is not always well defined, the alternative - dictionary encoding is case insensitive. Servers SHOULD accept this - encoding in addition to the standard 6-word and hexadecimal - encodings. - - - -Haller & Metz Standards Track [Page 11] - -RFC 1938 A One-Time Password System May 1996 - - -GENERATOR ENCODING USING AN ALTERNATE DICTIONARY - - The standard 6-word encoding uses the placement of a word in the - dictionary to represent an 11-bit number. The 64-bit one-time - password can then be represented by six words. - - An alternative dictionary of 2048 words may be created such that - each word W and position of the word in the dictionary N obey the - relationship: - - alg( W ) % 2048 == N - where - alg is the hash algorithm used (e.g. MD4, MD5, SHA1). - - In addition, no words in the standard dictionary may be chosen. - - The generator expands the 64-bit one-time password to 66 bits by - computing parity as with the standard 6-word encoding. The six 11- - bit numbers are then converted to words using the dictionary that - was created such that the above relationship holds. - - -SERVER DECODING OF ALTERNATE DICTIONARY ONE-TIME PASSWORDS - - The server accepting alternative dictionary encoding converts each - word to an 11-bit number using the above encoding. These numbers are - then used in the same way as the decoded standard dictionary words - to form the 66-bit one-time password. - - The server does not need to have access to the alternate dictionary - that was used to create the one-time password it is authenticating. - This is because the decoding from word to 11-bit number does not - make any use of the dictionary. As a result of the independence of - the dictionary, a server accepting one alternate dictionary accept - all alternate dictionaries. - -Appendix C - Dictionary for Converting Between 6-Word and Binary -Formats - - This dictionary is from the module put.c in the original Bellcore - reference distribution. - -{ "A", "ABE", "ACE", "ACT", "AD", "ADA", "ADD", -"AGO", "AID", "AIM", "AIR", "ALL", "ALP", "AM", "AMY", -"AN", "ANA", "AND", "ANN", "ANT", "ANY", "APE", "APS", -"APT", "ARC", "ARE", "ARK", "ARM", "ART", "AS", "ASH", -"ASK", "AT", "ATE", "AUG", "AUK", "AVE", "AWE", "AWK", -"AWL", "AWN", "AX", "AYE", "BAD", "BAG", "BAH", "BAM", - - - -Haller & Metz Standards Track [Page 12] - -RFC 1938 A One-Time Password System May 1996 - - -"BAN", "BAR", "BAT", "BAY", "BE", "BED", "BEE", "BEG", -"BEN", "BET", "BEY", "BIB", "BID", "BIG", "BIN", "BIT", -"BOB", "BOG", "BON", "BOO", "BOP", "BOW", "BOY", "BUB", -"BUD", "BUG", "BUM", "BUN", "BUS", "BUT", "BUY", "BY", -"BYE", "CAB", "CAL", "CAM", "CAN", "CAP", "CAR", "CAT", -"CAW", "COD", "COG", "COL", "CON", "COO", "COP", "COT", -"COW", "COY", "CRY", "CUB", "CUE", "CUP", "CUR", "CUT", -"DAB", "DAD", "DAM", "DAN", "DAR", "DAY", "DEE", "DEL", -"DEN", "DES", "DEW", "DID", "DIE", "DIG", "DIN", "DIP", -"DO", "DOE", "DOG", "DON", "DOT", "DOW", "DRY", "DUB", -"DUD", "DUE", "DUG", "DUN", "EAR", "EAT", "ED", "EEL", -"EGG", "EGO", "ELI", "ELK", "ELM", "ELY", "EM", "END", -"EST", "ETC", "EVA", "EVE", "EWE", "EYE", "FAD", "FAN", -"FAR", "FAT", "FAY", "FED", "FEE", "FEW", "FIB", "FIG", -"FIN", "FIR", "FIT", "FLO", "FLY", "FOE", "FOG", "FOR", -"FRY", "FUM", "FUN", "FUR", "GAB", "GAD", "GAG", "GAL", -"GAM", "GAP", "GAS", "GAY", "GEE", "GEL", "GEM", "GET", -"GIG", "GIL", "GIN", "GO", "GOT", "GUM", "GUN", "GUS", -"GUT", "GUY", "GYM", "GYP", "HA", "HAD", "HAL", "HAM", -"HAN", "HAP", "HAS", "HAT", "HAW", "HAY", "HE", "HEM", -"HEN", "HER", "HEW", "HEY", "HI", "HID", "HIM", "HIP", -"HIS", "HIT", "HO", "HOB", "HOC", "HOE", "HOG", "HOP", -"HOT", "HOW", "HUB", "HUE", "HUG", "HUH", "HUM", "HUT", -"I", "ICY", "IDA", "IF", "IKE", "ILL", "INK", "INN", -"IO", "ION", "IQ", "IRA", "IRE", "IRK", "IS", "IT", -"ITS", "IVY", "JAB", "JAG", "JAM", "JAN", "JAR", "JAW", -"JAY", "JET", "JIG", "JIM", "JO", "JOB", "JOE", "JOG", -"JOT", "JOY", "JUG", "JUT", "KAY", "KEG", "KEN", "KEY", -"KID", "KIM", "KIN", "KIT", "LA", "LAB", "LAC", "LAD", -"LAG", "LAM", "LAP", "LAW", "LAY", "LEA", "LED", "LEE", -"LEG", "LEN", "LEO", "LET", "LEW", "LID", "LIE", "LIN", -"LIP", "LIT", "LO", "LOB", "LOG", "LOP", "LOS", "LOT", -"LOU", "LOW", "LOY", "LUG", "LYE", "MA", "MAC", "MAD", -"MAE", "MAN", "MAO", "MAP", "MAT", "MAW", "MAY", "ME", -"MEG", "MEL", "MEN", "MET", "MEW", "MID", "MIN", "MIT", -"MOB", "MOD", "MOE", "MOO", "MOP", "MOS", "MOT", "MOW", -"MUD", "MUG", "MUM", "MY", "NAB", "NAG", "NAN", "NAP", -"NAT", "NAY", "NE", "NED", "NEE", "NET", "NEW", "NIB", -"NIL", "NIP", "NIT", "NO", "NOB", "NOD", "NON", "NOR", -"NOT", "NOV", "NOW", "NU", "NUN", "NUT", "O", "OAF", -"OAK", "OAR", "OAT", "ODD", "ODE", "OF", "OFF", "OFT", -"OH", "OIL", "OK", "OLD", "ON", "ONE", "OR", "ORB", -"ORE", "ORR", "OS", "OTT", "OUR", "OUT", "OVA", "OW", -"OWE", "OWL", "OWN", "OX", "PA", "PAD", "PAL", "PAM", -"PAN", "PAP", "PAR", "PAT", "PAW", "PAY", "PEA", "PEG", -"PEN", "PEP", "PER", "PET", "PEW", "PHI", "PI", "PIE", -"PIN", "PIT", "PLY", "PO", "POD", "POE", "POP", "POT", -"POW", "PRO", "PRY", "PUB", "PUG", "PUN", "PUP", "PUT", - - - -Haller & Metz Standards Track [Page 13] - -RFC 1938 A One-Time Password System May 1996 - - -"QUO", "RAG", "RAM", "RAN", "RAP", "RAT", "RAW", "RAY", -"REB", "RED", "REP", "RET", "RIB", "RID", "RIG", "RIM", -"RIO", "RIP", "ROB", "ROD", "ROE", "RON", "ROT", "ROW", -"ROY", "RUB", "RUE", "RUG", "RUM", "RUN", "RYE", "SAC", -"SAD", "SAG", "SAL", "SAM", "SAN", "SAP", "SAT", "SAW", -"SAY", "SEA", "SEC", "SEE", "SEN", "SET", "SEW", "SHE", -"SHY", "SIN", "SIP", "SIR", "SIS", "SIT", "SKI", "SKY", -"SLY", "SO", "SOB", "SOD", "SON", "SOP", "SOW", "SOY", -"SPA", "SPY", "SUB", "SUD", "SUE", "SUM", "SUN", "SUP", -"TAB", "TAD", "TAG", "TAN", "TAP", "TAR", "TEA", "TED", -"TEE", "TEN", "THE", "THY", "TIC", "TIE", "TIM", "TIN", -"TIP", "TO", "TOE", "TOG", "TOM", "TON", "TOO", "TOP", -"TOW", "TOY", "TRY", "TUB", "TUG", "TUM", "TUN", "TWO", -"UN", "UP", "US", "USE", "VAN", "VAT", "VET", "VIE", -"WAD", "WAG", "WAR", "WAS", "WAY", "WE", "WEB", "WED", -"WEE", "WET", "WHO", "WHY", "WIN", "WIT", "WOK", "WON", -"WOO", "WOW", "WRY", "WU", "YAM", "YAP", "YAW", "YE", -"YEA", "YES", "YET", "YOU", "ABED", "ABEL", "ABET", "ABLE", -"ABUT", "ACHE", "ACID", "ACME", "ACRE", "ACTA", "ACTS", "ADAM", -"ADDS", "ADEN", "AFAR", "AFRO", "AGEE", "AHEM", "AHOY", "AIDA", -"AIDE", "AIDS", "AIRY", "AJAR", "AKIN", "ALAN", "ALEC", "ALGA", -"ALIA", "ALLY", "ALMA", "ALOE", "ALSO", "ALTO", "ALUM", "ALVA", -"AMEN", "AMES", "AMID", "AMMO", "AMOK", "AMOS", "AMRA", "ANDY", -"ANEW", "ANNA", "ANNE", "ANTE", "ANTI", "AQUA", "ARAB", "ARCH", -"AREA", "ARGO", "ARID", "ARMY", "ARTS", "ARTY", "ASIA", "ASKS", -"ATOM", "AUNT", "AURA", "AUTO", "AVER", "AVID", "AVIS", "AVON", -"AVOW", "AWAY", "AWRY", "BABE", "BABY", "BACH", "BACK", "BADE", -"BAIL", "BAIT", "BAKE", "BALD", "BALE", "BALI", "BALK", "BALL", -"BALM", "BAND", "BANE", "BANG", "BANK", "BARB", "BARD", "BARE", -"BARK", "BARN", "BARR", "BASE", "BASH", "BASK", "BASS", "BATE", -"BATH", "BAWD", "BAWL", "BEAD", "BEAK", "BEAM", "BEAN", "BEAR", -"BEAT", "BEAU", "BECK", "BEEF", "BEEN", "BEER", "BEET", "BELA", -"BELL", "BELT", "BEND", "BENT", "BERG", "BERN", "BERT", "BESS", -"BEST", "BETA", "BETH", "BHOY", "BIAS", "BIDE", "BIEN", "BILE", -"BILK", "BILL", "BIND", "BING", "BIRD", "BITE", "BITS", "BLAB", -"BLAT", "BLED", "BLEW", "BLOB", "BLOC", "BLOT", "BLOW", "BLUE", -"BLUM", "BLUR", "BOAR", "BOAT", "BOCA", "BOCK", "BODE", "BODY", -"BOGY", "BOHR", "BOIL", "BOLD", "BOLO", "BOLT", "BOMB", "BONA", -"BOND", "BONE", "BONG", "BONN", "BONY", "BOOK", "BOOM", "BOON", -"BOOT", "BORE", "BORG", "BORN", "BOSE", "BOSS", "BOTH", "BOUT", -"BOWL", "BOYD", "BRAD", "BRAE", "BRAG", "BRAN", "BRAY", "BRED", -"BREW", "BRIG", "BRIM", "BROW", "BUCK", "BUDD", "BUFF", "BULB", -"BULK", "BULL", "BUNK", "BUNT", "BUOY", "BURG", "BURL", "BURN", -"BURR", "BURT", "BURY", "BUSH", "BUSS", "BUST", "BUSY", "BYTE", -"CADY", "CAFE", "CAGE", "CAIN", "CAKE", "CALF", "CALL", "CALM", -"CAME", "CANE", "CANT", "CARD", "CARE", "CARL", "CARR", "CART", -"CASE", "CASH", "CASK", "CAST", "CAVE", "CEIL", "CELL", "CENT", -"CERN", "CHAD", "CHAR", "CHAT", "CHAW", "CHEF", "CHEN", "CHEW", - - - -Haller & Metz Standards Track [Page 14] - -RFC 1938 A One-Time Password System May 1996 - - -"CHIC", "CHIN", "CHOU", "CHOW", "CHUB", "CHUG", "CHUM", "CITE", -"CITY", "CLAD", "CLAM", "CLAN", "CLAW", "CLAY", "CLOD", "CLOG", -"CLOT", "CLUB", "CLUE", "COAL", "COAT", "COCA", "COCK", "COCO", -"CODA", "CODE", "CODY", "COED", "COIL", "COIN", "COKE", "COLA", -"COLD", "COLT", "COMA", "COMB", "COME", "COOK", "COOL", "COON", -"COOT", "CORD", "CORE", "CORK", "CORN", "COST", "COVE", "COWL", -"CRAB", "CRAG", "CRAM", "CRAY", "CREW", "CRIB", "CROW", "CRUD", -"CUBA", "CUBE", "CUFF", "CULL", "CULT", "CUNY", "CURB", "CURD", -"CURE", "CURL", "CURT", "CUTS", "DADE", "DALE", "DAME", "DANA", -"DANE", "DANG", "DANK", "DARE", "DARK", "DARN", "DART", "DASH", -"DATA", "DATE", "DAVE", "DAVY", "DAWN", "DAYS", "DEAD", "DEAF", -"DEAL", "DEAN", "DEAR", "DEBT", "DECK", "DEED", "DEEM", "DEER", -"DEFT", "DEFY", "DELL", "DENT", "DENY", "DESK", "DIAL", "DICE", -"DIED", "DIET", "DIME", "DINE", "DING", "DINT", "DIRE", "DIRT", -"DISC", "DISH", "DISK", "DIVE", "DOCK", "DOES", "DOLE", "DOLL", -"DOLT", "DOME", "DONE", "DOOM", "DOOR", "DORA", "DOSE", "DOTE", -"DOUG", "DOUR", "DOVE", "DOWN", "DRAB", "DRAG", "DRAM", "DRAW", -"DREW", "DRUB", "DRUG", "DRUM", "DUAL", "DUCK", "DUCT", "DUEL", -"DUET", "DUKE", "DULL", "DUMB", "DUNE", "DUNK", "DUSK", "DUST", -"DUTY", "EACH", "EARL", "EARN", "EASE", "EAST", "EASY", "EBEN", -"ECHO", "EDDY", "EDEN", "EDGE", "EDGY", "EDIT", "EDNA", "EGAN", -"ELAN", "ELBA", "ELLA", "ELSE", "EMIL", "EMIT", "EMMA", "ENDS", -"ERIC", "EROS", "EVEN", "EVER", "EVIL", "EYED", "FACE", "FACT", -"FADE", "FAIL", "FAIN", "FAIR", "FAKE", "FALL", "FAME", "FANG", -"FARM", "FAST", "FATE", "FAWN", "FEAR", "FEAT", "FEED", "FEEL", -"FEET", "FELL", "FELT", "FEND", "FERN", "FEST", "FEUD", "FIEF", -"FIGS", "FILE", "FILL", "FILM", "FIND", "FINE", "FINK", "FIRE", -"FIRM", "FISH", "FISK", "FIST", "FITS", "FIVE", "FLAG", "FLAK", -"FLAM", "FLAT", "FLAW", "FLEA", "FLED", "FLEW", "FLIT", "FLOC", -"FLOG", "FLOW", "FLUB", "FLUE", "FOAL", "FOAM", "FOGY", "FOIL", -"FOLD", "FOLK", "FOND", "FONT", "FOOD", "FOOL", "FOOT", "FORD", -"FORE", "FORK", "FORM", "FORT", "FOSS", "FOUL", "FOUR", "FOWL", -"FRAU", "FRAY", "FRED", "FREE", "FRET", "FREY", "FROG", "FROM", -"FUEL", "FULL", "FUME", "FUND", "FUNK", "FURY", "FUSE", "FUSS", -"GAFF", "GAGE", "GAIL", "GAIN", "GAIT", "GALA", "GALE", "GALL", -"GALT", "GAME", "GANG", "GARB", "GARY", "GASH", "GATE", "GAUL", -"GAUR", "GAVE", "GAWK", "GEAR", "GELD", "GENE", "GENT", "GERM", -"GETS", "GIBE", "GIFT", "GILD", "GILL", "GILT", "GINA", "GIRD", -"GIRL", "GIST", "GIVE", "GLAD", "GLEE", "GLEN", "GLIB", "GLOB", -"GLOM", "GLOW", "GLUE", "GLUM", "GLUT", "GOAD", "GOAL", "GOAT", -"GOER", "GOES", "GOLD", "GOLF", "GONE", "GONG", "GOOD", "GOOF", -"GORE", "GORY", "GOSH", "GOUT", "GOWN", "GRAB", "GRAD", "GRAY", -"GREG", "GREW", "GREY", "GRID", "GRIM", "GRIN", "GRIT", "GROW", -"GRUB", "GULF", "GULL", "GUNK", "GURU", "GUSH", "GUST", "GWEN", -"GWYN", "HAAG", "HAAS", "HACK", "HAIL", "HAIR", "HALE", "HALF", -"HALL", "HALO", "HALT", "HAND", "HANG", "HANK", "HANS", "HARD", -"HARK", "HARM", "HART", "HASH", "HAST", "HATE", "HATH", "HAUL", -"HAVE", "HAWK", "HAYS", "HEAD", "HEAL", "HEAR", "HEAT", "HEBE", - - - -Haller & Metz Standards Track [Page 15] - -RFC 1938 A One-Time Password System May 1996 - - -"HECK", "HEED", "HEEL", "HEFT", "HELD", "HELL", "HELM", "HERB", -"HERD", "HERE", "HERO", "HERS", "HESS", "HEWN", "HICK", "HIDE", -"HIGH", "HIKE", "HILL", "HILT", "HIND", "HINT", "HIRE", "HISS", -"HIVE", "HOBO", "HOCK", "HOFF", "HOLD", "HOLE", "HOLM", "HOLT", -"HOME", "HONE", "HONK", "HOOD", "HOOF", "HOOK", "HOOT", "HORN", -"HOSE", "HOST", "HOUR", "HOVE", "HOWE", "HOWL", "HOYT", "HUCK", -"HUED", "HUFF", "HUGE", "HUGH", "HUGO", "HULK", "HULL", "HUNK", -"HUNT", "HURD", "HURL", "HURT", "HUSH", "HYDE", "HYMN", "IBIS", -"ICON", "IDEA", "IDLE", "IFFY", "INCA", "INCH", "INTO", "IONS", -"IOTA", "IOWA", "IRIS", "IRMA", "IRON", "ISLE", "ITCH", "ITEM", -"IVAN", "JACK", "JADE", "JAIL", "JAKE", "JANE", "JAVA", "JEAN", -"JEFF", "JERK", "JESS", "JEST", "JIBE", "JILL", "JILT", "JIVE", -"JOAN", "JOBS", "JOCK", "JOEL", "JOEY", "JOHN", "JOIN", "JOKE", -"JOLT", "JOVE", "JUDD", "JUDE", "JUDO", "JUDY", "JUJU", "JUKE", -"JULY", "JUNE", "JUNK", "JUNO", "JURY", "JUST", "JUTE", "KAHN", -"KALE", "KANE", "KANT", "KARL", "KATE", "KEEL", "KEEN", "KENO", -"KENT", "KERN", "KERR", "KEYS", "KICK", "KILL", "KIND", "KING", -"KIRK", "KISS", "KITE", "KLAN", "KNEE", "KNEW", "KNIT", "KNOB", -"KNOT", "KNOW", "KOCH", "KONG", "KUDO", "KURD", "KURT", "KYLE", -"LACE", "LACK", "LACY", "LADY", "LAID", "LAIN", "LAIR", "LAKE", -"LAMB", "LAME", "LAND", "LANE", "LANG", "LARD", "LARK", "LASS", -"LAST", "LATE", "LAUD", "LAVA", "LAWN", "LAWS", "LAYS", "LEAD", -"LEAF", "LEAK", "LEAN", "LEAR", "LEEK", "LEER", "LEFT", "LEND", -"LENS", "LENT", "LEON", "LESK", "LESS", "LEST", "LETS", "LIAR", -"LICE", "LICK", "LIED", "LIEN", "LIES", "LIEU", "LIFE", "LIFT", -"LIKE", "LILA", "LILT", "LILY", "LIMA", "LIMB", "LIME", "LIND", -"LINE", "LINK", "LINT", "LION", "LISA", "LIST", "LIVE", "LOAD", -"LOAF", "LOAM", "LOAN", "LOCK", "LOFT", "LOGE", "LOIS", "LOLA", -"LONE", "LONG", "LOOK", "LOON", "LOOT", "LORD", "LORE", "LOSE", -"LOSS", "LOST", "LOUD", "LOVE", "LOWE", "LUCK", "LUCY", "LUGE", -"LUKE", "LULU", "LUND", "LUNG", "LURA", "LURE", "LURK", "LUSH", -"LUST", "LYLE", "LYNN", "LYON", "LYRA", "MACE", "MADE", "MAGI", -"MAID", "MAIL", "MAIN", "MAKE", "MALE", "MALI", "MALL", "MALT", -"MANA", "MANN", "MANY", "MARC", "MARE", "MARK", "MARS", "MART", -"MARY", "MASH", "MASK", "MASS", "MAST", "MATE", "MATH", "MAUL", -"MAYO", "MEAD", "MEAL", "MEAN", "MEAT", "MEEK", "MEET", "MELD", -"MELT", "MEMO", "MEND", "MENU", "MERT", "MESH", "MESS", "MICE", -"MIKE", "MILD", "MILE", "MILK", "MILL", "MILT", "MIMI", "MIND", -"MINE", "MINI", "MINK", "MINT", "MIRE", "MISS", "MIST", "MITE", -"MITT", "MOAN", "MOAT", "MOCK", "MODE", "MOLD", "MOLE", "MOLL", -"MOLT", "MONA", "MONK", "MONT", "MOOD", "MOON", "MOOR", "MOOT", -"MORE", "MORN", "MORT", "MOSS", "MOST", "MOTH", "MOVE", "MUCH", -"MUCK", "MUDD", "MUFF", "MULE", "MULL", "MURK", "MUSH", "MUST", -"MUTE", "MUTT", "MYRA", "MYTH", "NAGY", "NAIL", "NAIR", "NAME", -"NARY", "NASH", "NAVE", "NAVY", "NEAL", "NEAR", "NEAT", "NECK", -"NEED", "NEIL", "NELL", "NEON", "NERO", "NESS", "NEST", "NEWS", -"NEWT", "NIBS", "NICE", "NICK", "NILE", "NINA", "NINE", "NOAH", -"NODE", "NOEL", "NOLL", "NONE", "NOOK", "NOON", "NORM", "NOSE", - - - -Haller & Metz Standards Track [Page 16] - -RFC 1938 A One-Time Password System May 1996 - - -"NOTE", "NOUN", "NOVA", "NUDE", "NULL", "NUMB", "OATH", "OBEY", -"OBOE", "ODIN", "OHIO", "OILY", "OINT", "OKAY", "OLAF", "OLDY", -"OLGA", "OLIN", "OMAN", "OMEN", "OMIT", "ONCE", "ONES", "ONLY", -"ONTO", "ONUS", "ORAL", "ORGY", "OSLO", "OTIS", "OTTO", "OUCH", -"OUST", "OUTS", "OVAL", "OVEN", "OVER", "OWLY", "OWNS", "QUAD", -"QUIT", "QUOD", "RACE", "RACK", "RACY", "RAFT", "RAGE", "RAID", -"RAIL", "RAIN", "RAKE", "RANK", "RANT", "RARE", "RASH", "RATE", -"RAVE", "RAYS", "READ", "REAL", "REAM", "REAR", "RECK", "REED", -"REEF", "REEK", "REEL", "REID", "REIN", "RENA", "REND", "RENT", -"REST", "RICE", "RICH", "RICK", "RIDE", "RIFT", "RILL", "RIME", -"RING", "RINK", "RISE", "RISK", "RITE", "ROAD", "ROAM", "ROAR", -"ROBE", "ROCK", "RODE", "ROIL", "ROLL", "ROME", "ROOD", "ROOF", -"ROOK", "ROOM", "ROOT", "ROSA", "ROSE", "ROSS", "ROSY", "ROTH", -"ROUT", "ROVE", "ROWE", "ROWS", "RUBE", "RUBY", "RUDE", "RUDY", -"RUIN", "RULE", "RUNG", "RUNS", "RUNT", "RUSE", "RUSH", "RUSK", -"RUSS", "RUST", "RUTH", "SACK", "SAFE", "SAGE", "SAID", "SAIL", -"SALE", "SALK", "SALT", "SAME", "SAND", "SANE", "SANG", "SANK", -"SARA", "SAUL", "SAVE", "SAYS", "SCAN", "SCAR", "SCAT", "SCOT", -"SEAL", "SEAM", "SEAR", "SEAT", "SEED", "SEEK", "SEEM", "SEEN", -"SEES", "SELF", "SELL", "SEND", "SENT", "SETS", "SEWN", "SHAG", -"SHAM", "SHAW", "SHAY", "SHED", "SHIM", "SHIN", "SHOD", "SHOE", -"SHOT", "SHOW", "SHUN", "SHUT", "SICK", "SIDE", "SIFT", "SIGH", -"SIGN", "SILK", "SILL", "SILO", "SILT", "SINE", "SING", "SINK", -"SIRE", "SITE", "SITS", "SITU", "SKAT", "SKEW", "SKID", "SKIM", -"SKIN", "SKIT", "SLAB", "SLAM", "SLAT", "SLAY", "SLED", "SLEW", -"SLID", "SLIM", "SLIT", "SLOB", "SLOG", "SLOT", "SLOW", "SLUG", -"SLUM", "SLUR", "SMOG", "SMUG", "SNAG", "SNOB", "SNOW", "SNUB", -"SNUG", "SOAK", "SOAR", "SOCK", "SODA", "SOFA", "SOFT", "SOIL", -"SOLD", "SOME", "SONG", "SOON", "SOOT", "SORE", "SORT", "SOUL", -"SOUR", "SOWN", "STAB", "STAG", "STAN", "STAR", "STAY", "STEM", -"STEW", "STIR", "STOW", "STUB", "STUN", "SUCH", "SUDS", "SUIT", -"SULK", "SUMS", "SUNG", "SUNK", "SURE", "SURF", "SWAB", "SWAG", -"SWAM", "SWAN", "SWAT", "SWAY", "SWIM", "SWUM", "TACK", "TACT", -"TAIL", "TAKE", "TALE", "TALK", "TALL", "TANK", "TASK", "TATE", -"TAUT", "TEAL", "TEAM", "TEAR", "TECH", "TEEM", "TEEN", "TEET", -"TELL", "TEND", "TENT", "TERM", "TERN", "TESS", "TEST", "THAN", -"THAT", "THEE", "THEM", "THEN", "THEY", "THIN", "THIS", "THUD", -"THUG", "TICK", "TIDE", "TIDY", "TIED", "TIER", "TILE", "TILL", -"TILT", "TIME", "TINA", "TINE", "TINT", "TINY", "TIRE", "TOAD", -"TOGO", "TOIL", "TOLD", "TOLL", "TONE", "TONG", "TONY", "TOOK", -"TOOL", "TOOT", "TORE", "TORN", "TOTE", "TOUR", "TOUT", "TOWN", -"TRAG", "TRAM", "TRAY", "TREE", "TREK", "TRIG", "TRIM", "TRIO", -"TROD", "TROT", "TROY", "TRUE", "TUBA", "TUBE", "TUCK", "TUFT", -"TUNA", "TUNE", "TUNG", "TURF", "TURN", "TUSK", "TWIG", "TWIN", -"TWIT", "ULAN", "UNIT", "URGE", "USED", "USER", "USES", "UTAH", -"VAIL", "VAIN", "VALE", "VARY", "VASE", "VAST", "VEAL", "VEDA", -"VEIL", "VEIN", "VEND", "VENT", "VERB", "VERY", "VETO", "VICE", -"VIEW", "VINE", "VISE", "VOID", "VOLT", "VOTE", "WACK", "WADE", - - - -Haller & Metz Standards Track [Page 17] - -RFC 1938 A One-Time Password System May 1996 - - -"WAGE", "WAIL", "WAIT", "WAKE", "WALE", "WALK", "WALL", "WALT", -"WAND", "WANE", "WANG", "WANT", "WARD", "WARM", "WARN", "WART", -"WASH", "WAST", "WATS", "WATT", "WAVE", "WAVY", "WAYS", "WEAK", -"WEAL", "WEAN", "WEAR", "WEED", "WEEK", "WEIR", "WELD", "WELL", -"WELT", "WENT", "WERE", "WERT", "WEST", "WHAM", "WHAT", "WHEE", -"WHEN", "WHET", "WHOA", "WHOM", "WICK", "WIFE", "WILD", "WILL", -"WIND", "WINE", "WING", "WINK", "WINO", "WIRE", "WISE", "WISH", -"WITH", "WOLF", "WONT", "WOOD", "WOOL", "WORD", "WORE", "WORK", -"WORM", "WORN", "WOVE", "WRIT", "WYNN", "YALE", "YANG", "YANK", -"YARD", "YARN", "YAWL", "YAWN", "YEAH", "YEAR", "YELL", "YOGA", -"YOKE" }; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Haller & Metz Standards Track [Page 18] - diff --git a/RFC/rfc1939.txt b/RFC/rfc1939.txt deleted file mode 100644 index b11350e9..00000000 --- a/RFC/rfc1939.txt +++ /dev/null @@ -1,1291 +0,0 @@ - - - - - - -Network Working Group J. Myers -Request for Comments: 1939 Carnegie Mellon -STD: 53 M. Rose -Obsoletes: 1725 Dover Beach Consulting, Inc. -Category: Standards Track May 1996 - - - Post Office Protocol - Version 3 - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Table of Contents - - 1. Introduction ................................................ 2 - 2. A Short Digression .......................................... 2 - 3. Basic Operation ............................................. 3 - 4. The AUTHORIZATION State ..................................... 4 - QUIT Command ................................................ 5 - 5. The TRANSACTION State ....................................... 5 - STAT Command ................................................ 6 - LIST Command ................................................ 6 - RETR Command ................................................ 8 - DELE Command ................................................ 8 - NOOP Command ................................................ 9 - RSET Command ................................................ 9 - 6. The UPDATE State ............................................ 10 - QUIT Command ................................................ 10 - 7. Optional POP3 Commands ...................................... 11 - TOP Command ................................................. 11 - UIDL Command ................................................ 12 - USER Command ................................................ 13 - PASS Command ................................................ 14 - APOP Command ................................................ 15 - 8. Scaling and Operational Considerations ...................... 16 - 9. POP3 Command Summary ........................................ 18 - 10. Example POP3 Session ....................................... 19 - 11. Message Format ............................................. 19 - 12. References ................................................. 20 - 13. Security Considerations .................................... 20 - 14. Acknowledgements ........................................... 20 - 15. Authors' Addresses ......................................... 21 - Appendix A. Differences from RFC 1725 .......................... 22 - - - -Myers & Rose Standards Track [Page 1] - -RFC 1939 POP3 May 1996 - - - Appendix B. Command Index ...................................... 23 - -1. Introduction - - On certain types of smaller nodes in the Internet it is often - impractical to maintain a message transport system (MTS). For - example, a workstation may not have sufficient resources (cycles, - disk space) in order to permit a SMTP server [RFC821] and associated - local mail delivery system to be kept resident and continuously - running. Similarly, it may be expensive (or impossible) to keep a - personal computer interconnected to an IP-style network for long - amounts of time (the node is lacking the resource known as - "connectivity"). - - Despite this, it is often very useful to be able to manage mail on - these smaller nodes, and they often support a user agent (UA) to aid - the tasks of mail handling. To solve this problem, a node which can - support an MTS entity offers a maildrop service to these less endowed - nodes. The Post Office Protocol - Version 3 (POP3) is intended to - permit a workstation to dynamically access a maildrop on a server - host in a useful fashion. Usually, this means that the POP3 protocol - is used to allow a workstation to retrieve mail that the server is - holding for it. - - POP3 is not intended to provide extensive manipulation operations of - mail on the server; normally, mail is downloaded and then deleted. A - more advanced (and complex) protocol, IMAP4, is discussed in - [RFC1730]. - - For the remainder of this memo, the term "client host" refers to a - host making use of the POP3 service, while the term "server host" - refers to a host which offers the POP3 service. - -2. A Short Digression - - This memo does not specify how a client host enters mail into the - transport system, although a method consistent with the philosophy of - this memo is presented here: - - When the user agent on a client host wishes to enter a message - into the transport system, it establishes an SMTP connection to - its relay host and sends all mail to it. This relay host could - be, but need not be, the POP3 server host for the client host. Of - course, the relay host must accept mail for delivery to arbitrary - recipient addresses, that functionality is not required of all - SMTP servers. - - - - - -Myers & Rose Standards Track [Page 2] - -RFC 1939 POP3 May 1996 - - -3. Basic Operation - - Initially, the server host starts the POP3 service by listening on - TCP port 110. When a client host wishes to make use of the service, - it establishes a TCP connection with the server host. When the - connection is established, the POP3 server sends a greeting. The - client and POP3 server then exchange commands and responses - (respectively) until the connection is closed or aborted. - - Commands in the POP3 consist of a case-insensitive keyword, possibly - followed by one or more arguments. All commands are terminated by a - CRLF pair. Keywords and arguments consist of printable ASCII - characters. Keywords and arguments are each separated by a single - SPACE character. Keywords are three or four characters long. Each - argument may be up to 40 characters long. - - Responses in the POP3 consist of a status indicator and a keyword - possibly followed by additional information. All responses are - terminated by a CRLF pair. Responses may be up to 512 characters - long, including the terminating CRLF. There are currently two status - indicators: positive ("+OK") and negative ("-ERR"). Servers MUST - send the "+OK" and "-ERR" in upper case. - - Responses to certain commands are multi-line. In these cases, which - are clearly indicated below, after sending the first line of the - response and a CRLF, any additional lines are sent, each terminated - by a CRLF pair. When all lines of the response have been sent, a - final line is sent, consisting of a termination octet (decimal code - 046, ".") and a CRLF pair. If any line of the multi-line response - begins with the termination octet, the line is "byte-stuffed" by - pre-pending the termination octet to that line of the response. - Hence a multi-line response is terminated with the five octets - "CRLF.CRLF". When examining a multi-line response, the client checks - to see if the line begins with the termination octet. If so and if - octets other than CRLF follow, the first octet of the line (the - termination octet) is stripped away. If so and if CRLF immediately - follows the termination character, then the response from the POP - server is ended and the line containing ".CRLF" is not considered - part of the multi-line response. - - A POP3 session progresses through a number of states during its - lifetime. Once the TCP connection has been opened and the POP3 - server has sent the greeting, the session enters the AUTHORIZATION - state. In this state, the client must identify itself to the POP3 - server. Once the client has successfully done this, the server - acquires resources associated with the client's maildrop, and the - session enters the TRANSACTION state. In this state, the client - requests actions on the part of the POP3 server. When the client has - - - -Myers & Rose Standards Track [Page 3] - -RFC 1939 POP3 May 1996 - - - issued the QUIT command, the session enters the UPDATE state. In - this state, the POP3 server releases any resources acquired during - the TRANSACTION state and says goodbye. The TCP connection is then - closed. - - A server MUST respond to an unrecognized, unimplemented, or - syntactically invalid command by responding with a negative status - indicator. A server MUST respond to a command issued when the - session is in an incorrect state by responding with a negative status - indicator. There is no general method for a client to distinguish - between a server which does not implement an optional command and a - server which is unwilling or unable to process the command. - - A POP3 server MAY have an inactivity autologout timer. Such a timer - MUST be of at least 10 minutes' duration. The receipt of any command - from the client during that interval should suffice to reset the - autologout timer. When the timer expires, the session does NOT enter - the UPDATE state--the server should close the TCP connection without - removing any messages or sending any response to the client. - -4. The AUTHORIZATION State - - Once the TCP connection has been opened by a POP3 client, the POP3 - server issues a one line greeting. This can be any positive - response. An example might be: - - S: +OK POP3 server ready - - The POP3 session is now in the AUTHORIZATION state. The client must - now identify and authenticate itself to the POP3 server. Two - possible mechanisms for doing this are described in this document, - the USER and PASS command combination and the APOP command. Both - mechanisms are described later in this document. Additional - authentication mechanisms are described in [RFC1734]. While there is - no single authentication mechanism that is required of all POP3 - servers, a POP3 server must of course support at least one - authentication mechanism. - - Once the POP3 server has determined through the use of any - authentication command that the client should be given access to the - appropriate maildrop, the POP3 server then acquires an exclusive- - access lock on the maildrop, as necessary to prevent messages from - being modified or removed before the session enters the UPDATE state. - If the lock is successfully acquired, the POP3 server responds with a - positive status indicator. The POP3 session now enters the - TRANSACTION state, with no messages marked as deleted. If the - maildrop cannot be opened for some reason (for example, a lock can - not be acquired, the client is denied access to the appropriate - - - -Myers & Rose Standards Track [Page 4] - -RFC 1939 POP3 May 1996 - - - maildrop, or the maildrop cannot be parsed), the POP3 server responds - with a negative status indicator. (If a lock was acquired but the - POP3 server intends to respond with a negative status indicator, the - POP3 server must release the lock prior to rejecting the command.) - After returning a negative status indicator, the server may close the - connection. If the server does not close the connection, the client - may either issue a new authentication command and start again, or the - client may issue the QUIT command. - - After the POP3 server has opened the maildrop, it assigns a message- - number to each message, and notes the size of each message in octets. - The first message in the maildrop is assigned a message-number of - "1", the second is assigned "2", and so on, so that the nth message - in a maildrop is assigned a message-number of "n". In POP3 commands - and responses, all message-numbers and message sizes are expressed in - base-10 (i.e., decimal). - - Here is the summary for the QUIT command when used in the - AUTHORIZATION state: - - QUIT - - Arguments: none - - Restrictions: none - - Possible Responses: - +OK - - Examples: - C: QUIT - S: +OK dewey POP3 server signing off - -5. The TRANSACTION State - - Once the client has successfully identified itself to the POP3 server - and the POP3 server has locked and opened the appropriate maildrop, - the POP3 session is now in the TRANSACTION state. The client may now - issue any of the following POP3 commands repeatedly. After each - command, the POP3 server issues a response. Eventually, the client - issues the QUIT command and the POP3 session enters the UPDATE state. - - - - - - - - - - -Myers & Rose Standards Track [Page 5] - -RFC 1939 POP3 May 1996 - - - Here are the POP3 commands valid in the TRANSACTION state: - - STAT - - Arguments: none - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - The POP3 server issues a positive response with a line - containing information for the maildrop. This line is - called a "drop listing" for that maildrop. - - In order to simplify parsing, all POP3 servers are - required to use a certain format for drop listings. The - positive response consists of "+OK" followed by a single - space, the number of messages in the maildrop, a single - space, and the size of the maildrop in octets. This memo - makes no requirement on what follows the maildrop size. - Minimal implementations should just end that line of the - response with a CRLF pair. More advanced implementations - may include other information. - - NOTE: This memo STRONGLY discourages implementations - from supplying additional information in the drop - listing. Other, optional, facilities are discussed - later on which permit the client to parse the messages - in the maildrop. - - Note that messages marked as deleted are not counted in - either total. - - Possible Responses: - +OK nn mm - - Examples: - C: STAT - S: +OK 2 320 - - - LIST [msg] - - Arguments: - a message-number (optional), which, if present, may NOT - refer to a message marked as deleted - - - - - -Myers & Rose Standards Track [Page 6] - -RFC 1939 POP3 May 1996 - - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - If an argument was given and the POP3 server issues a - positive response with a line containing information for - that message. This line is called a "scan listing" for - that message. - - If no argument was given and the POP3 server issues a - positive response, then the response given is multi-line. - After the initial +OK, for each message in the maildrop, - the POP3 server responds with a line containing - information for that message. This line is also called a - "scan listing" for that message. If there are no - messages in the maildrop, then the POP3 server responds - with no scan listings--it issues a positive response - followed by a line containing a termination octet and a - CRLF pair. - - In order to simplify parsing, all POP3 servers are - required to use a certain format for scan listings. A - scan listing consists of the message-number of the - message, followed by a single space and the exact size of - the message in octets. Methods for calculating the exact - size of the message are described in the "Message Format" - section below. This memo makes no requirement on what - follows the message size in the scan listing. Minimal - implementations should just end that line of the response - with a CRLF pair. More advanced implementations may - include other information, as parsed from the message. - - NOTE: This memo STRONGLY discourages implementations - from supplying additional information in the scan - listing. Other, optional, facilities are discussed - later on which permit the client to parse the messages - in the maildrop. - - Note that messages marked as deleted are not listed. - - Possible Responses: - +OK scan listing follows - -ERR no such message - - Examples: - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - - - -Myers & Rose Standards Track [Page 7] - -RFC 1939 POP3 May 1996 - - - S: 2 200 - S: . - ... - C: LIST 2 - S: +OK 2 200 - ... - C: LIST 3 - S: -ERR no such message, only 2 messages in maildrop - - - RETR msg - - Arguments: - a message-number (required) which may NOT refer to a - message marked as deleted - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - If the POP3 server issues a positive response, then the - response given is multi-line. After the initial +OK, the - POP3 server sends the message corresponding to the given - message-number, being careful to byte-stuff the termination - character (as with all multi-line responses). - - Possible Responses: - +OK message follows - -ERR no such message - - Examples: - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends the entire message here> - S: . - - - DELE msg - - Arguments: - a message-number (required) which may NOT refer to a - message marked as deleted - - Restrictions: - may only be given in the TRANSACTION state - - - - - - -Myers & Rose Standards Track [Page 8] - -RFC 1939 POP3 May 1996 - - - Discussion: - The POP3 server marks the message as deleted. Any future - reference to the message-number associated with the message - in a POP3 command generates an error. The POP3 server does - not actually delete the message until the POP3 session - enters the UPDATE state. - - Possible Responses: - +OK message deleted - -ERR no such message - - Examples: - C: DELE 1 - S: +OK message 1 deleted - ... - C: DELE 2 - S: -ERR message 2 already deleted - - - NOOP - - Arguments: none - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - The POP3 server does nothing, it merely replies with a - positive response. - - Possible Responses: - +OK - - Examples: - C: NOOP - S: +OK - - - RSET - - Arguments: none - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - If any messages have been marked as deleted by the POP3 - server, they are unmarked. The POP3 server then replies - - - -Myers & Rose Standards Track [Page 9] - -RFC 1939 POP3 May 1996 - - - with a positive response. - - Possible Responses: - +OK - - Examples: - C: RSET - S: +OK maildrop has 2 messages (320 octets) - -6. The UPDATE State - - When the client issues the QUIT command from the TRANSACTION state, - the POP3 session enters the UPDATE state. (Note that if the client - issues the QUIT command from the AUTHORIZATION state, the POP3 - session terminates but does NOT enter the UPDATE state.) - - If a session terminates for some reason other than a client-issued - QUIT command, the POP3 session does NOT enter the UPDATE state and - MUST not remove any messages from the maildrop. - - QUIT - - Arguments: none - - Restrictions: none - - Discussion: - The POP3 server removes all messages marked as deleted - from the maildrop and replies as to the status of this - operation. If there is an error, such as a resource - shortage, encountered while removing messages, the - maildrop may result in having some or none of the messages - marked as deleted be removed. In no case may the server - remove any messages not marked as deleted. - - Whether the removal was successful or not, the server - then releases any exclusive-access lock on the maildrop - and closes the TCP connection. - - Possible Responses: - +OK - -ERR some deleted messages not removed - - Examples: - C: QUIT - S: +OK dewey POP3 server signing off (maildrop empty) - ... - C: QUIT - - - -Myers & Rose Standards Track [Page 10] - -RFC 1939 POP3 May 1996 - - - S: +OK dewey POP3 server signing off (2 messages left) - ... - -7. Optional POP3 Commands - - The POP3 commands discussed above must be supported by all minimal - implementations of POP3 servers. - - The optional POP3 commands described below permit a POP3 client - greater freedom in message handling, while preserving a simple POP3 - server implementation. - - NOTE: This memo STRONGLY encourages implementations to support - these commands in lieu of developing augmented drop and scan - listings. In short, the philosophy of this memo is to put - intelligence in the part of the POP3 client and not the POP3 - server. - - TOP msg n - - Arguments: - a message-number (required) which may NOT refer to to a - message marked as deleted, and a non-negative number - of lines (required) - - Restrictions: - may only be given in the TRANSACTION state - - Discussion: - If the POP3 server issues a positive response, then the - response given is multi-line. After the initial +OK, the - POP3 server sends the headers of the message, the blank - line separating the headers from the body, and then the - number of lines of the indicated message's body, being - careful to byte-stuff the termination character (as with - all multi-line responses). - - Note that if the number of lines requested by the POP3 - client is greater than than the number of lines in the - body, then the POP3 server sends the entire message. - - Possible Responses: - +OK top of message follows - -ERR no such message - - Examples: - C: TOP 1 10 - S: +OK - - - -Myers & Rose Standards Track [Page 11] - -RFC 1939 POP3 May 1996 - - - S: <the POP3 server sends the headers of the - message, a blank line, and the first 10 lines - of the body of the message> - S: . - ... - C: TOP 100 3 - S: -ERR no such message - - - UIDL [msg] - - Arguments: - a message-number (optional), which, if present, may NOT - refer to a message marked as deleted - - Restrictions: - may only be given in the TRANSACTION state. - - Discussion: - If an argument was given and the POP3 server issues a positive - response with a line containing information for that message. - This line is called a "unique-id listing" for that message. - - If no argument was given and the POP3 server issues a positive - response, then the response given is multi-line. After the - initial +OK, for each message in the maildrop, the POP3 server - responds with a line containing information for that message. - This line is called a "unique-id listing" for that message. - - In order to simplify parsing, all POP3 servers are required to - use a certain format for unique-id listings. A unique-id - listing consists of the message-number of the message, - followed by a single space and the unique-id of the message. - No information follows the unique-id in the unique-id listing. - - The unique-id of a message is an arbitrary server-determined - string, consisting of one to 70 characters in the range 0x21 - to 0x7E, which uniquely identifies a message within a - maildrop and which persists across sessions. This - persistence is required even if a session ends without - entering the UPDATE state. The server should never reuse an - unique-id in a given maildrop, for as long as the entity - using the unique-id exists. - - Note that messages marked as deleted are not listed. - - While it is generally preferable for server implementations - to store arbitrarily assigned unique-ids in the maildrop, - - - -Myers & Rose Standards Track [Page 12] - -RFC 1939 POP3 May 1996 - - - this specification is intended to permit unique-ids to be - calculated as a hash of the message. Clients should be able - to handle a situation where two identical copies of a - message in a maildrop have the same unique-id. - - Possible Responses: - +OK unique-id listing follows - -ERR no such message - - Examples: - C: UIDL - S: +OK - S: 1 whqtswO00WBw418f9t5JxYwZ - S: 2 QhdPYR:00WBw1Ph7x7 - S: . - ... - C: UIDL 2 - S: +OK 2 QhdPYR:00WBw1Ph7x7 - ... - C: UIDL 3 - S: -ERR no such message, only 2 messages in maildrop - - - USER name - - Arguments: - a string identifying a mailbox (required), which is of - significance ONLY to the server - - Restrictions: - may only be given in the AUTHORIZATION state after the POP3 - greeting or after an unsuccessful USER or PASS command - - Discussion: - To authenticate using the USER and PASS command - combination, the client must first issue the USER - command. If the POP3 server responds with a positive - status indicator ("+OK"), then the client may issue - either the PASS command to complete the authentication, - or the QUIT command to terminate the POP3 session. If - the POP3 server responds with a negative status indicator - ("-ERR") to the USER command, then the client may either - issue a new authentication command or may issue the QUIT - command. - - The server may return a positive response even though no - such mailbox exists. The server may return a negative - response if mailbox exists, but does not permit plaintext - - - -Myers & Rose Standards Track [Page 13] - -RFC 1939 POP3 May 1996 - - - password authentication. - - Possible Responses: - +OK name is a valid mailbox - -ERR never heard of mailbox name - - Examples: - C: USER frated - S: -ERR sorry, no mailbox for frated here - ... - C: USER mrose - S: +OK mrose is a real hoopy frood - - - PASS string - - Arguments: - a server/mailbox-specific password (required) - - Restrictions: - may only be given in the AUTHORIZATION state immediately - after a successful USER command - - Discussion: - When the client issues the PASS command, the POP3 server - uses the argument pair from the USER and PASS commands to - determine if the client should be given access to the - appropriate maildrop. - - Since the PASS command has exactly one argument, a POP3 - server may treat spaces in the argument as part of the - password, instead of as argument separators. - - Possible Responses: - +OK maildrop locked and ready - -ERR invalid password - -ERR unable to lock maildrop - - Examples: - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: -ERR maildrop already locked - ... - C: USER mrose - S: +OK mrose is a real hoopy frood - C: PASS secret - S: +OK mrose's maildrop has 2 messages (320 octets) - - - -Myers & Rose Standards Track [Page 14] - -RFC 1939 POP3 May 1996 - - - APOP name digest - - Arguments: - a string identifying a mailbox and a MD5 digest string - (both required) - - Restrictions: - may only be given in the AUTHORIZATION state after the POP3 - greeting or after an unsuccessful USER or PASS command - - Discussion: - Normally, each POP3 session starts with a USER/PASS - exchange. This results in a server/user-id specific - password being sent in the clear on the network. For - intermittent use of POP3, this may not introduce a sizable - risk. However, many POP3 client implementations connect to - the POP3 server on a regular basis -- to check for new - mail. Further the interval of session initiation may be on - the order of five minutes. Hence, the risk of password - capture is greatly enhanced. - - An alternate method of authentication is required which - provides for both origin authentication and replay - protection, but which does not involve sending a password - in the clear over the network. The APOP command provides - this functionality. - - A POP3 server which implements the APOP command will - include a timestamp in its banner greeting. The syntax of - the timestamp corresponds to the `msg-id' in [RFC822], and - MUST be different each time the POP3 server issues a banner - greeting. For example, on a UNIX implementation in which a - separate UNIX process is used for each instance of a POP3 - server, the syntax of the timestamp might be: - - <process-ID.clock@hostname> - - where `process-ID' is the decimal value of the process's - PID, clock is the decimal value of the system clock, and - hostname is the fully-qualified domain-name corresponding - to the host where the POP3 server is running. - - The POP3 client makes note of this timestamp, and then - issues the APOP command. The `name' parameter has - identical semantics to the `name' parameter of the USER - command. The `digest' parameter is calculated by applying - the MD5 algorithm [RFC1321] to a string consisting of the - timestamp (including angle-brackets) followed by a shared - - - -Myers & Rose Standards Track [Page 15] - -RFC 1939 POP3 May 1996 - - - secret. This shared secret is a string known only to the - POP3 client and server. Great care should be taken to - prevent unauthorized disclosure of the secret, as knowledge - of the secret will allow any entity to successfully - masquerade as the named user. The `digest' parameter - itself is a 16-octet value which is sent in hexadecimal - format, using lower-case ASCII characters. - - When the POP3 server receives the APOP command, it verifies - the digest provided. If the digest is correct, the POP3 - server issues a positive response, and the POP3 session - enters the TRANSACTION state. Otherwise, a negative - response is issued and the POP3 session remains in the - AUTHORIZATION state. - - Note that as the length of the shared secret increases, so - does the difficulty of deriving it. As such, shared - secrets should be long strings (considerably longer than - the 8-character example shown below). - - Possible Responses: - +OK maildrop locked and ready - -ERR permission denied - - Examples: - S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> - C: APOP mrose c4c9334bac560ecc979e58001b3e22fb - S: +OK maildrop has 1 message (369 octets) - - In this example, the shared secret is the string `tan- - staaf'. Hence, the MD5 algorithm is applied to the string - - <1896.697170952@dbc.mtview.ca.us>tanstaaf - - which produces a digest value of - - c4c9334bac560ecc979e58001b3e22fb - -8. Scaling and Operational Considerations - - Since some of the optional features described above were added to the - POP3 protocol, experience has accumulated in using them in large- - scale commercial post office operations where most of the users are - unrelated to each other. In these situations and others, users and - vendors of POP3 clients have discovered that the combination of using - the UIDL command and not issuing the DELE command can provide a weak - version of the "maildrop as semi-permanent repository" functionality - normally associated with IMAP. Of course the other capabilities of - - - -Myers & Rose Standards Track [Page 16] - -RFC 1939 POP3 May 1996 - - - IMAP, such as polling an existing connection for newly arrived - messages and supporting multiple folders on the server, are not - present in POP3. - - When these facilities are used in this way by casual users, there has - been a tendency for already-read messages to accumulate on the server - without bound. This is clearly an undesirable behavior pattern from - the standpoint of the server operator. This situation is aggravated - by the fact that the limited capabilities of the POP3 do not permit - efficient handling of maildrops which have hundreds or thousands of - messages. - - Consequently, it is recommended that operators of large-scale multi- - user servers, especially ones in which the user's only access to the - maildrop is via POP3, consider such options as: - - * Imposing a per-user maildrop storage quota or the like. - - A disadvantage to this option is that accumulation of messages may - result in the user's inability to receive new ones into the - maildrop. Sites which choose this option should be sure to inform - users of impending or current exhaustion of quota, perhaps by - inserting an appropriate message into the user's maildrop. - - * Enforce a site policy regarding mail retention on the server. - - Sites are free to establish local policy regarding the storage and - retention of messages on the server, both read and unread. For - example, a site might delete unread messages from the server after - 60 days and delete read messages after 7 days. Such message - deletions are outside the scope of the POP3 protocol and are not - considered a protocol violation. - - Server operators enforcing message deletion policies should take - care to make all users aware of the policies in force. - - Clients must not assume that a site policy will automate message - deletions, and should continue to explicitly delete messages using - the DELE command when appropriate. - - It should be noted that enforcing site message deletion policies - may be confusing to the user community, since their POP3 client - may contain configuration options to leave mail on the server - which will not in fact be supported by the server. - - One special case of a site policy is that messages may only be - downloaded once from the server, and are deleted after this has - been accomplished. This could be implemented in POP3 server - - - -Myers & Rose Standards Track [Page 17] - -RFC 1939 POP3 May 1996 - - - software by the following mechanism: "following a POP3 login by a - client which was ended by a QUIT, delete all messages downloaded - during the session with the RETR command". It is important not to - delete messages in the event of abnormal connection termination - (ie, if no QUIT was received from the client) because the client - may not have successfully received or stored the messages. - Servers implementing a download-and-delete policy may also wish to - disable or limit the optional TOP command, since it could be used - as an alternate mechanism to download entire messages. - -9. POP3 Command Summary - - Minimal POP3 Commands: - - USER name valid in the AUTHORIZATION state - PASS string - QUIT - - STAT valid in the TRANSACTION state - LIST [msg] - RETR msg - DELE msg - NOOP - RSET - QUIT - - Optional POP3 Commands: - - APOP name digest valid in the AUTHORIZATION state - - TOP msg n valid in the TRANSACTION state - UIDL [msg] - - POP3 Replies: - - +OK - -ERR - - Note that with the exception of the STAT, LIST, and UIDL commands, - the reply given by the POP3 server to any command is significant - only to "+OK" and "-ERR". Any text occurring after this reply - may be ignored by the client. - - - - - - - - - -Myers & Rose Standards Track [Page 18] - -RFC 1939 POP3 May 1996 - - -10. Example POP3 Session - - S: <wait for connection on TCP port 110> - C: <open connection> - S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> - C: APOP mrose c4c9334bac560ecc979e58001b3e22fb - S: +OK mrose's maildrop has 2 messages (320 octets) - C: STAT - S: +OK 2 320 - C: LIST - S: +OK 2 messages (320 octets) - S: 1 120 - S: 2 200 - S: . - C: RETR 1 - S: +OK 120 octets - S: <the POP3 server sends message 1> - S: . - C: DELE 1 - S: +OK message 1 deleted - C: RETR 2 - S: +OK 200 octets - S: <the POP3 server sends message 2> - S: . - C: DELE 2 - S: +OK message 2 deleted - C: QUIT - S: +OK dewey POP3 server signing off (maildrop empty) - C: <close connection> - S: <wait for next connection> - -11. Message Format - - All messages transmitted during a POP3 session are assumed to conform - to the standard for the format of Internet text messages [RFC822]. - - It is important to note that the octet count for a message on the - server host may differ from the octet count assigned to that message - due to local conventions for designating end-of-line. Usually, - during the AUTHORIZATION state of the POP3 session, the POP3 server - can calculate the size of each message in octets when it opens the - maildrop. For example, if the POP3 server host internally represents - end-of-line as a single character, then the POP3 server simply counts - each occurrence of this character in a message as two octets. Note - that lines in the message which start with the termination octet need - not (and must not) be counted twice, since the POP3 client will - remove all byte-stuffed termination characters when it receives a - multi-line response. - - - -Myers & Rose Standards Track [Page 19] - -RFC 1939 POP3 May 1996 - - -12. References - - [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC - 821, USC/Information Sciences Institute, August 1982. - - [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text - Messages", STD 11, RFC 822, University of Delaware, August 1982. - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - MIT Laboratory for Computer Science, April 1992. - - [RFC1730] Crispin, M., "Internet Message Access Protocol - Version - 4", RFC 1730, University of Washington, December 1994. - - [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, - Carnegie Mellon, December 1994. - -13. Security Considerations - - It is conjectured that use of the APOP command provides origin - identification and replay protection for a POP3 session. - Accordingly, a POP3 server which implements both the PASS and APOP - commands should not allow both methods of access for a given user; - that is, for a given mailbox name, either the USER/PASS command - sequence or the APOP command is allowed, but not both. - - Further, note that as the length of the shared secret increases, so - does the difficulty of deriving it. - - Servers that answer -ERR to the USER command are giving potential - attackers clues about which names are valid. - - Use of the PASS command sends passwords in the clear over the - network. - - Use of the RETR and TOP commands sends mail in the clear over the - network. - - Otherwise, security issues are not discussed in this memo. - -14. Acknowledgements - - The POP family has a long and checkered history. Although primarily - a minor revision to RFC 1460, POP3 is based on the ideas presented in - RFCs 918, 937, and 1081. - - In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff - provided significant comments on the APOP command. - - - -Myers & Rose Standards Track [Page 20] - -RFC 1939 POP3 May 1996 - - -15. Authors' Addresses - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave - Pittsburgh, PA 15213 - - EMail: jgm+@cmu.edu - - - Marshall T. Rose - Dover Beach Consulting, Inc. - 420 Whisman Court - Mountain View, CA 94043-2186 - - EMail: mrose@dbc.mtview.ca.us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Rose Standards Track [Page 21] - -RFC 1939 POP3 May 1996 - - -Appendix A. Differences from RFC 1725 - - This memo is a revision to RFC 1725, a Draft Standard. It makes the - following changes from that document: - - - clarifies that command keywords are case insensitive. - - - specifies that servers must send "+OK" and "-ERR" in - upper case. - - - specifies that the initial greeting is a positive response, - instead of any string which should be a positive response. - - - clarifies behavior for unimplemented commands. - - - makes the USER and PASS commands optional. - - - clarified the set of possible responses to the USER command. - - - reverses the order of the examples in the USER and PASS - commands, to reduce confusion. - - - clarifies that the PASS command may only be given immediately - after a successful USER command. - - - clarified the persistence requirements of UIDs and added some - implementation notes. - - - specifies a UID length limitation of one to 70 octets. - - - specifies a status indicator length limitation - of 512 octets, including the CRLF. - - - clarifies that LIST with no arguments on an empty mailbox - returns success. - - - adds a reference from the LIST command to the Message Format - section - - - clarifies the behavior of QUIT upon failure - - - clarifies the security section to not imply the use of the - USER command with the APOP command. - - - adds references to RFCs 1730 and 1734 - - - clarifies the method by which a UA may enter mail into the - transport system. - - - -Myers & Rose Standards Track [Page 22] - -RFC 1939 POP3 May 1996 - - - - clarifies that the second argument to the TOP command is a - number of lines. - - - changes the suggestion in the Security Considerations section - for a server to not accept both PASS and APOP for a given user - from a "must" to a "should". - - - adds a section on scaling and operational considerations - -Appendix B. Command Index - - APOP ....................................................... 15 - DELE ....................................................... 8 - LIST ....................................................... 6 - NOOP ....................................................... 9 - PASS ....................................................... 14 - QUIT ....................................................... 5 - QUIT ....................................................... 10 - RETR ....................................................... 8 - RSET ....................................................... 9 - STAT ....................................................... 6 - TOP ........................................................ 11 - UIDL ....................................................... 12 - USER ....................................................... 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Rose Standards Track [Page 23] - diff --git a/RFC/rfc1985.txt b/RFC/rfc1985.txt deleted file mode 100644 index f49afd75..00000000 --- a/RFC/rfc1985.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group J. De Winter -Request for Comments: 1985 Wildbear Consulting, Inc. -Category: Standards Track August 1996 - - - SMTP Service Extension - for Remote Message Queue Starting - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This memo defines an extension to the SMTP service whereby an SMTP - client and server may interact to give the server an opportunity to - start the processing of its queues for messages to go to a given - host. This extension is meant to be used in startup conditions as - well as for mail nodes that have transient connections to their - service providers. - -1. Introduction - - The TURN command was a valid attempt to address the problem of having - to start the processing for the mail queue on a remote machine. - However, the TURN command presents a large security loophole. As - there is no verification of the remote host name, the TURN command - could be used by a rogue system to download the mail for a site other - than itself. - - Therefore, this memo introduces the ETRN command. This command uses - the mechanism defined in [4] to define extensions to the SMTP service - whereby a client ("sender-SMTP") may request that the server - ("receiver-SMTP") start the processing of its mail queues for - messages that are waiting at the server for the client machine. If - any messages are at the server for the client, then the server should - create a new SMTP session and send the messages at that time. - - - - - - - - - - -De Winter Standards Track [Page 1] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - -2. Framework for the ETRN Extension - - The following service extension is therefore defined: - - (1) the name of the SMTP service extension is "Remote Queue - Processing Declaration"; - - (2) the EHLO keyword value associated with this extension is "ETRN", - with no associated parameters; - - (3) one additional verb, ETRN, with a single parameter that - specifies the name of the client(s) to start processing for; - - (4) no additional SMTP verbs are defined by this extension. - - The remainder of this memo specifies how support for the extension - affects the behavior of an SMTP client and server. - -3. The Remote Queue Processing Declaration service extension - - To save money, many small companies want to only maintain transient - connections to their service providers. In addition, there are some - situations where the client sites depend on their mail arriving - quickly, so forcing the queues on the server belonging to their - service provider may be more desirable than waiting for the retry - timeout to occur. - - Both of these situations could currently be fixed using the TURN - command defined in [1], if it were not for a large security loophole - in the TURN command. As it stands, the TURN command will reverse the - direction of the SMTP connection and assume that the remote host is - being honest about what its name is. The security loophole is that - there is no documented stipulation for checking the authenticity of - the remote host name, as given in the HELO or EHLO command. As such, - most SMTP and ESMTP implementations do not implement the TURN command - to avoid this security loophole. - - This has been addressed in the design of the ETRN command. This - extended turn command was written with the points in the first - paragraph in mind, yet paying attention to the problems that - currently exist with the TURN command. The security loophole is - avoided by asking the server to start a new connection aimed at the - specified client. - - In this manner, the server has a lot more certainty that it is - talking to the correct SMTP client. This mechanism can just be seen - as a more immediate version of the retry queues that appear in most - SMTP implementations. In addition, as this command will take a - - - -De Winter Standards Track [Page 2] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - - single parameter, the name of the remote host(s) to start the queues - for, the server can decide whether it wishes to respect the request - or deny it for any local administrative reasons. - -4. Definitions - - Remote queue processing means that using an SMTP or ESMTP connection, - the client may request that the server start to process parts of its - messaging queue. This processing is performed using the existing - SMTP infrastructure and will occur at some point after the processing - is initiated. - - The server host is the node that is responding to the ETRN - command. - - The client host is the node that is initiating the ETRN command. - - The remote host name is defined to be a plain-text field that - specifies a name for the remote host(s). This remote host name may - also include an alias for the specified remote host or special - commands to identify other types of queues. - -5. The extended ETRN command - - The extended ETRN command is issued by the client host when it wishes - to start the SMTP queue processing of a given server host. The - syntax of this command is as follows: - - ETRN [<option character>]<node name><CR><LF> - - This command may be issued at any time once a session is established, - as long as there is not a transaction occuring. Thus, this command - is illegal between a MAIL FROM: command and the end of the DATA - commands and responses. - - The specified node name must be a fully qualified domain name for the - node, which may refer to a CNAME or MX pointer in the DNS. If an - alias is used for the node, multiple ETRN commands may be needed to - start the processing for the node as it may be listed at the remote - site under multiple names. This can also be addressed using the - options discussed in section 5.3. - - The option character under normal circumstances is not used. - - - - - - - - -De Winter Standards Track [Page 3] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - -5.1 Server action on receipt of the extended ETRN command - - When the server host receives the ETRN command, it should have a look - at the node name that is specified in the command and make a local - decision if it should honour the request. If not, the appropriate - error codes should be returned to the client. - - Otherwise, the server host should force its retry queues to start - sending messages to that remote site, using another SMTP connection. - At the moment, there is no requirement that a connection must occur, - or that the connection must occur within a given time frame. This - should be noted in the case where there are no messages for the - client host at the server host and only the 250 response is used. - - Since the processing of the queues may take an indeterminate amount - of time, this command should return immediately with a response to - the client host. The valid return codes for this command are: - - 250 OK, queuing for node <x> started - 251 OK, no messages waiting for node <x> - 252 OK, pending messages for node <x> started - 253 OK, <n> pending messages for node <x> started - 458 Unable to queue messages for node <x> - 459 Node <x> not allowed: <reason> - 500 Syntax Error - 501 Syntax Error in Parameters - - The 250 response code does not indicate that messages will be sent to - the system in question, just that the queue has been started and some - action will occur. If the server is capable of supporting it, the - 251, 252 or 253 response codes should be used to give more - information to the client side. In this case, if there are messages - waiting for the client side node, a check can be performed using - these responses codes as an indication of when there are no more - pending messages in the queue for that node. - - The 458 and 459 result codes should be used to give more information - back to the client host as to why the action was not performed. If - the syntax of the request is not correct, then the 500 and 501 result - codes should be used. - -5.2 Client action on receiving response to extended ETRN command - - If one of the 500 level error codes (550 or 551) are sent, the client - should assume that the protocol is not supported in the remote host - or that the protocol has not been implemented correctly on either the - client or server host. In this case, multiple ETRN commands (dealing - with the aliases for the system) should not be sent. - - - -De Winter Standards Track [Page 4] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - - If the 250 response is received, then the client host can assume that - the server host found its request to be satisfactory and it will send - any queued messages. This process may involve going through a very - large retry queue, and may take some time. - - If the 400 level response is received, then the client can assume - that the server supports the command, but for some local reason does - not want to accept the ETRN command as is. In most cases, it will - mean that there is a list of nodes that it will accept the command - from and the current client is not on that list. The 459 response - code is presented to allow for a more in-depth reason as to why the - remote queuing cannot be started. - -5.3 Use Of ETRN to release mail for a subdomain or queue - - If the requesting server wishes to release all of the mail for a - given subdomain, a variation on the ETRN command can be used. To - perform this request, the option character '@' should be used in - front of the node name. In this manner, any domain names that are - formed with a suffix of the specified node name are released. - - For example, if the command ETRN @foo.com was issued, then any - accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com - may be released. It should be noted that the receiving side of the - ETRN command should make a decision based on the client in question - and only allow certain combinations for each of the nodes. This is - more of a security issue than anything else. - - In a similar vein, it might be necessary under some circumstances to - release a certain queue, where that queue does not correspond to a - given domain name. To this end, the option character '#' can be used - to force the processing of a given queue. In this case, the node - name would be used as a queue name instead, and its syntactical - structure would be dependant on the receiving server. An example of - this would be using the command ETRN #uucp to force the flush of a - UUCP queue. Note that the use of this option is entirely a local - matter and there is no way for a client to find a list of any such - queues that exist. - -6. Minimal usage - - A "minimal" client may use this extension with its host name to start - the queues on the server host. This minimal usage will not handle - cases where mail for 'x.y' is sent to 's.x.y'. - - A minimal server may use this extensions to start the processing of - the queues for all remote sites. In this case, the 458 error - response will not be seen, and it should always return the 250 - - - -De Winter Standards Track [Page 5] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - - response as it will always try and start the processing for any - request. - -7. Example - - The following example illustrates the use of remote queue processing - with some permanent and temporary failures. - - S: <wait for connection on TCP port 25> - C: <open connection to server> - S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992) - C: EHLO ymir.claremont.edu - S: 250-sigurd.innosoft.com - S: 250-EXPN - S: 250-HELP - S: 250 ETRN - C: ETRN - S: 500 Syntax Error - C: ETRN localname - S: 501 Syntax Error in Parameters - C: ETRN uu.net - S: 458 Unable to queue messages for node uu.net - ... - - C: ETRN sigurd.innosoft.com - S: 250 OK, queuing for node sigurd.innosoft.com started - C: ETRN innosoft.com - S: 250 OK, queuing for node innosoft.com started - - OR - - C: ETRN sigurd.innosoft.com - S: 251 OK, no messages waiting for node sigurd.innosoft.com - C: ETRN innosoft.com - S: 252 OK, pending messages for node innosoft.com started - C: ETRN mysoft.com - S: 253 OK, 14 pending messages for node mysoft.com started - - ... - C: ETRN foo.bar - S: 459 Node foo.bar not allowed: Unable to resolve name. - ... - C: QUIT - S: 250 Goodbye - - - - - - - -De Winter Standards Track [Page 6] - -RFC 1985 SMTP Service Extension - ETRN August 1996 - - -8. Security Considerations - - This command does not compromise any security considerations of any - existing SMTP or ESMTP protocols as it merely shortens the time that - a client needs to wait before their messages are retried. - - Precautions should be taken to make sure that any client server can - only use the @ and # option characters for systems that make sense. - Failure to implement some kind of sanity checking on the parameters - could lead to congestion. This would be evident if a person asking - to release @com, which would release mail for any address that ended - with com. - -9. Acknowledgements - - This document was created with lots of support from the users of our - products, who have given some input to the functionality that they - would like to see in the software that they bought. - -10. References - - [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC - 821, August 1982. - - [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, - E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United - Nations University, Innosoft International, Inc., Dover Beach - Consulting, Inc., Network Management Associates, Inc., The Branch - Office, February 1993. - -11. Author's Address - - Jack De Winter - Wildbear Consulting, Inc. - 17 Brock Street - Kitchener, Ontario, Canada - N2M 1X2 - - Phone: +1 519 576 3873 - EMail: jack@wildbear.on.ca - - - - - - - - - - - -De Winter Standards Track [Page 7] - diff --git a/RFC/rfc2033.txt b/RFC/rfc2033.txt deleted file mode 100644 index a47433e8..00000000 --- a/RFC/rfc2033.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group J. Myers -Request for Comments: 2033 Carnegie Mellon -Category: Informational October 1996 - - - Local Mail Transfer Protocol - -Status of this Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -1. Abstract - - SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a - mechanism for transferring mail reliably and efficiently. The design - of the SMTP protocol effectively requires the server to manage a mail - delivery queue. - - In some limited circumstances, outside the area of mail exchange - between independent hosts on public networks, it is desirable to - implement a system where a mail receiver does not manage a queue. - This document describes the LMTP protocol for transporting mail into - such systems. - - Although LMTP is an alternative protocol to ESMTP, it uses (with a - few changes) the syntax and semantics of ESMTP. This design permits - LMTP to utilize the extensions defined for ESMTP. LMTP should be - used only by specific prior arrangement and configuration, and it - MUST NOT be used on TCP port 25. - -Table of Contents - - 1. Abstract ................................................ 1 - 2. Conventions Used in this Document ....................... 2 - 3. Introduction and Overview ............................... 2 - 4. The LMTP protocol ....................................... 3 - 4.1. The LHLO, HELO and EHLO commands ........................ 4 - 4.2. The DATA command ........................................ 4 - 4.3. The BDAT command ........................................ 5 - 5. Implementation requirements ............................. 6 - 6. Acknowledgments ......................................... 6 - 7. References .............................................. 7 - 8. Security Considerations ................................. 7 - 9. Author's Address ........................................ 7 - - - - - -Myers Informational [Page 1] - -RFC 2033 LMTP October 1996 - - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - -3. Introduction and Overview - - The design of the SMTP protocol effectively requires the server to - manage a mail delivery queue. This is because a single mail - transaction may specify multiple recipients and the final "." of the - DATA command may return only one reply code, to indicate the status - of the entire transaction. If, for example, a server is given a - transaction for two recipients, delivery to the first succeeds, and - delivery to the second encounters a temporary failure condition, - there is no mechanism to inform the client of the situation. The - server must queue the message and later attempt to deliver it to the - second recipient. - - This queuing requirement is beneficial in the situation for which - SMTP was originally designed: store-and-forward relay of mail between - networked hosts. In some limited situations, it is desirable to have - a server which does not manage a queue, instead relying on the client - to perform queue management. As an example, consider a hypothetical - host with a mail system designed as follows: - - - - TCP port 25 +-----------------+ - ---------------------->| | ######### - | Queue |<># Mail # - TCP port 25 | Manager | # Queue # - <----------------------| | ######### - +-----------------+ - Local * ^ Local * Local - IPC * | IPC * IPC - * | * - * | * - * | * - V | V - Non-SMTP +----------+ +----------+ - Protocol | Gateway | | Local | ######### - <==============>| Delivery | | Delivery |>># Mail # - | Agent | | Agent | # Spool # - +----------+ +----------+ ######### - - - The host's mail system has three independent, communicating - subsystems. The first is a queue manager, which acts as a - - - -Myers Informational [Page 2] - -RFC 2033 LMTP October 1996 - - - traditional SMTP agent, transferring messages to and from other hosts - over TCP and managing a mail queue in persistent storage. The other - two are agents which handle delivery for addresses in domains for - which the host takes responsibility. One agent performs gatewaying - to and from some other mail system. The other agent delivers the - message into a persistent mail spool. - - It would be desirable to use SMTP over a local inter-process - communication channel to transfer messages from the queue manager to - the delivery agents. It would, however, significantly increase the - complexity of the delivery agents to require them to manage their own - mail queues. - - The common practice of invoking a delivery agent with the envelope - address(es) as command-line arguments, then having the delivery agent - communicate status with an exit code has three serious problems: the - agent can only return one exit code to be applied to all recipients, - it is difficult to extend the interface to deal with ESMTP extensions - such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and - exits performed by system libraries due to temporary conditions - frequently get interpreted as permanent errors. - - The LMTP protocol causes the server to return, after the final "." of - the DATA command, one reply for each recipient. Therefore, if the - queue manager is configured to use LMTP instead of SMTP when - transferring messages to the delivery agents, then the delivery - agents may attempt delivery to each recipient after the final "." and - individually report the status for each recipient. Connections which - should use the LMTP protocol are drawn in the diagram above using - asterisks. - - Note that it is not beneficial to use the LMTP protocol when - transferring messages to the queue manager, either from the network - or from a delivery agent. The queue manager does implement a mail - queue, so it may store the message and take responsibility for later - delivering it. - -4. The LMTP protocol - - The LMTP protocol is identical to the SMTP protocol SMTP [SMTP] - [HOST-REQ] with its service extensions [ESMTP], except as modified by - this document. - - A "successful" RCPT command is defined as an RCPT command which - returns a Positive Completion reply code. - - A "Positive Completion reply code" is defined in Appendix E of STD - 10, RFC 821 [SMTP] as a reply code which "2" as the first digit. - - - -Myers Informational [Page 3] - -RFC 2033 LMTP October 1996 - - -4.1. The LHLO, HELO and EHLO commands - - The HELO and EHLO commands of ESMTP are replaced by the LHLO command. - This permits a misconfiguration where both parties are not using the - same protocol to be detected. - - The LHLO command has identical semantics to the EHLO command of ESMTP - [ESMTP]. - - The HELO and EHLO commands of ESMTP are not present in LMTP. A LMTP - server MUST NOT return a Postive Completion reply code to these - commands. The 500 reply code is recommended. - -4.2. The DATA command - - In the LMTP protocol, there is one additional restriction placed on - the DATA command, and one change to how replies to the final "." are - sent. - - The additional restriction is that when there have been no successful - RCPT commands in the mail transaction, the DATA command MUST fail - with a 503 reply code. - - The change is that after the final ".", the server returns one reply - for each previously successful RCPT command in the mail transaction, - in the order that the RCPT commands were issued. Even if there were - multiple successful RCPT commands giving the same forward-path, there - must be one reply for each successful RCPT command. - - When one of these replies to the final "." is a Positive Completion - reply, the server is accepting responsibility for delivering or - relying the message to the corresponding recipient. It must take - this responsibility seriously, i.e., it MUST NOT lose the message for - frivolous reasons, e.g., because the host later crashes or because of - a predictable resource shortage. - - A multiline reply is still considered a single reply and corresponds - to a single RCPT command. - - EXAMPLE: - - S: 220 foo.edu LMTP server ready - C: LHLO foo.edu - S: 250-foo.edu - S: 250-PIPELINING - S: 250 SIZE - C: MAIL FROM:<chris@bar.com> - S: 250 OK - - - -Myers Informational [Page 4] - -RFC 2033 LMTP October 1996 - - - C: RCPT TO:<pat@foo.edu> - S: 250 OK - C: RCPT TO:<jones@foo.edu> - S: 550 No such user here - C: RCPT TO:<green@foo.edu> - S: 250 OK - C: DATA - S: 354 Start mail input; end with <CRLF>.<CRLF> - C: Blah blah blah... - C: ...etc. etc. etc. - C: . - S: 250 OK - S: 452 <green@foo.edu> is temporarily over quota - C: QUIT - S: 221 foo.edu closing connection - - -NOTE: in the above example, the domain names of both the client and - server are identical. This is because in the example the client and - server are different subsystems of the same mail domain. - -4.3. The BDAT command - - If the server supports the ESMTP CHUNKING extension [BINARYMIME], a - BDAT command containing the LAST parameter returns one reply for each - previously successful RCPT command in the mail transaction, in the - order that the RCPT commands were issued. Even if there were - multiple successful RCPT commands giving the same forward-path, there - must be one reply for each successful RCPT command. If there were no - previously successful RCPT commands in the mail transaction, then the - BDAT LAST command returns zero replies. - - When one of these replies to the BDAT LAST command is a Positive - Completion reply, the server is accepting responsibility for - delivering or relaying the message to the corresponding recipient. - It must take this responsibility seriously, i.e., it MUST NOT lose - the message for frivolous reasons, e.g., because the host later - crashes or because of a predictable resource shortage. - - A multiline reply is still considered a single reply and corresponds - to a single RCPT command. - - The behavior of BDAT commands without the LAST parameter is not - changed; they still return exactly one reply. - - - - - - - -Myers Informational [Page 5] - -RFC 2033 LMTP October 1996 - - -5. Implementation requirements - - As LMTP is a different protocol than SMTP, it MUST NOT be used on the - TCP service port 25. - - A server implementation MUST implement the PIPELINING [PIPELINING] - and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions. A - server implementation SHOULD implement the 8BITMIME [8BITMIME] - extension. - - Use of LMTP can aggravate the situation described in [DUP-MSGS]. To - avoid this synchronization problem, the following requirements are - made of implementations: - - A server implementation which is capable of quickly accepting - responsibility for delivering or relaying a message to multiple - recipients and which is capable of sending any necessary notification - messages SHOULD NOT implement the LMTP protocol. - - The LMTP protocol SHOULD NOT be used over wide area networks. - - The server SHOULD send each reply as soon as possible. If it is - going to spend a nontrivial amount of time handling delivery for the - next recipient, it SHOULD flush any outgoing LMTP buffer, so the - reply may be quickly received by the client. - - The client SHOULD process the replies as they come in, instead of - waiting for all of the replies to arrive before processing any of - them. If the connection closes after replies for some, but not all, - recipients have arrived, the client MUST process the replies that - arrived and treat the rest as temporary failures. - -6. Acknowledgments - - This work is a refinement of the MULT extension, which was invented - by Jeff Michaud and was used in implementing gateways to the Mail-11 - mail system. - - Many thanks to Matt Thomas for assisting me in understanding the - semantics of the Mail-11 MULT extension. - - - - - - - - - - - -Myers Informational [Page 6] - -RFC 2033 LMTP October 1996 - - -7. References - - [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME - transport", RFC 1652, July 1994. - - [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission - of Large and Binary MIME Messages", RFC 1830, August 1995. - - [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for - Delivery Status Notifications", RFC 1894, January 1996. - - [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047, - February 1988. - - [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for - Returning Enhanced Error Codes", RFC 2034, October 1996. - - [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N., - "SMTP Service Extensions", RFC 1869, November 1995. - - [HOST-REQ] Braden, R., "Requirements for Internet hosts - application - and support", STD 3, RFC 1123 section 5, October 1989. - - [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for - Command Pipelining", RFC 1854, October 1995. - - [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, - August 1982. - - - There are no known security issues with the issues in this memo. - -9. Author's Address - - John G. Myers - Carnegie-Mellon University - 5000 Forbes Ave. - Pittsburgh PA, 15213-3890 - - EMail: jgm+@cmu.edu - - - - - - - - - - - -Myers Informational [Page 7] - diff --git a/RFC/rfc2060.txt b/RFC/rfc2060.txt deleted file mode 100644 index 591dec4d..00000000 --- a/RFC/rfc2060.txt +++ /dev/null @@ -1,4595 +0,0 @@ - - - - - - -Network Working Group M. Crispin -Request for Comments: 2060 University of Washington -Obsoletes: 1730 December 1996 -Category: Standards Track - - - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) - allows a client to access and manipulate electronic mail messages on - a server. IMAP4rev1 permits manipulation of remote message folders, - called "mailboxes", in a way that is functionally equivalent to local - mailboxes. IMAP4rev1 also provides the capability for an offline - client to resynchronize with the server (see also [IMAP-DISC]). - - IMAP4rev1 includes operations for creating, deleting, and renaming - mailboxes; checking for new messages; permanently removing messages; - setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; - searching; and selective fetching of message attributes, texts, and - portions thereof. Messages in IMAP4rev1 are accessed by the use of - numbers. These numbers are either message sequence numbers or unique - identifiers. - - IMAP4rev1 supports a single server. A mechanism for accessing - configuration information to support multiple IMAP4rev1 servers is - discussed in [ACAP]. - - IMAP4rev1 does not specify a means of posting mail; this function is - handled by a mail transfer protocol such as [SMTP]. - - IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and - unpublished IMAP2bis protocols. In the course of the evolution of - IMAP4rev1, some aspects in the earlier protocol have become obsolete. - Obsolete commands, responses, and data formats which an IMAP4rev1 - implementation may encounter when used with an earlier implementation - are described in [IMAP-OBSOLETE]. - - - - - -Crispin Standards Track [Page 1] - -RFC 2060 IMAP4rev1 December 1996 - - - Other compatibility issues with IMAP2bis, the most common variant of - the earlier protocol, are discussed in [IMAP-COMPAT]. A full - discussion of compatibility issues with rare (and presumed extinct) - variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is - primarily of historical interest. - -Table of Contents - -IMAP4rev1 Protocol Specification .................................. 4 -1. How to Read This Document ................................. 4 -1.1. Organization of This Document ............................. 4 -1.2. Conventions Used in This Document ......................... 4 -2. Protocol Overview ......................................... 5 -2.1. Link Level ................................................ 5 -2.2. Commands and Responses .................................... 6 -2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 6 -2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 7 -2.3. Message Attributes ........................................ 7 -2.3.1. Message Numbers ........................................... 7 -2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7 -2.3.1.2. Message Sequence Number Message Attribute ......... 9 -2.3.2. Flags Message Attribute .................................... 9 -2.3.3. Internal Date Message Attribute ........................... 10 -2.3.4. [RFC-822] Size Message Attribute .......................... 11 -2.3.5. Envelope Structure Message Attribute ...................... 11 -2.3.6. Body Structure Message Attribute .......................... 11 -2.4. Message Texts ............................................. 11 -3. State and Flow Diagram .................................... 11 -3.1. Non-Authenticated State ................................... 11 -3.2. Authenticated State ....................................... 11 -3.3. Selected State ............................................ 12 -3.4. Logout State .............................................. 12 -4. Data Formats .............................................. 12 -4.1. Atom ...................................................... 13 -4.2. Number .................................................... 13 -4.3. String ..................................................... 13 -4.3.1. 8-bit and Binary Strings .................................. 13 -4.4. Parenthesized List ........................................ 14 -4.5. NIL ....................................................... 14 -5. Operational Considerations ................................ 14 -5.1. Mailbox Naming ............................................ 14 -5.1.1. Mailbox Hierarchy Naming .................................. 14 -5.1.2. Mailbox Namespace Naming Convention ....................... 14 -5.1.3. Mailbox International Naming Convention ................... 15 -5.2. Mailbox Size and Message Status Updates ................... 16 -5.3. Response when no Command in Progress ...................... 16 -5.4. Autologout Timer .......................................... 16 -5.5. Multiple Commands in Progress ............................. 17 - - - -Crispin Standards Track [Page 2] - -RFC 2060 IMAP4rev1 December 1996 - - -6. Client Commands ........................................... 17 -6.1. Client Commands - Any State ............................... 18 -6.1.1. CAPABILITY Command ........................................ 18 -6.1.2. NOOP Command .............................................. 19 -6.1.3. LOGOUT Command ............................................ 20 -6.2. Client Commands - Non-Authenticated State ................. 20 -6.2.1. AUTHENTICATE Command ...................................... 21 -6.2.2. LOGIN Command ............................................. 22 -6.3. Client Commands - Authenticated State ..................... 22 -6.3.1. SELECT Command ............................................ 23 -6.3.2. EXAMINE Command ........................................... 24 -6.3.3. CREATE Command ............................................ 25 -6.3.4. DELETE Command ............................................ 26 -6.3.5. RENAME Command ............................................ 27 -6.3.6. SUBSCRIBE Command ......................................... 29 -6.3.7. UNSUBSCRIBE Command ....................................... 30 -6.3.8. LIST Command .............................................. 30 -6.3.9. LSUB Command .............................................. 32 -6.3.10. STATUS Command ............................................ 33 -6.3.11. APPEND Command ............................................ 34 -6.4. Client Commands - Selected State .......................... 35 -6.4.1. CHECK Command ............................................. 36 -6.4.2. CLOSE Command ............................................. 36 -6.4.3. EXPUNGE Command ........................................... 37 -6.4.4. SEARCH Command ............................................ 37 -6.4.5. FETCH Command ............................................. 41 -6.4.6. STORE Command ............................................. 45 -6.4.7. COPY Command .............................................. 46 -6.4.8. UID Command ............................................... 47 -6.5. Client Commands - Experimental/Expansion .................. 48 -6.5.1. X<atom> Command ........................................... 48 -7. Server Responses .......................................... 48 -7.1. Server Responses - Status Responses ....................... 49 -7.1.1. OK Response ............................................... 51 -7.1.2. NO Response ............................................... 51 -7.1.3. BAD Response .............................................. 52 -7.1.4. PREAUTH Response .......................................... 52 -7.1.5. BYE Response .............................................. 52 -7.2. Server Responses - Server and Mailbox Status .............. 53 -7.2.1. CAPABILITY Response ....................................... 53 -7.2.2. LIST Response .............................................. 54 -7.2.3. LSUB Response ............................................. 55 -7.2.4 STATUS Response ........................................... 55 -7.2.5. SEARCH Response ........................................... 55 -7.2.6. FLAGS Response ............................................ 56 -7.3. Server Responses - Mailbox Size ........................... 56 -7.3.1. EXISTS Response ........................................... 56 -7.3.2. RECENT Response ........................................... 57 - - - -Crispin Standards Track [Page 3] - -RFC 2060 IMAP4rev1 December 1996 - - -7.4. Server Responses - Message Status ......................... 57 -7.4.1. EXPUNGE Response .......................................... 57 -7.4.2. FETCH Response ............................................ 58 -7.5. Server Responses - Command Continuation Request ........... 63 -8. Sample IMAP4rev1 connection ............................... 63 -9. Formal Syntax ............................................. 64 -10. Author's Note ............................................. 74 -11. Security Considerations ................................... 74 -12. Author's Address .......................................... 75 -Appendices ........................................................ 76 -A. References ................................................ 76 -B. Changes from RFC 1730 ..................................... 77 -C. Key Word Index ............................................ 79 - - -IMAP4rev1 Protocol Specification - -1. How to Read This Document - -1.1. Organization of This Document - - This document is written from the point of view of the implementor of - an IMAP4rev1 client or server. Beyond the protocol overview in - section 2, it is not optimized for someone trying to understand the - operation of the protocol. The material in sections 3 through 5 - provides the general context and definitions with which IMAP4rev1 - operates. - - Sections 6, 7, and 9 describe the IMAP commands, responses, and - syntax, respectively. The relationships among these are such that it - is almost impossible to understand any of them separately. In - particular, do not attempt to deduce command syntax from the command - section alone; instead refer to the Formal Syntax section. - -1.2. Conventions Used in This Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - The following terms are used in this document to signify the - requirements of this specification. - - 1) MUST, or the adjective REQUIRED, means that the definition is - an absolute requirement of the specification. - - 2) MUST NOT that the definition is an absolute prohibition of the - specification. - - - - -Crispin Standards Track [Page 4] - -RFC 2060 IMAP4rev1 December 1996 - - - 3) SHOULD means that there may exist valid reasons in particular - circumstances to ignore a particular item, but the full - implications MUST be understood and carefully weighed before - choosing a different course. - - 4) SHOULD NOT means that there may exist valid reasons in - particular circumstances when the particular behavior is - acceptable or even useful, but the full implications SHOULD be - understood and the case carefully weighed before implementing - any behavior described with this label. - - 5) MAY, or the adjective OPTIONAL, means that an item is truly - optional. One vendor may choose to include the item because a - particular marketplace requires it or because the vendor feels - that it enhances the product while another vendor may omit the - same item. An implementation which does not include a - particular option MUST be prepared to interoperate with another - implementation which does include the option. - - "Can" is used instead of "may" when referring to a possible - circumstance or situation, as opposed to an optional facility of - the protocol. - - "User" is used to refer to a human user, whereas "client" refers - to the software being run by the user. - - "Connection" refers to the entire sequence of client/server - interaction from the initial establishment of the network - connection until its termination. "Session" refers to the - sequence of client/server interaction from the time that a mailbox - is selected (SELECT or EXAMINE command) until the time that - selection ends (SELECT or EXAMINE of another mailbox, CLOSE - command, or connection termination). - - Characters are 7-bit US-ASCII unless otherwise specified. Other - character sets are indicated using a "CHARSET", as described in - [MIME-IMT] and defined in [CHARSET]. CHARSETs have important - additional semantics in addition to defining character set; refer - to these documents for more detail. - -2. Protocol Overview - -2.1. Link Level - - The IMAP4rev1 protocol assumes a reliable data stream such as - provided by TCP. When TCP is used, an IMAP4rev1 server listens on - port 143. - - - - -Crispin Standards Track [Page 5] - -RFC 2060 IMAP4rev1 December 1996 - - -2.2. Commands and Responses - - An IMAP4rev1 connection consists of the establishment of a - client/server network connection, an initial greeting from the - server, and client/server interactions. These client/server - interactions consist of a client command, server data, and a server - completion result response. - - All interactions transmitted by client and server are in the form of - lines; that is, strings that end with a CRLF. The protocol receiver - of an IMAP4rev1 client or server is either reading a line, or is - reading a sequence of octets with a known count followed by a line. - -2.2.1. Client Protocol Sender and Server Protocol Receiver - - The client command begins an operation. Each client command is - prefixed with an identifier (typically a short alphanumeric string, - e.g. A0001, A0002, etc.) called a "tag". A different tag is - generated by the client for each command. - - There are two cases in which a line from the client does not - represent a complete command. In one case, a command argument is - quoted with an octet count (see the description of literal in String - under Data Formats); in the other case, the command arguments require - server feedback (see the AUTHENTICATE command). In either case, the - server sends a command continuation request response if it is ready - for the octets (if appropriate) and the remainder of the command. - This response is prefixed with the token "+". - - Note: If, instead, the server detected an error in the command, it - sends a BAD completion response with tag matching the command (as - described below) to reject the command and prevent the client from - sending any more of the command. - - It is also possible for the server to send a completion response - for some other command (if multiple commands are in progress), or - untagged data. In either case, the command continuation request - is still pending; the client takes the appropriate action for the - response, and reads another response from the server. In all - cases, the client MUST send a complete command (including - receiving all command continuation request responses and command - continuations for the command) before initiating a new command. - - The protocol receiver of an IMAP4rev1 server reads a command line - from the client, parses the command and its arguments, and transmits - server data and a server command completion result response. - - - - - -Crispin Standards Track [Page 6] - -RFC 2060 IMAP4rev1 December 1996 - - -2.2.2. Server Protocol Sender and Client Protocol Receiver - - Data transmitted by the server to the client and status responses - that do not indicate command completion are prefixed with the token - "*", and are called untagged responses. - - Server data MAY be sent as a result of a client command, or MAY be - sent unilaterally by the server. There is no syntactic difference - between server data that resulted from a specific command and server - data that were sent unilaterally. - - The server completion result response indicates the success or - failure of the operation. It is tagged with the same tag as the - client command which began the operation. Thus, if more than one - command is in progress, the tag in a server completion response - identifies the command to which the response applies. There are - three possible server completion responses: OK (indicating success), - NO (indicating failure), or BAD (indicating protocol error such as - unrecognized command or command syntax error). - - The protocol receiver of an IMAP4rev1 client reads a response line - from the server. It then takes action on the response based upon the - first token of the response, which can be a tag, a "*", or a "+". - - A client MUST be prepared to accept any server response at all times. - This includes server data that was not requested. Server data SHOULD - be recorded, so that the client can reference its recorded copy - rather than sending a command to the server to request the data. In - the case of certain server data, the data MUST be recorded. - - This topic is discussed in greater detail in the Server Responses - section. - -2.3. Message Attributes - - In addition to message text, each message has several attributes - associated with it. These attributes may be retrieved individually - or in conjunction with other attributes or message texts. - -2.3.1. Message Numbers - - Messages in IMAP4rev1 are accessed by one of two numbers; the unique - identifier and the message sequence number. - -2.3.1.1. Unique Identifier (UID) Message Attribute - - A 32-bit value assigned to each message, which when used with the - unique identifier validity value (see below) forms a 64-bit value - - - -Crispin Standards Track [Page 7] - -RFC 2060 IMAP4rev1 December 1996 - - - that is permanently guaranteed not to refer to any other message in - the mailbox. Unique identifiers are assigned in a strictly ascending - fashion in the mailbox; as each message is added to the mailbox it is - assigned a higher UID than the message(s) which were added - previously. - - Unlike message sequence numbers, unique identifiers are not - necessarily contiguous. Unique identifiers also persist across - sessions. This permits a client to resynchronize its state from a - previous session with the server (e.g. disconnected or offline access - clients); this is discussed further in [IMAP-DISC]. - - Associated with every mailbox is a unique identifier validity value, - which is sent in an UIDVALIDITY response code in an OK untagged - response at mailbox selection time. If unique identifiers from an - earlier session fail to persist to this session, the unique - identifier validity value MUST be greater than the one used in the - earlier session. - - Note: Unique identifiers MUST be strictly ascending in the mailbox - at all times. If the physical message store is re-ordered by a - non-IMAP agent, this requires that the unique identifiers in the - mailbox be regenerated, since the former unique identifers are no - longer strictly ascending as a result of the re-ordering. Another - instance in which unique identifiers are regenerated is if the - message store has no mechanism to store unique identifiers. - Although this specification recognizes that this may be - unavoidable in certain server environments, it STRONGLY ENCOURAGES - message store implementation techniques that avoid this problem. - - Another cause of non-persistance is if the mailbox is deleted and - a new mailbox with the same name is created at a later date, Since - the name is the same, a client may not know that this is a new - mailbox unless the unique identifier validity is different. A - good value to use for the unique identifier validity value is a - 32-bit representation of the creation date/time of the mailbox. - It is alright to use a constant such as 1, but only if it - guaranteed that unique identifiers will never be reused, even in - the case of a mailbox being deleted (or renamed) and a new mailbox - by the same name created at some future time. - - The unique identifier of a message MUST NOT change during the - session, and SHOULD NOT change between sessions. However, if it is - not possible to preserve the unique identifier of a message in a - subsequent session, each subsequent session MUST have a new unique - identifier validity value that is larger than any that was used - previously. - - - - -Crispin Standards Track [Page 8] - -RFC 2060 IMAP4rev1 December 1996 - - -2.3.1.2. Message Sequence Number Message Attribute - - A relative position from 1 to the number of messages in the mailbox. - This position MUST be ordered by ascending unique identifier. As - each new message is added, it is assigned a message sequence number - that is 1 higher than the number of messages in the mailbox before - that new message was added. - - Message sequence numbers can be reassigned during the session. For - example, when a message is permanently removed (expunged) from the - mailbox, the message sequence number for all subsequent messages is - decremented. Similarly, a new message can be assigned a message - sequence number that was once held by some other message prior to an - expunge. - - In addition to accessing messages by relative position in the - mailbox, message sequence numbers can be used in mathematical - calculations. For example, if an untagged "EXISTS 11" is received, - and previously an untagged "8 EXISTS" was received, three new - messages have arrived with message sequence numbers of 9, 10, and 11. - Another example; if message 287 in a 523 message mailbox has UID - 12345, there are exactly 286 messages which have lesser UIDs and 236 - messages which have greater UIDs. - -2.3.2. Flags Message Attribute - - A list of zero or more named tokens associated with the message. A - flag is set by its addition to this list, and is cleared by its - removal. There are two types of flags in IMAP4rev1. A flag of - either type may be permanent or session-only. - - A system flag is a flag name that is pre-defined in this - specification. All system flags begin with "\". Certain system - flags (\Deleted and \Seen) have special semantics described - elsewhere. The currently-defined system flags are: - - \Seen Message has been read - - \Answered Message has been answered - - \Flagged Message is "flagged" for urgent/special attention - - \Deleted Message is "deleted" for removal by later EXPUNGE - - \Draft Message has not completed composition (marked as a - draft). - - - - - -Crispin Standards Track [Page 9] - -RFC 2060 IMAP4rev1 December 1996 - - - \Recent Message is "recently" arrived in this mailbox. This - session is the first session to have been notified - about this message; subsequent sessions will not see - \Recent set for this message. This flag can not be - altered by the client. - - If it is not possible to determine whether or not - this session is the first session to be notified - about a message, then that message SHOULD be - considered recent. - - If multiple connections have the same mailbox - selected simultaneously, it is undefined which of - these connections will see newly-arrives messages - with \Recent set and which will see it without - \Recent set. - - A keyword is defined by the server implementation. Keywords do - not begin with "\". Servers MAY permit the client to define new - keywords in the mailbox (see the description of the - PERMANENTFLAGS response code for more information). - - A flag may be permanent or session-only on a per-flag basis. - Permanent flags are those which the client can add or remove - from the message flags permanently; that is, subsequent sessions - will see any change in permanent flags. Changes to session - flags are valid only in that session. - - Note: The \Recent system flag is a special case of a - session flag. \Recent can not be used as an argument in a - STORE command, and thus can not be changed at all. - -2.3.3. Internal Date Message Attribute - - The internal date and time of the message on the server. This is not - the date and time in the [RFC-822] header, but rather a date and time - which reflects when the message was received. In the case of - messages delivered via [SMTP], this SHOULD be the date and time of - final delivery of the message as defined by [SMTP]. In the case of - messages delivered by the IMAP4rev1 COPY command, this SHOULD be the - internal date and time of the source message. In the case of - messages delivered by the IMAP4rev1 APPEND command, this SHOULD be - the date and time as specified in the APPEND command description. - All other cases are implementation defined. - - - - - - - -Crispin Standards Track [Page 10] - -RFC 2060 IMAP4rev1 December 1996 - - -2.3.4. [RFC-822] Size Message Attribute - - The number of octets in the message, as expressed in [RFC-822] - format. - -2.3.5. Envelope Structure Message Attribute - - A parsed representation of the [RFC-822] envelope information (not to - be confused with an [SMTP] envelope) of the message. - -2.3.6. Body Structure Message Attribute - - A parsed representation of the [MIME-IMB] body structure information - of the message. - -2.4. Message Texts - - In addition to being able to fetch the full [RFC-822] text of a - message, IMAP4rev1 permits the fetching of portions of the full - message text. Specifically, it is possible to fetch the [RFC-822] - message header, [RFC-822] message body, a [MIME-IMB] body part, or a - [MIME-IMB] header. - -3. State and Flow Diagram - - An IMAP4rev1 server is in one of four states. Most commands are - valid in only certain states. It is a protocol error for the client - to attempt a command while the command is in an inappropriate state. - In this case, a server will respond with a BAD or NO (depending upon - server implementation) command completion result. - -3.1. Non-Authenticated State - - In non-authenticated state, the client MUST supply authentication - credentials before most commands will be permitted. This state is - entered when a connection starts unless the connection has been pre- - authenticated. - -3.2. Authenticated State - - In authenticated state, the client is authenticated and MUST select a - mailbox to access before commands that affect messages will be - permitted. This state is entered when a pre-authenticated connection - starts, when acceptable authentication credentials have been - provided, or after an error in selecting a mailbox. - - - - - - -Crispin Standards Track [Page 11] - -RFC 2060 IMAP4rev1 December 1996 - - -3.3. Selected State - - In selected state, a mailbox has been selected to access. This state - is entered when a mailbox has been successfully selected. - -3.4. Logout State - - In logout state, the connection is being terminated, and the server - will close the connection. This state can be entered as a result of - a client request or by unilateral server decision. - - +--------------------------------------+ - |initial connection and server greeting| - +--------------------------------------+ - || (1) || (2) || (3) - VV || || - +-----------------+ || || - |non-authenticated| || || - +-----------------+ || || - || (7) || (4) || || - || VV VV || - || +----------------+ || - || | authenticated |<=++ || - || +----------------+ || || - || || (7) || (5) || (6) || - || || VV || || - || || +--------+ || || - || || |selected|==++ || - || || +--------+ || - || || || (7) || - VV VV VV VV - +--------------------------------------+ - | logout and close connection | - +--------------------------------------+ - - (1) connection without pre-authentication (OK greeting) - (2) pre-authenticated connection (PREAUTH greeting) - (3) rejected connection (BYE greeting) - (4) successful LOGIN or AUTHENTICATE command - (5) successful SELECT or EXAMINE command - (6) CLOSE command, or failed SELECT or EXAMINE command - (7) LOGOUT command, server shutdown, or connection closed - -4. Data Formats - - IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can - be in one of several forms: atom, number, string, parenthesized list, - or NIL. - - - -Crispin Standards Track [Page 12] - -RFC 2060 IMAP4rev1 December 1996 - - -4.1. Atom - - An atom consists of one or more non-special characters. - -4.2. Number - - A number consists of one or more digit characters, and represents a - numeric value. - -4.3. String - - A string is in one of two forms: literal and quoted string. The - literal form is the general form of string. The quoted string form - is an alternative that avoids the overhead of processing a literal at - the cost of limitations of characters that can be used in a quoted - string. - - A literal is a sequence of zero or more octets (including CR and LF), - prefix-quoted with an octet count in the form of an open brace ("{"), - the number of octets, close brace ("}"), and CRLF. In the case of - literals transmitted from server to client, the CRLF is immediately - followed by the octet data. In the case of literals transmitted from - client to server, the client MUST wait to receive a command - continuation request (described later in this document) before - sending the octet data (and the remainder of the command). - - A quoted string is a sequence of zero or more 7-bit characters, - excluding CR and LF, with double quote (<">) characters at each end. - - The empty string is represented as either "" (a quoted string with - zero characters between double quotes) or as {0} followed by CRLF (a - literal with an octet count of 0). - - Note: Even if the octet count is 0, a client transmitting a - literal MUST wait to receive a command continuation request. - -4.3.1. 8-bit and Binary Strings - - 8-bit textual and binary mail is supported through the use of a - [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY - transmit 8-bit or multi-octet characters in literals, but SHOULD do - so only when the [CHARSET] is identified. - - - - - - - - - -Crispin Standards Track [Page 13] - -RFC 2060 IMAP4rev1 December 1996 - - - Although a BINARY body encoding is defined, unencoded binary strings - are not permitted. A "binary string" is any string with NUL - characters. Implementations MUST encode binary data into a textual - form such as BASE64 before transmitting the data. A string with an - excessive amount of CTL characters MAY also be considered to be - binary. - -4.4. Parenthesized List - - Data structures are represented as a "parenthesized list"; a sequence - of data items, delimited by space, and bounded at each end by - parentheses. A parenthesized list can contain other parenthesized - lists, using multiple levels of parentheses to indicate nesting. - - The empty list is represented as () -- a parenthesized list with no - members. - -4.5. NIL - - The special atom "NIL" represents the non-existence of a particular - data item that is represented as a string or parenthesized list, as - distinct from the empty string "" or the empty parenthesized list (). - -5. Operational Considerations - -5.1. Mailbox Naming - - The interpretation of mailbox names is implementation-dependent. - However, the case-insensitive mailbox name INBOX is a special name - reserved to mean "the primary mailbox for this user on this server". - -5.1.1. Mailbox Hierarchy Naming - - If it is desired to export hierarchical mailbox names, mailbox names - MUST be left-to-right hierarchical using a single character to - separate levels of hierarchy. The same hierarchy separator character - is used for all levels of hierarchy within a single name. - -5.1.2. Mailbox Namespace Naming Convention - - By convention, the first hierarchical element of any mailbox name - which begins with "#" identifies the "namespace" of the remainder of - the name. This makes it possible to disambiguate between different - types of mailbox stores, each of which have their own namespaces. - - - - - - - -Crispin Standards Track [Page 14] - -RFC 2060 IMAP4rev1 December 1996 - - - For example, implementations which offer access to USENET - newsgroups MAY use the "#news" namespace to partition the USENET - newsgroup namespace from that of other mailboxes. Thus, the - comp.mail.misc newsgroup would have an mailbox name of - "#news.comp.mail.misc", and the name "comp.mail.misc" could refer - to a different object (e.g. a user's private mailbox). - -5.1.3. Mailbox International Naming Convention - - By convention, international mailbox names are specified using a - modified version of the UTF-7 encoding described in [UTF-7]. The - purpose of these modifications is to correct the following problems - with UTF-7: - - 1) UTF-7 uses the "+" character for shifting; this conflicts with - the common use of "+" in mailbox names, in particular USENET - newsgroup names. - - 2) UTF-7's encoding is BASE64 which uses the "/" character; this - conflicts with the use of "/" as a popular hierarchy delimiter. - - 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with - the use of "\" as a popular hierarchy delimiter. - - 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with - the use of "~" in some servers as a home directory indicator. - - 5) UTF-7 permits multiple alternate forms to represent the same - string; in particular, printable US-ASCII chararacters can be - represented in encoded form. - - In modified UTF-7, printable US-ASCII characters except for "&" - represent themselves; that is, characters with octet values 0x20-0x25 - and 0x27-0x7e. The character "&" (0x26) is represented by the two- - octet sequence "&-". - - All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all - Unicode 16-bit octets) are represented in modified BASE64, with a - further modification from [UTF-7] that "," is used instead of "/". - Modified BASE64 MUST NOT be used to represent any printing US-ASCII - character which can represent itself. - - "&" is used to shift to modified BASE64 and "-" to shift back to US- - ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that - is, a name that ends with a Unicode 16-bit octet MUST end with a "- - "). - - - - - -Crispin Standards Track [Page 15] - -RFC 2060 IMAP4rev1 December 1996 - - - For example, here is a mailbox name which mixes English, Japanese, - and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw- - -5.2. Mailbox Size and Message Status Updates - - At any time, a server can send data that the client did not request. - Sometimes, such behavior is REQUIRED. For example, agents other than - the server MAY add messages to the mailbox (e.g. new mail delivery), - change the flags of message in the mailbox (e.g. simultaneous access - to the same mailbox by multiple agents), or even remove messages from - the mailbox. A server MUST send mailbox size updates automatically - if a mailbox size change is observed during the processing of a - command. A server SHOULD send message flag updates automatically, - without requiring the client to request such updates explicitly. - Special rules exist for server notification of a client about the - removal of messages to prevent synchronization errors; see the - description of the EXPUNGE response for more detail. - - Regardless of what implementation decisions a client makes on - remembering data from the server, a client implementation MUST record - mailbox size updates. It MUST NOT assume that any command after - initial mailbox selection will return the size of the mailbox. - -5.3. Response when no Command in Progress - - Server implementations are permitted to send an untagged response - (except for EXPUNGE) while there is no command in progress. Server - implementations that send such responses MUST deal with flow control - considerations. Specifically, they MUST either (1) verify that the - size of the data does not exceed the underlying transport's available - window size, or (2) use non-blocking writes. - -5.4. Autologout Timer - - If a server has an inactivity autologout timer, that timer MUST be of - at least 30 minutes' duration. The receipt of ANY command from the - client during that interval SHOULD suffice to reset the autologout - timer. - - - - - - - - - - - - - -Crispin Standards Track [Page 16] - -RFC 2060 IMAP4rev1 December 1996 - - -5.5. Multiple Commands in Progress - - The client MAY send another command without waiting for the - completion result response of a command, subject to ambiguity rules - (see below) and flow control constraints on the underlying data - stream. Similarly, a server MAY begin processing another command - before processing the current command to completion, subject to - ambiguity rules. However, any command continuation request responses - and command continuations MUST be negotiated before any subsequent - command is initiated. - - The exception is if an ambiguity would result because of a command - that would affect the results of other commands. Clients MUST NOT - send multiple commands without waiting if an ambiguity would result. - If the server detects a possible ambiguity, it MUST execute commands - to completion in the order given by the client. - - The most obvious example of ambiguity is when a command would affect - the results of another command; for example, a FETCH of a message's - flags and a STORE of that same message's flags. - - A non-obvious ambiguity occurs with commands that permit an untagged - EXPUNGE response (commands other than FETCH, STORE, and SEARCH), - since an untagged EXPUNGE response can invalidate sequence numbers in - a subsequent command. This is not a problem for FETCH, STORE, or - SEARCH commands because servers are prohibited from sending EXPUNGE - responses while any of those commands are in progress. Therefore, if - the client sends any command other than FETCH, STORE, or SEARCH, it - MUST wait for a response before sending a command with message - sequence numbers. - - For example, the following non-waiting command sequences are invalid: - - FETCH + NOOP + STORE - STORE + COPY + FETCH - COPY + COPY - CHECK + FETCH - - The following are examples of valid non-waiting command sequences: - - FETCH + STORE + SEARCH + CHECK - STORE + COPY + EXPUNGE - -6. Client Commands - - IMAP4rev1 commands are described in this section. Commands are - organized by the state in which the command is permitted. Commands - which are permitted in multiple states are listed in the minimum - - - -Crispin Standards Track [Page 17] - -RFC 2060 IMAP4rev1 December 1996 - - - permitted state (for example, commands valid in authenticated and - selected state are listed in the authenticated state commands). - - Command arguments, identified by "Arguments:" in the command - descriptions below, are described by function, not by syntax. The - precise syntax of command arguments is described in the Formal Syntax - section. - - Some commands cause specific server responses to be returned; these - are identified by "Responses:" in the command descriptions below. - See the response descriptions in the Responses section for - information on these responses, and the Formal Syntax section for the - precise syntax of these responses. It is possible for server data to - be transmitted as a result of any command; thus, commands that do not - specifically require server data specify "no specific responses for - this command" instead of "none". - - The "Result:" in the command description refers to the possible - tagged status responses to a command, and any special interpretation - of these status responses. - -6.1. Client Commands - Any State - - The following commands are valid in any state: CAPABILITY, NOOP, and - LOGOUT. - -6.1.1. CAPABILITY Command - - Arguments: none - - Responses: REQUIRED untagged response: CAPABILITY - - Result: OK - capability completed - BAD - command unknown or arguments invalid - - The CAPABILITY command requests a listing of capabilities that the - server supports. The server MUST send a single untagged - CAPABILITY response with "IMAP4rev1" as one of the listed - capabilities before the (tagged) OK response. This listing of - capabilities is not dependent upon connection state or user. It - is therefore not necessary to issue a CAPABILITY command more than - once in a connection. - - - - - - - - - -Crispin Standards Track [Page 18] - -RFC 2060 IMAP4rev1 December 1996 - - - A capability name which begins with "AUTH=" indicates that the - server supports that particular authentication mechanism. All - such names are, by definition, part of this specification. For - example, the authorization capability for an experimental - "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not - "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". - - Other capability names refer to extensions, revisions, or - amendments to this specification. See the documentation of the - CAPABILITY response for additional information. No capabilities, - beyond the base IMAP4rev1 set defined in this specification, are - enabled without explicit client action to invoke the capability. - - See the section entitled "Client Commands - - Experimental/Expansion" for information about the form of site or - implementation-specific capabilities. - - Example: C: abcd CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 - S: abcd OK CAPABILITY completed - -6.1.2. NOOP Command - - Arguments: none - - Responses: no specific responses for this command (but see below) - - Result: OK - noop completed - BAD - command unknown or arguments invalid - - The NOOP command always succeeds. It does nothing. - - Since any command can return a status update as untagged data, the - NOOP command can be used as a periodic poll for new messages or - message status updates during a period of inactivity. The NOOP - command can also be used to reset any inactivity autologout timer - on the server. - - Example: C: a002 NOOP - S: a002 OK NOOP completed - . . . - C: a047 NOOP - S: * 22 EXPUNGE - S: * 23 EXISTS - S: * 3 RECENT - S: * 14 FETCH (FLAGS (\Seen \Deleted)) - S: a047 OK NOOP completed - - - - -Crispin Standards Track [Page 19] - -RFC 2060 IMAP4rev1 December 1996 - - -6.1.3. LOGOUT Command - - Arguments: none - - Responses: REQUIRED untagged response: BYE - - Result: OK - logout completed - BAD - command unknown or arguments invalid - - The LOGOUT command informs the server that the client is done with - the connection. The server MUST send a BYE untagged response - before the (tagged) OK response, and then close the network - connection. - - Example: C: A023 LOGOUT - S: * BYE IMAP4rev1 Server logging out - S: A023 OK LOGOUT completed - (Server and client then close the connection) - -6.2. Client Commands - Non-Authenticated State - - In non-authenticated state, the AUTHENTICATE or LOGIN command - establishes authentication and enter authenticated state. The - AUTHENTICATE command provides a general mechanism for a variety of - authentication techniques, whereas the LOGIN command uses the - traditional user name and plaintext password pair. - - Server implementations MAY allow non-authenticated access to certain - mailboxes. The convention is to use a LOGIN command with the userid - "anonymous". A password is REQUIRED. It is implementation-dependent - what requirements, if any, are placed on the password and what access - restrictions are placed on anonymous users. - - Once authenticated (including as anonymous), it is not possible to - re-enter non-authenticated state. - - In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), - the following commands are valid in non-authenticated state: - AUTHENTICATE and LOGIN. - - - - - - - - - - - - -Crispin Standards Track [Page 20] - -RFC 2060 IMAP4rev1 December 1996 - - -6.2.1. AUTHENTICATE Command - - Arguments: authentication mechanism name - - Responses: continuation data can be requested - - Result: OK - authenticate completed, now in authenticated state - NO - authenticate failure: unsupported authentication - mechanism, credentials rejected - BAD - command unknown or arguments invalid, - authentication exchange cancelled - - The AUTHENTICATE command indicates an authentication mechanism, - such as described in [IMAP-AUTH], to the server. If the server - supports the requested authentication mechanism, it performs an - authentication protocol exchange to authenticate and identify the - client. It MAY also negotiate an OPTIONAL protection mechanism - for subsequent protocol interactions. If the requested - authentication mechanism is not supported, the server SHOULD - reject the AUTHENTICATE command by sending a tagged NO response. - - The authentication protocol exchange consists of a series of - server challenges and client answers that are specific to the - authentication mechanism. A server challenge consists of a - command continuation request response with the "+" token followed - by a BASE64 encoded string. The client answer consists of a line - consisting of a BASE64 encoded string. If the client wishes to - cancel an authentication exchange, it issues a line with a single - "*". If the server receives such an answer, it MUST reject the - AUTHENTICATE command by sending a tagged BAD response. - - A protection mechanism provides integrity and privacy protection - to the connection. If a protection mechanism is negotiated, it is - applied to all subsequent data sent over the connection. The - protection mechanism takes effect immediately following the CRLF - that concludes the authentication exchange for the client, and the - CRLF of the tagged OK response for the server. Once the - protection mechanism is in effect, the stream of command and - response octets is processed into buffers of ciphertext. Each - buffer is transferred over the connection as a stream of octets - prepended with a four octet field in network byte order that - represents the length of the following data. The maximum - ciphertext buffer length is defined by the protection mechanism. - - Authentication mechanisms are OPTIONAL. Protection mechanisms are - also OPTIONAL; an authentication mechanism MAY be implemented - without any protection mechanism. If an AUTHENTICATE command - fails with a NO response, the client MAY try another - - - -Crispin Standards Track [Page 21] - -RFC 2060 IMAP4rev1 December 1996 - - - authentication mechanism by issuing another AUTHENTICATE command, - or MAY attempt to authenticate by using the LOGIN command. In - other words, the client MAY request authentication types in - decreasing order of preference, with the LOGIN command as a last - resort. - - Example: S: * OK KerberosV4 IMAP4rev1 Server - C: A001 AUTHENTICATE KERBEROS_V4 - S: + AmFYig== - C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT - +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd - WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh - S: + or//EoAADZI= - C: DiAF5A4gA+oOIALuBkAAmw== - S: A001 OK Kerberos V4 authentication successful - - Note: the line breaks in the first client answer are for editorial - clarity and are not in real authenticators. - -6.2.2. LOGIN Command - - Arguments: user name - password - - Responses: no specific responses for this command - - Result: OK - login completed, now in authenticated state - NO - login failure: user name or password rejected - BAD - command unknown or arguments invalid - - The LOGIN command identifies the client to the server and carries - the plaintext password authenticating this user. - - Example: C: a001 LOGIN SMITH SESAME - S: a001 OK LOGIN completed - -6.3. Client Commands - Authenticated State - - In authenticated state, commands that manipulate mailboxes as atomic - entities are permitted. Of these commands, the SELECT and EXAMINE - commands will select a mailbox for access and enter selected state. - - In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), - the following commands are valid in authenticated state: SELECT, - EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, - STATUS, and APPEND. - - - - - -Crispin Standards Track [Page 22] - -RFC 2060 IMAP4rev1 December 1996 - - -6.3.1. SELECT Command - - Arguments: mailbox name - - Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT - OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS - - Result: OK - select completed, now in selected state - NO - select failure, now in authenticated state: no - such mailbox, can't access mailbox - BAD - command unknown or arguments invalid - - The SELECT command selects a mailbox so that messages in the - mailbox can be accessed. Before returning an OK to the client, - the server MUST send the following untagged data to the client: - - FLAGS Defined flags in the mailbox. See the description - of the FLAGS response for more detail. - - <n> EXISTS The number of messages in the mailbox. See the - description of the EXISTS response for more detail. - - <n> RECENT The number of messages with the \Recent flag set. - See the description of the RECENT response for more - detail. - - OK [UIDVALIDITY <n>] - The unique identifier validity value. See the - description of the UID command for more detail. - - to define the initial state of the mailbox at the client. - - The server SHOULD also send an UNSEEN response code in an OK - untagged response, indicating the message sequence number of the - first unseen message in the mailbox. - - If the client can not change the permanent state of one or more of - the flags listed in the FLAGS untagged response, the server SHOULD - send a PERMANENTFLAGS response code in an OK untagged response, - listing the flags that the client can change permanently. - - Only one mailbox can be selected at a time in a connection; - simultaneous access to multiple mailboxes requires multiple - connections. The SELECT command automatically deselects any - currently selected mailbox before attempting the new selection. - Consequently, if a mailbox is selected and a SELECT command that - fails is attempted, no mailbox is selected. - - - - -Crispin Standards Track [Page 23] - -RFC 2060 IMAP4rev1 December 1996 - - - If the client is permitted to modify the mailbox, the server - SHOULD prefix the text of the tagged OK response with the - "[READ-WRITE]" response code. - - If the client is not permitted to modify the mailbox but is - permitted read access, the mailbox is selected as read-only, and - the server MUST prefix the text of the tagged OK response to - SELECT with the "[READ-ONLY]" response code. Read-only access - through SELECT differs from the EXAMINE command in that certain - read-only mailboxes MAY permit the change of permanent state on a - per-user (as opposed to global) basis. Netnews messages marked in - a server-based .newsrc file are an example of such per-user - permanent state that can be modified with read-only mailboxes. - - Example: C: A142 SELECT INBOX - S: * 172 EXISTS - S: * 1 RECENT - S: * OK [UNSEEN 12] Message 12 is first unseen - S: * OK [UIDVALIDITY 3857529045] UIDs valid - S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) - S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited - S: A142 OK [READ-WRITE] SELECT completed - -6.3.2. EXAMINE Command - - Arguments: mailbox name - - Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT - OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS - - Result: OK - examine completed, now in selected state - NO - examine failure, now in authenticated state: no - such mailbox, can't access mailbox - BAD - command unknown or arguments invalid - - The EXAMINE command is identical to SELECT and returns the same - output; however, the selected mailbox is identified as read-only. - No changes to the permanent state of the mailbox, including - per-user state, are permitted. - - - - - - - - - - - - -Crispin Standards Track [Page 24] - -RFC 2060 IMAP4rev1 December 1996 - - - The text of the tagged OK response to the EXAMINE command MUST - begin with the "[READ-ONLY]" response code. - - Example: C: A932 EXAMINE blurdybloop - S: * 17 EXISTS - S: * 2 RECENT - S: * OK [UNSEEN 8] Message 8 is first unseen - S: * OK [UIDVALIDITY 3857529045] UIDs valid - S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) - S: * OK [PERMANENTFLAGS ()] No permanent flags permitted - S: A932 OK [READ-ONLY] EXAMINE completed - -6.3.3. CREATE Command - - Arguments: mailbox name - - Responses: no specific responses for this command - - Result: OK - create completed - NO - create failure: can't create mailbox with that name - BAD - command unknown or arguments invalid - - The CREATE command creates a mailbox with the given name. An OK - response is returned only if a new mailbox with that name has been - created. It is an error to attempt to create INBOX or a mailbox - with a name that refers to an extant mailbox. Any error in - creation will return a tagged NO response. - - If the mailbox name is suffixed with the server's hierarchy - separator character (as returned from the server by a LIST - command), this is a declaration that the client intends to create - mailbox names under this name in the hierarchy. Server - implementations that do not require this declaration MUST ignore - it. - - If the server's hierarchy separator character appears elsewhere in - the name, the server SHOULD create any superior hierarchical names - that are needed for the CREATE command to complete successfully. - In other words, an attempt to create "foo/bar/zap" on a server in - which "/" is the hierarchy separator character SHOULD create foo/ - and foo/bar/ if they do not already exist. - - If a new mailbox is created with the same name as a mailbox which - was deleted, its unique identifiers MUST be greater than any - unique identifiers used in the previous incarnation of the mailbox - UNLESS the new incarnation has a different unique identifier - validity value. See the description of the UID command for more - detail. - - - -Crispin Standards Track [Page 25] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A003 CREATE owatagusiam/ - S: A003 OK CREATE completed - C: A004 CREATE owatagusiam/blurdybloop - S: A004 OK CREATE completed - - Note: the interpretation of this example depends on whether "/" - was returned as the hierarchy separator from LIST. If "/" is the - hierarchy separator, a new level of hierarchy named "owatagusiam" - with a member called "blurdybloop" is created. Otherwise, two - mailboxes at the same hierarchy level are created. - -6.3.4. DELETE Command - - Arguments: mailbox name - - Responses: no specific responses for this command - - Result: OK - delete completed - NO - delete failure: can't delete mailbox with that name - BAD - command unknown or arguments invalid - - The DELETE command permanently removes the mailbox with the given - name. A tagged OK response is returned only if the mailbox has - been deleted. It is an error to attempt to delete INBOX or a - mailbox name that does not exist. - - The DELETE command MUST NOT remove inferior hierarchical names. - For example, if a mailbox "foo" has an inferior "foo.bar" - (assuming "." is the hierarchy delimiter character), removing - "foo" MUST NOT remove "foo.bar". It is an error to attempt to - delete a name that has inferior hierarchical names and also has - the \Noselect mailbox name attribute (see the description of the - LIST response for more details). - - It is permitted to delete a name that has inferior hierarchical - names and does not have the \Noselect mailbox name attribute. In - this case, all messages in that mailbox are removed, and the name - will acquire the \Noselect mailbox name attribute. - - The value of the highest-used unique identifier of the deleted - mailbox MUST be preserved so that a new mailbox created with the - same name will not reuse the identifiers of the former - incarnation, UNLESS the new incarnation has a different unique - identifier validity value. See the description of the UID command - for more detail. - - - - - - -Crispin Standards Track [Page 26] - -RFC 2060 IMAP4rev1 December 1996 - - - Examples: C: A682 LIST "" * - S: * LIST () "/" blurdybloop - S: * LIST (\Noselect) "/" foo - S: * LIST () "/" foo/bar - S: A682 OK LIST completed - C: A683 DELETE blurdybloop - S: A683 OK DELETE completed - C: A684 DELETE foo - S: A684 NO Name "foo" has inferior hierarchical names - C: A685 DELETE foo/bar - S: A685 OK DELETE Completed - C: A686 LIST "" * - S: * LIST (\Noselect) "/" foo - S: A686 OK LIST completed - C: A687 DELETE foo - S: A687 OK DELETE Completed - - - C: A82 LIST "" * - S: * LIST () "." blurdybloop - S: * LIST () "." foo - S: * LIST () "." foo.bar - S: A82 OK LIST completed - C: A83 DELETE blurdybloop - S: A83 OK DELETE completed - C: A84 DELETE foo - S: A84 OK DELETE Completed - C: A85 LIST "" * - S: * LIST () "." foo.bar - S: A85 OK LIST completed - C: A86 LIST "" % - S: * LIST (\Noselect) "." foo - S: A86 OK LIST completed - -6.3.5. RENAME Command - - Arguments: existing mailbox name - new mailbox name - - Responses: no specific responses for this command - - Result: OK - rename completed - NO - rename failure: can't rename mailbox with that name, - can't rename to mailbox with that name - BAD - command unknown or arguments invalid - - The RENAME command changes the name of a mailbox. A tagged OK - response is returned only if the mailbox has been renamed. It is - - - -Crispin Standards Track [Page 27] - -RFC 2060 IMAP4rev1 December 1996 - - - an error to attempt to rename from a mailbox name that does not - exist or to a mailbox name that already exists. Any error in - renaming will return a tagged NO response. - - If the name has inferior hierarchical names, then the inferior - hierarchical names MUST also be renamed. For example, a rename of - "foo" to "zap" will rename "foo/bar" (assuming "/" is the - hierarchy delimiter character) to "zap/bar". - - The value of the highest-used unique identifier of the old mailbox - name MUST be preserved so that a new mailbox created with the same - name will not reuse the identifiers of the former incarnation, - UNLESS the new incarnation has a different unique identifier - validity value. See the description of the UID command for more - detail. - - Renaming INBOX is permitted, and has special behavior. It moves - all messages in INBOX to a new mailbox with the given name, - leaving INBOX empty. If the server implementation supports - inferior hierarchical names of INBOX, these are unaffected by a - rename of INBOX. - - Examples: C: A682 LIST "" * - S: * LIST () "/" blurdybloop - S: * LIST (\Noselect) "/" foo - S: * LIST () "/" foo/bar - S: A682 OK LIST completed - C: A683 RENAME blurdybloop sarasoop - S: A683 OK RENAME completed - C: A684 RENAME foo zowie - S: A684 OK RENAME Completed - C: A685 LIST "" * - S: * LIST () "/" sarasoop - S: * LIST (\Noselect) "/" zowie - S: * LIST () "/" zowie/bar - S: A685 OK LIST completed - - - - - - - - - - - - - - - -Crispin Standards Track [Page 28] - -RFC 2060 IMAP4rev1 December 1996 - - - C: Z432 LIST "" * - S: * LIST () "." INBOX - S: * LIST () "." INBOX.bar - S: Z432 OK LIST completed - C: Z433 RENAME INBOX old-mail - S: Z433 OK RENAME completed - C: Z434 LIST "" * - S: * LIST () "." INBOX - S: * LIST () "." INBOX.bar - S: * LIST () "." old-mail - S: Z434 OK LIST completed - -6.3.6. SUBSCRIBE Command - - Arguments: mailbox - - Responses: no specific responses for this command - - Result: OK - subscribe completed - NO - subscribe failure: can't subscribe to that name - BAD - command unknown or arguments invalid - - The SUBSCRIBE command adds the specified mailbox name to the - server's set of "active" or "subscribed" mailboxes as returned by - the LSUB command. This command returns a tagged OK response only - if the subscription is successful. - - A server MAY validate the mailbox argument to SUBSCRIBE to verify - that it exists. However, it MUST NOT unilaterally remove an - existing mailbox name from the subscription list even if a mailbox - by that name no longer exists. - - Note: this requirement is because some server sites may routinely - remove a mailbox with a well-known name (e.g. "system-alerts") - after its contents expire, with the intention of recreating it - when new contents are appropriate. - - Example: C: A002 SUBSCRIBE #news.comp.mail.mime - S: A002 OK SUBSCRIBE completed - - - - - - - - - - - - -Crispin Standards Track [Page 29] - -RFC 2060 IMAP4rev1 December 1996 - - -6.3.7. UNSUBSCRIBE Command - - Arguments: mailbox name - - Responses: no specific responses for this command - - Result: OK - unsubscribe completed - NO - unsubscribe failure: can't unsubscribe that name - BAD - command unknown or arguments invalid - - The UNSUBSCRIBE command removes the specified mailbox name from - the server's set of "active" or "subscribed" mailboxes as returned - by the LSUB command. This command returns a tagged OK response - only if the unsubscription is successful. - - Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime - S: A002 OK UNSUBSCRIBE completed - -6.3..8. LIST Command - - Arguments: reference name - mailbox name with possible wildcards - - Responses: untagged responses: LIST - - Result: OK - list completed - NO - list failure: can't list that reference or name - BAD - command unknown or arguments invalid - - The LIST command returns a subset of names from the complete set - of all names available to the client. Zero or more untagged LIST - replies are returned, containing the name attributes, hierarchy - delimiter, and name; see the description of the LIST reply for - more detail. - - The LIST command SHOULD return its data quickly, without undue - delay. For example, it SHOULD NOT go to excess trouble to - calculate \Marked or \Unmarked status or perform other processing; - if each name requires 1 second of processing, then a list of 1200 - names would take 20 minutes! - - An empty ("" string) reference name argument indicates that the - mailbox name is interpreted as by SELECT. The returned mailbox - names MUST match the supplied mailbox name pattern. A non-empty - reference name argument is the name of a mailbox or a level of - mailbox hierarchy, and indicates a context in which the mailbox - name is interpreted in an implementation-defined manner. - - - - -Crispin Standards Track [Page 30] - -RFC 2060 IMAP4rev1 December 1996 - - - An empty ("" string) mailbox name argument is a special request to - return the hierarchy delimiter and the root name of the name given - in the reference. The value returned as the root MAY be null if - the reference is non-rooted or is null. In all cases, the - hierarchy delimiter is returned. This permits a client to get the - hierarchy delimiter even when no mailboxes by that name currently - exist. - - The reference and mailbox name arguments are interpreted, in an - implementation-dependent fashion, into a canonical form that - represents an unambiguous left-to-right hierarchy. The returned - mailbox names will be in the interpreted form. - - Any part of the reference argument that is included in the - interpreted form SHOULD prefix the interpreted form. It SHOULD - also be in the same form as the reference name argument. This - rule permits the client to determine if the returned mailbox name - is in the context of the reference argument, or if something about - the mailbox argument overrode the reference argument. Without - this rule, the client would have to have knowledge of the server's - naming semantics including what characters are "breakouts" that - override a naming context. - - For example, here are some examples of how references and mailbox - names might be interpreted on a UNIX-based server: - - Reference Mailbox Name Interpretation - ------------ ------------ -------------- - ~smith/Mail/ foo.* ~smith/Mail/foo.* - archive/ % archive/% - #news. comp.mail.* #news.comp.mail.* - ~smith/Mail/ /usr/doc/foo /usr/doc/foo - archive/ ~fred/Mail/* ~fred/Mail/* - - The first three examples demonstrate interpretations in the - context of the reference argument. Note that "~smith/Mail" SHOULD - NOT be transformed into something like "/u2/users/smith/Mail", or - it would be impossible for the client to determine that the - interpretation was in the context of the reference. - - The character "*" is a wildcard, and matches zero or more - characters at this position. The character "%" is similar to "*", - but it does not match a hierarchy delimiter. If the "%" wildcard - is the last character of a mailbox name argument, matching levels - of hierarchy are also returned. If these levels of hierarchy are - not also selectable mailboxes, they are returned with the - \Noselect mailbox name attribute (see the description of the LIST - response for more details). - - - -Crispin Standards Track [Page 31] - -RFC 2060 IMAP4rev1 December 1996 - - - Server implementations are permitted to "hide" otherwise - accessible mailboxes from the wildcard characters, by preventing - certain characters or names from matching a wildcard in certain - situations. For example, a UNIX-based server might restrict the - interpretation of "*" so that an initial "/" character does not - match. - - The special name INBOX is included in the output from LIST, if - INBOX is supported by this server for this user and if the - uppercase string "INBOX" matches the interpreted reference and - mailbox name arguments with wildcards as described above. The - criteria for omitting INBOX is whether SELECT INBOX will return - failure; it is not relevant whether the user's real INBOX resides - on this or some other server. - - Example: C: A101 LIST "" "" - S: * LIST (\Noselect) "/" "" - S: A101 OK LIST Completed - C: A102 LIST #news.comp.mail.misc "" - S: * LIST (\Noselect) "." #news. - S: A102 OK LIST Completed - C: A103 LIST /usr/staff/jones "" - S: * LIST (\Noselect) "/" / - S: A103 OK LIST Completed - C: A202 LIST ~/Mail/ % - S: * LIST (\Noselect) "/" ~/Mail/foo - S: * LIST () "/" ~/Mail/meetings - S: A202 OK LIST completed - -6.3.9. LSUB Command - - Arguments: reference name - mailbox name with possible wildcards - - Responses: untagged responses: LSUB - - Result: OK - lsub completed - NO - lsub failure: can't list that reference or name - BAD - command unknown or arguments invalid - - The LSUB command returns a subset of names from the set of names - that the user has declared as being "active" or "subscribed". - Zero or more untagged LSUB replies are returned. The arguments to - LSUB are in the same form as those for LIST. - - A server MAY validate the subscribed names to see if they still - exist. If a name does not exist, it SHOULD be flagged with the - \Noselect attribute in the LSUB response. The server MUST NOT - - - -Crispin Standards Track [Page 32] - -RFC 2060 IMAP4rev1 December 1996 - - - unilaterally remove an existing mailbox name from the subscription - list even if a mailbox by that name no longer exists. - - Example: C: A002 LSUB "#news." "comp.mail.*" - S: * LSUB () "." #news.comp.mail.mime - S: * LSUB () "." #news.comp.mail.misc - S: A002 OK LSUB completed - -6.3.10. STATUS Command - - Arguments: mailbox name - status data item names - - Responses: untagged responses: STATUS - - Result: OK - status completed - NO - status failure: no status for that name - BAD - command unknown or arguments invalid - - The STATUS command requests the status of the indicated mailbox. - It does not change the currently selected mailbox, nor does it - affect the state of any messages in the queried mailbox (in - particular, STATUS MUST NOT cause messages to lose the \Recent - flag). - - The STATUS command provides an alternative to opening a second - IMAP4rev1 connection and doing an EXAMINE command on a mailbox to - query that mailbox's status without deselecting the current - mailbox in the first IMAP4rev1 connection. - - Unlike the LIST command, the STATUS command is not guaranteed to - be fast in its response. In some implementations, the server is - obliged to open the mailbox read-only internally to obtain certain - status information. Also unlike the LIST command, the STATUS - command does not accept wildcards. - - The currently defined status data items that can be requested are: - - MESSAGES The number of messages in the mailbox. - - RECENT The number of messages with the \Recent flag set. - - UIDNEXT The next UID value that will be assigned to a new - message in the mailbox. It is guaranteed that this - value will not change unless new messages are added - to the mailbox; and that it will change when new - messages are added even if those new messages are - subsequently expunged. - - - -Crispin Standards Track [Page 33] - -RFC 2060 IMAP4rev1 December 1996 - - - UIDVALIDITY The unique identifier validity value of the - mailbox. - - UNSEEN The number of messages which do not have the \Seen - flag set. - - - Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) - S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) - S: A042 OK STATUS completed - -6.3.11. APPEND Command - - Arguments: mailbox name - OPTIONAL flag parenthesized list - OPTIONAL date/time string - message literal - - Responses: no specific responses for this command - - Result: OK - append completed - NO - append error: can't append to that mailbox, error - in flags or date/time or message text - BAD - command unknown or arguments invalid - - The APPEND command appends the literal argument as a new message - to the end of the specified destination mailbox. This argument - SHOULD be in the format of an [RFC-822] message. 8-bit characters - are permitted in the message. A server implementation that is - unable to preserve 8-bit data properly MUST be able to reversibly - convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content - transfer encoding. - - Note: There MAY be exceptions, e.g. draft messages, in which - required [RFC-822] header lines are omitted in the message literal - argument to APPEND. The full implications of doing so MUST be - understood and carefully weighed. - - If a flag parenthesized list is specified, the flags SHOULD be set in - the resulting message; otherwise, the flag list of the resulting - message is set empty by default. - - If a date_time is specified, the internal date SHOULD be set in the - resulting message; otherwise, the internal date of the resulting - message is set to the current date and time by default. - - - - - - -Crispin Standards Track [Page 34] - -RFC 2060 IMAP4rev1 December 1996 - - - If the append is unsuccessful for any reason, the mailbox MUST be - restored to its state before the APPEND attempt; no partial appending - is permitted. - - If the destination mailbox does not exist, a server MUST return an - error, and MUST NOT automatically create the mailbox. Unless it is - certain that the destination mailbox can not be created, the server - MUST send the response code "[TRYCREATE]" as the prefix of the text - of the tagged NO response. This gives a hint to the client that it - can attempt a CREATE command and retry the APPEND if the CREATE is - successful. - - If the mailbox is currently selected, the normal new mail actions - SHOULD occur. Specifically, the server SHOULD notify the client - immediately via an untagged EXISTS response. If the server does not - do so, the client MAY issue a NOOP command (or failing that, a CHECK - command) after one or more APPEND commands. - - Example: C: A003 APPEND saved-messages (\Seen) {310} - C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) - C: From: Fred Foobar <foobar@Blurdybloop.COM> - C: Subject: afternoon meeting - C: To: mooch@owatagu.siam.edu - C: Message-Id: <B27397-0100000@Blurdybloop.COM> - C: MIME-Version: 1.0 - C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII - C: - C: Hello Joe, do you think we can meet at 3:30 tomorrow? - C: - S: A003 OK APPEND completed - - Note: the APPEND command is not used for message delivery, because - it does not provide a mechanism to transfer [SMTP] envelope - information. - -6.4. Client Commands - Selected State - - In selected state, commands that manipulate messages in a mailbox are - permitted. - - In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), - and the authenticated state commands (SELECT, EXAMINE, CREATE, - DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and - APPEND), the following commands are valid in the selected state: - CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. - - - - - - -Crispin Standards Track [Page 35] - -RFC 2060 IMAP4rev1 December 1996 - - -6.4.1. CHECK Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - check completed - BAD - command unknown or arguments invalid - - The CHECK command requests a checkpoint of the currently selected - mailbox. A checkpoint refers to any implementation-dependent - housekeeping associated with the mailbox (e.g. resolving the - server's in-memory state of the mailbox with the state on its - disk) that is not normally executed as part of each command. A - checkpoint MAY take a non-instantaneous amount of real time to - complete. If a server implementation has no such housekeeping - considerations, CHECK is equivalent to NOOP. - - There is no guarantee that an EXISTS untagged response will happen - as a result of CHECK. NOOP, not CHECK, SHOULD be used for new - mail polling. - - Example: C: FXXZ CHECK - S: FXXZ OK CHECK Completed - -6.4.2. CLOSE Command - - Arguments: none - - Responses: no specific responses for this command - - Result: OK - close completed, now in authenticated state - NO - close failure: no mailbox selected - BAD - command unknown or arguments invalid - - The CLOSE command permanently removes from the currently selected - mailbox all messages that have the \Deleted flag set, and returns - to authenticated state from selected state. No untagged EXPUNGE - responses are sent. - - No messages are removed, and no error is given, if the mailbox is - selected by an EXAMINE command or is otherwise selected read-only. - - Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT - command MAY be issued without previously issuing a CLOSE command. - The SELECT, EXAMINE, and LOGOUT commands implicitly close the - currently selected mailbox without doing an expunge. However, - when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT - - - -Crispin Standards Track [Page 36] - -RFC 2060 IMAP4rev1 December 1996 - - - sequence is considerably faster than an EXPUNGE-LOGOUT or - EXPUNGE-SELECT because no untagged EXPUNGE responses (which the - client would probably ignore) are sent. - - Example: C: A341 CLOSE - S: A341 OK CLOSE completed - -6.4.3. EXPUNGE Command - - Arguments: none - - Responses: untagged responses: EXPUNGE - - Result: OK - expunge completed - NO - expunge failure: can't expunge (e.g. permission - denied) - BAD - command unknown or arguments invalid - - The EXPUNGE command permanently removes from the currently - selected mailbox all messages that have the \Deleted flag set. - Before returning an OK to the client, an untagged EXPUNGE response - is sent for each message that is removed. - - Example: C: A202 EXPUNGE - S: * 3 EXPUNGE - S: * 3 EXPUNGE - S: * 5 EXPUNGE - S: * 8 EXPUNGE - S: A202 OK EXPUNGE completed - - Note: in this example, messages 3, 4, 7, and 11 had the - \Deleted flag set. See the description of the EXPUNGE - response for further explanation. - -6.4.4. SEARCH Command - - Arguments: OPTIONAL [CHARSET] specification - searching criteria (one or more) - - Responses: REQUIRED untagged response: SEARCH - - Result: OK - search completed - NO - search error: can't search that [CHARSET] or - criteria - BAD - command unknown or arguments invalid - - - - - - -Crispin Standards Track [Page 37] - -RFC 2060 IMAP4rev1 December 1996 - - - The SEARCH command searches the mailbox for messages that match - the given searching criteria. Searching criteria consist of one - or more search keys. The untagged SEARCH response from the server - contains a listing of message sequence numbers corresponding to - those messages that match the searching criteria. - - When multiple keys are specified, the result is the intersection - (AND function) of all the messages that match those keys. For - example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers - to all deleted messages from Smith that were placed in the mailbox - since February 1, 1994. A search key can also be a parenthesized - list of one or more search keys (e.g. for use with the OR and NOT - keys). - - Server implementations MAY exclude [MIME-IMB] body parts with - terminal content media types other than TEXT and MESSAGE from - consideration in SEARCH matching. - - The OPTIONAL [CHARSET] specification consists of the word - "CHARSET" followed by a registered [CHARSET]. It indicates the - [CHARSET] of the strings that appear in the search criteria. - [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in - [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing - text in a [CHARSET] other than US-ASCII. US-ASCII MUST be - supported; other [CHARSET]s MAY be supported. If the server does - not support the specified [CHARSET], it MUST return a tagged NO - response (not a BAD). - - In all search keys that use strings, a message matches the key if - the string is a substring of the field. The matching is case- - insensitive. - - The defined search keys are as follows. Refer to the Formal - Syntax section for the precise syntactic definitions of the - arguments. - - <message set> Messages with message sequence numbers - corresponding to the specified message sequence - number set - - ALL All messages in the mailbox; the default initial - key for ANDing. - - ANSWERED Messages with the \Answered flag set. - - BCC <string> Messages that contain the specified string in the - envelope structure's BCC field. - - - - -Crispin Standards Track [Page 38] - -RFC 2060 IMAP4rev1 December 1996 - - - BEFORE <date> Messages whose internal date is earlier than the - specified date. - - BODY <string> Messages that contain the specified string in the - body of the message. - - CC <string> Messages that contain the specified string in the - envelope structure's CC field. - - DELETED Messages with the \Deleted flag set. - - DRAFT Messages with the \Draft flag set. - - FLAGGED Messages with the \Flagged flag set. - - FROM <string> Messages that contain the specified string in the - envelope structure's FROM field. - - HEADER <field-name> <string> - Messages that have a header with the specified - field-name (as defined in [RFC-822]) and that - contains the specified string in the [RFC-822] - field-body. - - KEYWORD <flag> Messages with the specified keyword set. - - LARGER <n> Messages with an [RFC-822] size larger than the - specified number of octets. - - NEW Messages that have the \Recent flag set but not the - \Seen flag. This is functionally equivalent to - "(RECENT UNSEEN)". - - NOT <search-key> - Messages that do not match the specified search - key. - - OLD Messages that do not have the \Recent flag set. - This is functionally equivalent to "NOT RECENT" (as - opposed to "NOT NEW"). - - ON <date> Messages whose internal date is within the - specified date. - - OR <search-key1> <search-key2> - Messages that match either search key. - - RECENT Messages that have the \Recent flag set. - - - -Crispin Standards Track [Page 39] - -RFC 2060 IMAP4rev1 December 1996 - - - SEEN Messages that have the \Seen flag set. - - SENTBEFORE <date> - Messages whose [RFC-822] Date: header is earlier - than the specified date. - - SENTON <date> Messages whose [RFC-822] Date: header is within the - specified date. - - SENTSINCE <date> - Messages whose [RFC-822] Date: header is within or - later than the specified date. - - SINCE <date> Messages whose internal date is within or later - than the specified date. - - SMALLER <n> Messages with an [RFC-822] size smaller than the - specified number of octets. - - SUBJECT <string> - Messages that contain the specified string in the - envelope structure's SUBJECT field. - - TEXT <string> Messages that contain the specified string in the - header or body of the message. - - TO <string> Messages that contain the specified string in the - envelope structure's TO field. - - UID <message set> - Messages with unique identifiers corresponding to - the specified unique identifier set. - - UNANSWERED Messages that do not have the \Answered flag set. - - UNDELETED Messages that do not have the \Deleted flag set. - - UNDRAFT Messages that do not have the \Draft flag set. - - UNFLAGGED Messages that do not have the \Flagged flag set. - - UNKEYWORD <flag> - Messages that do not have the specified keyword - set. - - UNSEEN Messages that do not have the \Seen flag set. - - - - - -Crispin Standards Track [Page 40] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" - S: * SEARCH 2 84 882 - S: A282 OK SEARCH completed - -6.4.5. FETCH Command - - Arguments: message set - message data item names - - Responses: untagged responses: FETCH - - Result: OK - fetch completed - NO - fetch error: can't fetch that data - BAD - command unknown or arguments invalid - - The FETCH command retrieves data associated with a message in the - mailbox. The data items to be fetched can be either a single atom - or a parenthesized list. - - The currently defined data items that can be fetched are: - - ALL Macro equivalent to: (FLAGS INTERNALDATE - RFC822.SIZE ENVELOPE) - - BODY Non-extensible form of BODYSTRUCTURE. - - BODY[<section>]<<partial>> - The text of a particular body section. The section - specification is a set of zero or more part - specifiers delimited by periods. A part specifier - is either a part number or one of the following: - HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and - TEXT. An empty section specification refers to the - entire message, including the header. - - Every message has at least one part number. - Non-[MIME-IMB] messages, and non-multipart - [MIME-IMB] messages with no encapsulated message, - only have a part 1. - - Multipart messages are assigned consecutive part - numbers, as they occur in the message. If a - particular part is of type message or multipart, - its parts MUST be indicated by a period followed by - the part number within that nested multipart part. - - - - - - -Crispin Standards Track [Page 41] - -RFC 2060 IMAP4rev1 December 1996 - - - A part of type MESSAGE/RFC822 also has nested part - numbers, referring to parts of the MESSAGE part's - body. - - The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and - TEXT part specifiers can be the sole part specifier - or can be prefixed by one or more numeric part - specifiers, provided that the numeric part - specifier refers to a part of type MESSAGE/RFC822. - The MIME part specifier MUST be prefixed by one or - more numeric part specifiers. - - The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT - part specifiers refer to the [RFC-822] header of - the message or of an encapsulated [MIME-IMT] - MESSAGE/RFC822 message. HEADER.FIELDS and - HEADER.FIELDS.NOT are followed by a list of - field-name (as defined in [RFC-822]) names, and - return a subset of the header. The subset returned - by HEADER.FIELDS contains only those header fields - with a field-name that matches one of the names in - the list; similarly, the subset returned by - HEADER.FIELDS.NOT contains only the header fields - with a non-matching field-name. The field-matching - is case-insensitive but otherwise exact. In all - cases, the delimiting blank line between the header - and the body is always included. - - The MIME part specifier refers to the [MIME-IMB] - header for this part. - - The TEXT part specifier refers to the text body of - the message, omitting the [RFC-822] header. - - - - - - - - - - - - - - - - - - -Crispin Standards Track [Page 42] - -RFC 2060 IMAP4rev1 December 1996 - - - Here is an example of a complex message - with some of its part specifiers: - - HEADER ([RFC-822] header of the message) - TEXT MULTIPART/MIXED - 1 TEXT/PLAIN - 2 APPLICATION/OCTET-STREAM - 3 MESSAGE/RFC822 - 3.HEADER ([RFC-822] header of the message) - 3.TEXT ([RFC-822] text body of the message) - 3.1 TEXT/PLAIN - 3.2 APPLICATION/OCTET-STREAM - 4 MULTIPART/MIXED - 4.1 IMAGE/GIF - 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) - 4.2 MESSAGE/RFC822 - 4.2.HEADER ([RFC-822] header of the message) - 4.2.TEXT ([RFC-822] text body of the message) - 4.2.1 TEXT/PLAIN - 4.2.2 MULTIPART/ALTERNATIVE - 4.2.2.1 TEXT/PLAIN - 4.2.2.2 TEXT/RICHTEXT - - - It is possible to fetch a substring of the - designated text. This is done by appending an open - angle bracket ("<"), the octet position of the - first desired octet, a period, the maximum number - of octets desired, and a close angle bracket (">") - to the part specifier. If the starting octet is - beyond the end of the text, an empty string is - returned. - - Any partial fetch that attempts to read beyond the - end of the text is truncated as appropriate. A - partial fetch that starts at octet 0 is returned as - a partial fetch, even if this truncation happened. - - Note: this means that BODY[]<0.2048> of a - 1500-octet message will return BODY[]<0> - with a literal of size 1500, not BODY[]. - - Note: a substring fetch of a - HEADER.FIELDS or HEADER.FIELDS.NOT part - specifier is calculated after subsetting - the header. - - - - - -Crispin Standards Track [Page 43] - -RFC 2060 IMAP4rev1 December 1996 - - - The \Seen flag is implicitly set; if this causes - the flags to change they SHOULD be included as part - of the FETCH responses. - - BODY.PEEK[<section>]<<partial>> An alternate form of - BODY[<section>] that does not implicitly set the - \Seen flag. - - BODYSTRUCTURE The [MIME-IMB] body structure of the message. This - is computed by the server by parsing the [MIME-IMB] - header fields in the [RFC-822] header and - [MIME-IMB] headers. - - ENVELOPE The envelope structure of the message. This is - computed by the server by parsing the [RFC-822] - header into the component parts, defaulting various - fields as necessary. - - FAST Macro equivalent to: (FLAGS INTERNALDATE - RFC822.SIZE) - - FLAGS The flags that are set for this message. - - FULL Macro equivalent to: (FLAGS INTERNALDATE - RFC822.SIZE ENVELOPE BODY) - - INTERNALDATE The internal date of the message. - - RFC822 Functionally equivalent to BODY[], differing in the - syntax of the resulting untagged FETCH data (RFC822 - is returned). - - RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], - differing in the syntax of the resulting untagged - FETCH data (RFC822.HEADER is returned). - - RFC822.SIZE The [RFC-822] size of the message. - - RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in - the syntax of the resulting untagged FETCH data - (RFC822.TEXT is returned). - - UID The unique identifier for the message. - - - - - - - - -Crispin Standards Track [Page 44] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) - S: * 2 FETCH .... - S: * 3 FETCH .... - S: * 4 FETCH .... - S: A654 OK FETCH completed - -6.4.6. STORE Command - - Arguments: message set - message data item name - value for message data item - - Responses: untagged responses: FETCH - - Result: OK - store completed - NO - store error: can't store that data - BAD - command unknown or arguments invalid - - The STORE command alters data associated with a message in the - mailbox. Normally, STORE will return the updated value of the - data with an untagged FETCH response. A suffix of ".SILENT" in - the data item name prevents the untagged FETCH, and the server - SHOULD assume that the client has determined the updated value - itself or does not care about the updated value. - - Note: regardless of whether or not the ".SILENT" suffix was - used, the server SHOULD send an untagged FETCH response if a - change to a message's flags from an external source is - observed. The intent is that the status of the flags is - determinate without a race condition. - - The currently defined data items that can be stored are: - - FLAGS <flag list> - Replace the flags for the message with the - argument. The new value of the flags are returned - as if a FETCH of those flags was done. - - FLAGS.SILENT <flag list> - Equivalent to FLAGS, but without returning a new - value. - - +FLAGS <flag list> - Add the argument to the flags for the message. The - new value of the flags are returned as if a FETCH - of those flags was done. - - - - - -Crispin Standards Track [Page 45] - -RFC 2060 IMAP4rev1 December 1996 - - - +FLAGS.SILENT <flag list> - Equivalent to +FLAGS, but without returning a new - value. - - -FLAGS <flag list> - Remove the argument from the flags for the message. - The new value of the flags are returned as if a - FETCH of those flags was done. - - -FLAGS.SILENT <flag list> - Equivalent to -FLAGS, but without returning a new - value. - - Example: C: A003 STORE 2:4 +FLAGS (\Deleted) - S: * 2 FETCH FLAGS (\Deleted \Seen) - S: * 3 FETCH FLAGS (\Deleted) - S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) - S: A003 OK STORE completed - -6.4.7. COPY Command - - Arguments: message set - mailbox name - - Responses: no specific responses for this command - - Result: OK - copy completed - NO - copy error: can't copy those messages or to that - name - BAD - command unknown or arguments invalid - - The COPY command copies the specified message(s) to the end of the - specified destination mailbox. The flags and internal date of the - message(s) SHOULD be preserved in the copy. - - If the destination mailbox does not exist, a server SHOULD return - an error. It SHOULD NOT automatically create the mailbox. Unless - it is certain that the destination mailbox can not be created, the - server MUST send the response code "[TRYCREATE]" as the prefix of - the text of the tagged NO response. This gives a hint to the - client that it can attempt a CREATE command and retry the COPY if - the CREATE is successful. - - - - - - - - - -Crispin Standards Track [Page 46] - -RFC 2060 IMAP4rev1 December 1996 - - - If the COPY command is unsuccessful for any reason, server - implementations MUST restore the destination mailbox to its state - before the COPY attempt. - - Example: C: A003 COPY 2:4 MEETING - S: A003 OK COPY completed - -6.4.8. UID Command - - Arguments: command name - command arguments - - Responses: untagged responses: FETCH, SEARCH - - Result: OK - UID command completed - NO - UID command error - BAD - command unknown or arguments invalid - - The UID command has two forms. In the first form, it takes as its - arguments a COPY, FETCH, or STORE command with arguments - appropriate for the associated command. However, the numbers in - the message set argument are unique identifiers instead of message - sequence numbers. - - In the second form, the UID command takes a SEARCH command with - SEARCH command arguments. The interpretation of the arguments is - the same as with SEARCH; however, the numbers returned in a SEARCH - response for a UID SEARCH command are unique identifiers instead - of message sequence numbers. For example, the command UID SEARCH - 1:100 UID 443:557 returns the unique identifiers corresponding to - the intersection of the message sequence number set 1:100 and the - UID set 443:557. - - Message set ranges are permitted; however, there is no guarantee - that unique identifiers be contiguous. A non-existent unique - identifier within a message set range is ignored without any error - message generated. - - The number after the "*" in an untagged FETCH response is always a - message sequence number, not a unique identifier, even for a UID - command response. However, server implementations MUST implicitly - include the UID message data item as part of any FETCH response - caused by a UID command, regardless of whether a UID was specified - as a message data item to the FETCH. - - - - - - - -Crispin Standards Track [Page 47] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A999 UID FETCH 4827313:4828442 FLAGS - S: * 23 FETCH (FLAGS (\Seen) UID 4827313) - S: * 24 FETCH (FLAGS (\Seen) UID 4827943) - S: * 25 FETCH (FLAGS (\Seen) UID 4828442) - S: A999 UID FETCH completed - -6.5. Client Commands - Experimental/Expansion - -6.5.1. X<atom> Command - - Arguments: implementation defined - - Responses: implementation defined - - Result: OK - command completed - NO - failure - BAD - command unknown or arguments invalid - - Any command prefixed with an X is an experimental command. - Commands which are not part of this specification, a standard or - standards-track revision of this specification, or an IESG- - approved experimental protocol, MUST use the X prefix. - - Any added untagged responses issued by an experimental command - MUST also be prefixed with an X. Server implementations MUST NOT - send any such untagged responses, unless the client requested it - by issuing the associated experimental command. - - Example: C: a441 CAPABILITY - S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN - S: a441 OK CAPABILITY completed - C: A442 XPIG-LATIN - S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay - S: A442 OK XPIG-LATIN ompleted-cay - -7. Server Responses - - Server responses are in three forms: status responses, server data, - and command continuation request. The information contained in a - server response, identified by "Contents:" in the response - descriptions below, is described by function, not by syntax. The - precise syntax of server responses is described in the Formal Syntax - section. - - The client MUST be prepared to accept any response at all times. - - - - - - -Crispin Standards Track [Page 48] - -RFC 2060 IMAP4rev1 December 1996 - - - Status responses can be tagged or untagged. Tagged status responses - indicate the completion result (OK, NO, or BAD status) of a client - command, and have a tag matching the command. - - Some status responses, and all server data, are untagged. An - untagged response is indicated by the token "*" instead of a tag. - Untagged status responses indicate server greeting, or server status - that does not indicate the completion of a command (for example, an - impending system shutdown alert). For historical reasons, untagged - server data responses are also called "unsolicited data", although - strictly speaking only unilateral server data is truly "unsolicited". - - Certain server data MUST be recorded by the client when it is - received; this is noted in the description of that data. Such data - conveys critical information which affects the interpretation of all - subsequent commands and responses (e.g. updates reflecting the - creation or destruction of messages). - - Other server data SHOULD be recorded for later reference; if the - client does not need to record the data, or if recording the data has - no obvious purpose (e.g. a SEARCH response when no SEARCH command is - in progress), the data SHOULD be ignored. - - An example of unilateral untagged server data occurs when the IMAP - connection is in selected state. In selected state, the server - checks the mailbox for new messages as part of command execution. - Normally, this is part of the execution of every command; hence, a - NOOP command suffices to check for new messages. If new messages are - found, the server sends untagged EXISTS and RECENT responses - reflecting the new size of the mailbox. Server implementations that - offer multiple simultaneous access to the same mailbox SHOULD also - send appropriate unilateral untagged FETCH and EXPUNGE responses if - another agent changes the state of any message flags or expunges any - messages. - - Command continuation request responses use the token "+" instead of a - tag. These responses are sent by the server to indicate acceptance - of an incomplete client command and readiness for the remainder of - the command. - -7.1. Server Responses - Status Responses - - Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD - may be tagged or untagged. PREAUTH and BYE are always untagged. - - Status responses MAY include an OPTIONAL "response code". A response - code consists of data inside square brackets in the form of an atom, - possibly followed by a space and arguments. The response code - - - -Crispin Standards Track [Page 49] - -RFC 2060 IMAP4rev1 December 1996 - - - contains additional information or status codes for client software - beyond the OK/NO/BAD condition, and are defined when there is a - specific action that a client can take based upon the additional - information. - - The currently defined response codes are: - - ALERT The human-readable text contains a special alert - that MUST be presented to the user in a fashion - that calls the user's attention to the message. - - NEWNAME Followed by a mailbox name and a new mailbox name. - A SELECT or EXAMINE is failing because the target - mailbox name no longer exists because it was - renamed to the new mailbox name. This is a hint to - the client that the operation can succeed if the - SELECT or EXAMINE is reissued with the new mailbox - name. - - PARSE The human-readable text represents an error in - parsing the [RFC-822] header or [MIME-IMB] headers - of a message in the mailbox. - - PERMANENTFLAGS Followed by a parenthesized list of flags, - indicates which of the known flags that the client - can change permanently. Any flags that are in the - FLAGS untagged response, but not the PERMANENTFLAGS - list, can not be set permanently. If the client - attempts to STORE a flag that is not in the - PERMANENTFLAGS list, the server will either reject - it with a NO reply or store the state for the - remainder of the current session only. The - PERMANENTFLAGS list can also include the special - flag \*, which indicates that it is possible to - create new keywords by attempting to store those - flags in the mailbox. - - READ-ONLY The mailbox is selected read-only, or its access - while selected has changed from read-write to - read-only. - - READ-WRITE The mailbox is selected read-write, or its access - while selected has changed from read-only to - read-write. - - - - - - - -Crispin Standards Track [Page 50] - -RFC 2060 IMAP4rev1 December 1996 - - - TRYCREATE An APPEND or COPY attempt is failing because the - target mailbox does not exist (as opposed to some - other reason). This is a hint to the client that - the operation can succeed if the mailbox is first - created by the CREATE command. - - UIDVALIDITY Followed by a decimal number, indicates the unique - identifier validity value. - - UNSEEN Followed by a decimal number, indicates the number - of the first message without the \Seen flag set. - - Additional response codes defined by particular client or server - implementations SHOULD be prefixed with an "X" until they are - added to a revision of this protocol. Client implementations - SHOULD ignore response codes that they do not recognize. - -7.1.1. OK Response - - Contents: OPTIONAL response code - human-readable text - - The OK response indicates an information message from the server. - When tagged, it indicates successful completion of the associated - command. The human-readable text MAY be presented to the user as - an information message. The untagged form indicates an - information-only message; the nature of the information MAY be - indicated by a response code. - - The untagged form is also used as one of three possible greetings - at connection startup. It indicates that the connection is not - yet authenticated and that a LOGIN command is needed. - - Example: S: * OK IMAP4rev1 server ready - C: A001 LOGIN fred blurdybloop - S: * OK [ALERT] System shutdown in 10 minutes - S: A001 OK LOGIN Completed - -7.1.2. NO Response - - Contents: OPTIONAL response code - human-readable text - - The NO response indicates an operational error message from the - server. When tagged, it indicates unsuccessful completion of the - associated command. The untagged form indicates a warning; the - command can still complete successfully. The human-readable text - describes the condition. - - - -Crispin Standards Track [Page 51] - -RFC 2060 IMAP4rev1 December 1996 - - - Example: C: A222 COPY 1:2 owatagusiam - S: * NO Disk is 98% full, please delete unnecessary data - S: A222 OK COPY completed - C: A223 COPY 3:200 blurdybloop - S: * NO Disk is 98% full, please delete unnecessary data - S: * NO Disk is 99% full, please delete unnecessary data - S: A223 NO COPY failed: disk is full - -7.1.3. BAD Response - - Contents: OPTIONAL response code - human-readable text - - The BAD response indicates an error message from the server. When - tagged, it reports a protocol-level error in the client's command; - the tag indicates the command that caused the error. The untagged - form indicates a protocol-level error for which the associated - command can not be determined; it can also indicate an internal - server failure. The human-readable text describes the condition. - - Example: C: ...very long command line... - S: * BAD Command line too long - C: ...empty line... - S: * BAD Empty command line - C: A443 EXPUNGE - S: * BAD Disk crash, attempting salvage to a new disk! - S: * OK Salvage successful, no data lost - S: A443 OK Expunge completed - -7.1.4. PREAUTH Response - - Contents: OPTIONAL response code - human-readable text - - The PREAUTH response is always untagged, and is one of three - possible greetings at connection startup. It indicates that the - connection has already been authenticated by external means and - thus no LOGIN command is needed. - - Example: S: * PREAUTH IMAP4rev1 server logged in as Smith - -7.1.5. BYE Response - - Contents: OPTIONAL response code - human-readable text - - - - - - -Crispin Standards Track [Page 52] - -RFC 2060 IMAP4rev1 December 1996 - - - The BYE response is always untagged, and indicates that the server - is about to close the connection. The human-readable text MAY be - displayed to the user in a status report by the client. The BYE - response is sent under one of four conditions: - - 1) as part of a normal logout sequence. The server will close - the connection after sending the tagged OK response to the - LOGOUT command. - - 2) as a panic shutdown announcement. The server closes the - connection immediately. - - 3) as an announcement of an inactivity autologout. The server - closes the connection immediately. - - 4) as one of three possible greetings at connection startup, - indicating that the server is not willing to accept a - connection from this client. The server closes the - connection immediately. - - The difference between a BYE that occurs as part of a normal - LOGOUT sequence (the first case) and a BYE that occurs because of - a failure (the other three cases) is that the connection closes - immediately in the failure case. - - Example: S: * BYE Autologout; idle for too long - -7.2. Server Responses - Server and Mailbox Status - - These responses are always untagged. This is how server and mailbox - status data are transmitted from the server to the client. Many of - these responses typically result from a command with the same name. - -7.2.1. CAPABILITY Response - - Contents: capability listing - - The CAPABILITY response occurs as a result of a CAPABILITY - command. The capability listing contains a space-separated - listing of capability names that the server supports. The - capability listing MUST include the atom "IMAP4rev1". - - A capability name which begins with "AUTH=" indicates that the - server supports that particular authentication mechanism. - - - - - - - -Crispin Standards Track [Page 53] - -RFC 2060 IMAP4rev1 December 1996 - - - Other capability names indicate that the server supports an - extension, revision, or amendment to the IMAP4rev1 protocol. - Server responses MUST conform to this document until the client - issues a command that uses the associated capability. - - Capability names MUST either begin with "X" or be standard or - standards-track IMAP4rev1 extensions, revisions, or amendments - registered with IANA. A server MUST NOT offer unregistered or - non-standard capability names, unless such names are prefixed with - an "X". - - Client implementations SHOULD NOT require any capability name - other than "IMAP4rev1", and MUST ignore any unknown capability - names. - - Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN - -7.2.2. LIST Response - - Contents: name attributes - hierarchy delimiter - name - - The LIST response occurs as a result of a LIST command. It - returns a single name that matches the LIST specification. There - can be multiple LIST responses for a single LIST command. - - Four name attributes are defined: - - \Noinferiors It is not possible for any child levels of - hierarchy to exist under this name; no child levels - exist now and none can be created in the future. - - \Noselect It is not possible to use this name as a selectable - mailbox. - - \Marked The mailbox has been marked "interesting" by the - server; the mailbox probably contains messages that - have been added since the last time the mailbox was - selected. - - \Unmarked The mailbox does not contain any additional - messages since the last time the mailbox was - selected. - - If it is not feasible for the server to determine whether the - mailbox is "interesting" or not, or if the name is a \Noselect - name, the server SHOULD NOT send either \Marked or \Unmarked. - - - -Crispin Standards Track [Page 54] - -RFC 2060 IMAP4rev1 December 1996 - - - The hierarchy delimiter is a character used to delimit levels of - hierarchy in a mailbox name. A client can use it to create child - mailboxes, and to search higher or lower levels of naming - hierarchy. All children of a top-level hierarchy node MUST use - the same separator character. A NIL hierarchy delimiter means - that no hierarchy exists; the name is a "flat" name. - - The name represents an unambiguous left-to-right hierarchy, and - MUST be valid for use as a reference in LIST and LSUB commands. - Unless \Noselect is indicated, the name MUST also be valid as an - argument for commands, such as SELECT, that accept mailbox - names. - - Example: S: * LIST (\Noselect) "/" ~/Mail/foo - -7.2.3. LSUB Response - - Contents: name attributes - hierarchy delimiter - name - - The LSUB response occurs as a result of an LSUB command. It - returns a single name that matches the LSUB specification. There - can be multiple LSUB responses for a single LSUB command. The - data is identical in format to the LIST response. - - Example: S: * LSUB () "." #news.comp.mail.misc - -7.2.4 STATUS Response - - Contents: name - status parenthesized list - - The STATUS response occurs as a result of an STATUS command. It - returns the mailbox name that matches the STATUS specification and - the requested mailbox status information. - - Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) - -7.2.5. SEARCH Response - - Contents: zero or more numbers - - - - - - - - - -Crispin Standards Track [Page 55] - -RFC 2060 IMAP4rev1 December 1996 - - - The SEARCH response occurs as a result of a SEARCH or UID SEARCH - command. The number(s) refer to those messages that match the - search criteria. For SEARCH, these are message sequence numbers; - for UID SEARCH, these are unique identifiers. Each number is - delimited by a space. - - Example: S: * SEARCH 2 3 6 - -7.2.6. FLAGS Response - - Contents: flag parenthesized list - - The FLAGS response occurs as a result of a SELECT or EXAMINE - command. The flag parenthesized list identifies the flags (at a - minimum, the system-defined flags) that are applicable for this - mailbox. Flags other than the system flags can also exist, - depending on server implementation. - - The update from the FLAGS response MUST be recorded by the client. - - Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) - -7.3. Server Responses - Mailbox Size - - These responses are always untagged. This is how changes in the size - of the mailbox are trasnmitted from the server to the client. - Immediately following the "*" token is a number that represents a - message count. - -7.3.1. EXISTS Response - - Contents: none - - The EXISTS response reports the number of messages in the mailbox. - This response occurs as a result of a SELECT or EXAMINE command, - and if the size of the mailbox changes (e.g. new mail). - - The update from the EXISTS response MUST be recorded by the - client. - - Example: S: * 23 EXISTS - - - - - - - - - - -Crispin Standards Track [Page 56] - -RFC 2060 IMAP4rev1 December 1996 - - -7.3.2. RECENT Response - - Contents: none - - The RECENT response reports the number of messages with the - \Recent flag set. This response occurs as a result of a SELECT or - EXAMINE command, and if the size of the mailbox changes (e.g. new - mail). - - Note: It is not guaranteed that the message sequence numbers of - recent messages will be a contiguous range of the highest n - messages in the mailbox (where n is the value reported by the - RECENT response). Examples of situations in which this is not - the case are: multiple clients having the same mailbox open - (the first session to be notified will see it as recent, others - will probably see it as non-recent), and when the mailbox is - re-ordered by a non-IMAP agent. - - The only reliable way to identify recent messages is to look at - message flags to see which have the \Recent flag set, or to do - a SEARCH RECENT. - - The update from the RECENT response MUST be recorded by the - client. - - Example: S: * 5 RECENT - -7.4. Server Responses - Message Status - - These responses are always untagged. This is how message data are - transmitted from the server to the client, often as a result of a - command with the same name. Immediately following the "*" token is a - number that represents a message sequence number. - -7.4.1. EXPUNGE Response - - Contents: none - - The EXPUNGE response reports that the specified message sequence - number has been permanently removed from the mailbox. The message - sequence number for each successive message in the mailbox is - immediately decremented by 1, and this decrement is reflected in - message sequence numbers in subsequent responses (including other - untagged EXPUNGE responses). - - As a result of the immediate decrement rule, message sequence - numbers that appear in a set of successive EXPUNGE responses - depend upon whether the messages are removed starting from lower - - - -Crispin Standards Track [Page 57] - -RFC 2060 IMAP4rev1 December 1996 - - - numbers to higher numbers, or from higher numbers to lower - numbers. For example, if the last 5 messages in a 9-message - mailbox are expunged; a "lower to higher" server will send five - untagged EXPUNGE responses for message sequence number 5, whereas - a "higher to lower server" will send successive untagged EXPUNGE - responses for message sequence numbers 9, 8, 7, 6, and 5. - - An EXPUNGE response MUST NOT be sent when no command is in - progress; nor while responding to a FETCH, STORE, or SEARCH - command. This rule is necessary to prevent a loss of - synchronization of message sequence numbers between client and - server. - - The update from the EXPUNGE response MUST be recorded by the - client. - - Example: S: * 44 EXPUNGE - -7.4.2. FETCH Response - - Contents: message data - - The FETCH response returns data about a message to the client. - The data are pairs of data item names and their values in - parentheses. This response occurs as the result of a FETCH or - STORE command, as well as by unilateral server decision (e.g. flag - updates). - - The current data items are: - - BODY A form of BODYSTRUCTURE without extension data. - - BODY[<section>]<<origin_octet>> - A string expressing the body contents of the - specified section. The string SHOULD be - interpreted by the client according to the content - transfer encoding, body type, and subtype. - - If the origin octet is specified, this string is a - substring of the entire body contents, starting at - that origin octet. This means that BODY[]<0> MAY - be truncated, but BODY[] is NEVER truncated. - - 8-bit textual data is permitted if a [CHARSET] - identifier is part of the body parameter - parenthesized list for this section. Note that - headers (part specifiers HEADER or MIME, or the - header portion of a MESSAGE/RFC822 part), MUST be - - - -Crispin Standards Track [Page 58] - -RFC 2060 IMAP4rev1 December 1996 - - - 7-bit; 8-bit characters are not permitted in - headers. Note also that the blank line at the end - of the header is always included in header data. - - Non-textual data such as binary data MUST be - transfer encoded into a textual form such as BASE64 - prior to being sent to the client. To derive the - original binary data, the client MUST decode the - transfer encoded string. - - BODYSTRUCTURE A parenthesized list that describes the [MIME-IMB] - body structure of a message. This is computed by - the server by parsing the [MIME-IMB] header fields, - defaulting various fields as necessary. - - For example, a simple text message of 48 lines and - 2279 octets can have a body structure of: ("TEXT" - "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 - 48) - - Multiple parts are indicated by parenthesis - nesting. Instead of a body type as the first - element of the parenthesized list there is a nested - body. The second element of the parenthesized list - is the multipart subtype (mixed, digest, parallel, - alternative, etc.). - - For example, a two part message consisting of a - text and a BASE645-encoded text attachment can have - a body structure of: (("TEXT" "PLAIN" ("CHARSET" - "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN" - ("CHARSET" "US-ASCII" "NAME" "cc.diff") - "<960723163407.20117h@cac.washington.edu>" - "Compiler diff" "BASE64" 4554 73) "MIXED")) - - Extension data follows the multipart subtype. - Extension data is never returned with the BODY - fetch, but can be returned with a BODYSTRUCTURE - fetch. Extension data, if present, MUST be in the - defined order. - - The extension data of a multipart body part are in - the following order: - - body parameter parenthesized list - A parenthesized list of attribute/value pairs - [e.g. ("foo" "bar" "baz" "rag") where "bar" is - the value of "foo" and "rag" is the value of - - - -Crispin Standards Track [Page 59] - -RFC 2060 IMAP4rev1 December 1996 - - - "baz"] as defined in [MIME-IMB]. - - body disposition - A parenthesized list, consisting of a - disposition type string followed by a - parenthesized list of disposition - attribute/value pairs. The disposition type and - attribute names will be defined in a future - standards-track revision to [DISPOSITION]. - - body language - A string or parenthesized list giving the body - language value as defined in [LANGUAGE-TAGS]. - - Any following extension data are not yet defined in - this version of the protocol. Such extension data - can consist of zero or more NILs, strings, numbers, - or potentially nested parenthesized lists of such - data. Client implementations that do a - BODYSTRUCTURE fetch MUST be prepared to accept such - extension data. Server implementations MUST NOT - send such extension data until it has been defined - by a revision of this protocol. - - The basic fields of a non-multipart body part are - in the following order: - - body type - A string giving the content media type name as - defined in [MIME-IMB]. - - body subtype - A string giving the content subtype name as - defined in [MIME-IMB]. - - body parameter parenthesized list - A parenthesized list of attribute/value pairs - [e.g. ("foo" "bar" "baz" "rag") where "bar" is - the value of "foo" and "rag" is the value of - "baz"] as defined in [MIME-IMB]. - - body id - A string giving the content id as defined in - [MIME-IMB]. - - body description - A string giving the content description as - defined in [MIME-IMB]. - - - -Crispin Standards Track [Page 60] - -RFC 2060 IMAP4rev1 December 1996 - - - body encoding - A string giving the content transfer encoding as - defined in [MIME-IMB]. - - body size - A number giving the size of the body in octets. - Note that this size is the size in its transfer - encoding and not the resulting size after any - decoding. - - A body type of type MESSAGE and subtype RFC822 - contains, immediately after the basic fields, the - envelope structure, body structure, and size in - text lines of the encapsulated message. - - A body type of type TEXT contains, immediately - after the basic fields, the size of the body in - text lines. Note that this size is the size in its - content transfer encoding and not the resulting - size after any decoding. - - Extension data follows the basic fields and the - type-specific fields listed above. Extension data - is never returned with the BODY fetch, but can be - returned with a BODYSTRUCTURE fetch. Extension - data, if present, MUST be in the defined order. - - The extension data of a non-multipart body part are - in the following order: - - body MD5 - A string giving the body MD5 value as defined in - [MD5]. - - body disposition - A parenthesized list with the same content and - function as the body disposition for a multipart - body part. - - body language - A string or parenthesized list giving the body - language value as defined in [LANGUAGE-TAGS]. - - Any following extension data are not yet defined in - this version of the protocol, and would be as - described above under multipart extension data. - - - - - -Crispin Standards Track [Page 61] - -RFC 2060 IMAP4rev1 December 1996 - - - ENVELOPE A parenthesized list that describes the envelope - structure of a message. This is computed by the - server by parsing the [RFC-822] header into the - component parts, defaulting various fields as - necessary. - - The fields of the envelope structure are in the - following order: date, subject, from, sender, - reply-to, to, cc, bcc, in-reply-to, and message-id. - The date, subject, in-reply-to, and message-id - fields are strings. The from, sender, reply-to, - to, cc, and bcc fields are parenthesized lists of - address structures. - - An address structure is a parenthesized list that - describes an electronic mail address. The fields - of an address structure are in the following order: - personal name, [SMTP] at-domain-list (source - route), mailbox name, and host name. - - [RFC-822] group syntax is indicated by a special - form of address structure in which the host name - field is NIL. If the mailbox name field is also - NIL, this is an end of group marker (semi-colon in - RFC 822 syntax). If the mailbox name field is - non-NIL, this is a start of group marker, and the - mailbox name field holds the group name phrase. - - Any field of an envelope or address structure that - is not applicable is presented as NIL. Note that - the server MUST default the reply-to and sender - fields from the from field; a client is not - expected to know to do this. - - FLAGS A parenthesized list of flags that are set for this - message. - - INTERNALDATE A string representing the internal date of the - message. - - RFC822 Equivalent to BODY[]. - - RFC822.HEADER Equivalent to BODY.PEEK[HEADER]. - - RFC822.SIZE A number expressing the [RFC-822] size of the - message. - - RFC822.TEXT Equivalent to BODY[TEXT]. - - - -Crispin Standards Track [Page 62] - -RFC 2060 IMAP4rev1 December 1996 - - - UID A number expressing the unique identifier of the - message. - - - Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) - -7.5. Server Responses - Command Continuation Request - - The command continuation request response is indicated by a "+" token - instead of a tag. This form of response indicates that the server is - ready to accept the continuation of a command from the client. The - remainder of this response is a line of text. - - This response is used in the AUTHORIZATION command to transmit server - data to the client, and request additional client data. This - response is also used if an argument to any command is a literal. - - The client is not permitted to send the octets of the literal unless - the server indicates that it expects it. This permits the server to - process commands and reject errors on a line-by-line basis. The - remainder of the command, including the CRLF that terminates a - command, follows the octets of the literal. If there are any - additional command arguments the literal octets are followed by a - space and those arguments. - - Example: C: A001 LOGIN {11} - S: + Ready for additional command text - C: FRED FOOBAR {7} - S: + Ready for additional command text - C: fat man - S: A001 OK LOGIN completed - C: A044 BLURDYBLOOP {102856} - S: A044 BAD No such command as "BLURDYBLOOP" - -8. Sample IMAP4rev1 connection - - The following is a transcript of an IMAP4rev1 connection. A long - line in this sample is broken for editorial clarity. - -S: * OK IMAP4rev1 Service Ready -C: a001 login mrc secret -S: a001 OK LOGIN completed -C: a002 select inbox -S: * 18 EXISTS -S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) -S: * 2 RECENT -S: * OK [UNSEEN 17] Message 17 is the first unseen message -S: * OK [UIDVALIDITY 3857529045] UIDs valid - - - -Crispin Standards Track [Page 63] - -RFC 2060 IMAP4rev1 December 1996 - - -S: a002 OK [READ-WRITE] SELECT completed -C: a003 fetch 12 full -S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" - RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" - "IMAP4rev1 WG mtg summary and minutes" - (("Terry Gray" NIL "gray" "cac.washington.edu")) - (("Terry Gray" NIL "gray" "cac.washington.edu")) - (("Terry Gray" NIL "gray" "cac.washington.edu")) - ((NIL NIL "imap" "cac.washington.edu")) - ((NIL NIL "minutes" "CNRI.Reston.VA.US") - ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL - "<B27397-0100000@cac.washington.edu>") - BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) -S: a003 OK FETCH completed -C: a004 fetch 12 body[header] -S: * 12 FETCH (BODY[HEADER] {350} -S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) -S: From: Terry Gray <gray@cac.washington.edu> -S: Subject: IMAP4rev1 WG mtg summary and minutes -S: To: imap@cac.washington.edu -S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU> -S: Message-Id: <B27397-0100000@cac.washington.edu> -S: MIME-Version: 1.0 -S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII -S: -S: ) -S: a004 OK FETCH completed -C: a005 store 12 +flags \deleted -S: * 12 FETCH (FLAGS (\Seen \Deleted)) -S: a005 OK +FLAGS completed -C: a006 logout -S: * BYE IMAP4rev1 server terminating connection -S: a006 OK LOGOUT completed - -9. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in [RFC-822] with one exception; the - delimiter used with the "#" construct is a single space (SPACE) and - not one or more commas. - - In the case of alternative or optional rules in which a later rule - overlaps an earlier rule, the rule which is listed earlier MUST take - priority. For example, "\Seen" when parsed as a flag is the \Seen - flag name and not a flag_extension, even though "\Seen" could be - parsed as a flag_extension. Some, but not all, instances of this - rule are noted below. - - - - -Crispin Standards Track [Page 64] - -RFC 2060 IMAP4rev1 December 1996 - - - Except as noted otherwise, all alphabetic characters are case- - insensitive. The use of upper or lower case characters to define - token strings is for editorial clarity only. Implementations MUST - accept these strings in a case-insensitive fashion. - -address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox - SPACE addr_host ")" - -addr_adl ::= nstring - ;; Holds route from [RFC-822] route-addr if - ;; non-NIL - -addr_host ::= nstring - ;; NIL indicates [RFC-822] group syntax. - ;; Otherwise, holds [RFC-822] domain name - -addr_mailbox ::= nstring - ;; NIL indicates end of [RFC-822] group; if - ;; non-NIL and addr_host is NIL, holds - ;; [RFC-822] group name. - ;; Otherwise, holds [RFC-822] local-part - -addr_name ::= nstring - ;; Holds phrase from [RFC-822] mailbox if - ;; non-NIL - -alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / - "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / - "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / - "Y" / "Z" / - "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / - "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / - "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / - "y" / "z" - ;; Case-sensitive - -append ::= "APPEND" SPACE mailbox [SPACE flag_list] - [SPACE date_time] SPACE literal - -astring ::= atom / string - -atom ::= 1*ATOM_CHAR - -ATOM_CHAR ::= <any CHAR except atom_specials> - -atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / - quoted_specials - - - - -Crispin Standards Track [Page 65] - -RFC 2060 IMAP4rev1 December 1996 - - -authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) - -auth_type ::= atom - ;; Defined by [IMAP-AUTH] - -base64 ::= *(4base64_char) [base64_terminal] - -base64_char ::= alpha / digit / "+" / "/" - -base64_terminal ::= (2base64_char "==") / (3base64_char "=") - -body ::= "(" body_type_1part / body_type_mpart ")" - -body_extension ::= nstring / number / "(" 1#body_extension ")" - ;; Future expansion. Client implementations - ;; MUST accept body_extension fields. Server - ;; implementations MUST NOT generate - ;; body_extension fields except as defined by - ;; future standard or standards-track - ;; revisions of this specification. - -body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp - [SPACE body_fld_lang - [SPACE 1#body_extension]]] - ;; MUST NOT be returned on non-extensible - ;; "BODY" fetch - -body_ext_mpart ::= body_fld_param - [SPACE body_fld_dsp SPACE body_fld_lang - [SPACE 1#body_extension]] - ;; MUST NOT be returned on non-extensible - ;; "BODY" fetch - -body_fields ::= body_fld_param SPACE body_fld_id SPACE - body_fld_desc SPACE body_fld_enc SPACE - body_fld_octets - -body_fld_desc ::= nstring - -body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil - -body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ - "QUOTED-PRINTABLE") <">) / string - -body_fld_id ::= nstring - -body_fld_lang ::= nstring / "(" 1#string ")" - - - - -Crispin Standards Track [Page 66] - -RFC 2060 IMAP4rev1 December 1996 - - -body_fld_lines ::= number - -body_fld_md5 ::= nstring - -body_fld_octets ::= number - -body_fld_param ::= "(" 1#(string SPACE string) ")" / nil - -body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) - [SPACE body_ext_1part] - -body_type_basic ::= media_basic SPACE body_fields - ;; MESSAGE subtype MUST NOT be "RFC822" - -body_type_mpart ::= 1*body SPACE media_subtype - [SPACE body_ext_mpart] - -body_type_msg ::= media_message SPACE body_fields SPACE envelope - SPACE body SPACE body_fld_lines - -body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines - -capability ::= "AUTH=" auth_type / atom - ;; New capabilities MUST begin with "X" or be - ;; registered with IANA as standard or - ;; standards-track - -capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" - [SPACE 1#capability] - ;; IMAP4rev1 servers which offer RFC 1730 - ;; compatibility MUST list "IMAP4" as the first - ;; capability. - -CHAR ::= <any 7-bit US-ASCII character except NUL, - 0x01 - 0x7f> - -CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff> - -command ::= tag SPACE (command_any / command_auth / - command_nonauth / command_select) CRLF - ;; Modal based on state - -command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command - ;; Valid in all states - -command_auth ::= append / create / delete / examine / list / lsub / - rename / select / status / subscribe / unsubscribe - ;; Valid only in Authenticated or Selected state - - - -Crispin Standards Track [Page 67] - -RFC 2060 IMAP4rev1 December 1996 - - -command_nonauth ::= login / authenticate - ;; Valid only when in Non-Authenticated state - -command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / - copy / fetch / store / uid / search - ;; Valid only when in Selected state - -continue_req ::= "+" SPACE (resp_text / base64) - -copy ::= "COPY" SPACE set SPACE mailbox - -CR ::= <ASCII CR, carriage return, 0x0D> - -create ::= "CREATE" SPACE mailbox - ;; Use of INBOX gives a NO error - -CRLF ::= CR LF - -CTL ::= <any ASCII control character and DEL, - 0x00 - 0x1f, 0x7f> - -date ::= date_text / <"> date_text <"> - -date_day ::= 1*2digit - ;; Day of month - -date_day_fixed ::= (SPACE digit) / 2digit - ;; Fixed-format version of date_day - -date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / - "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" - -date_text ::= date_day "-" date_month "-" date_year - -date_year ::= 4digit - -date_time ::= <"> date_day_fixed "-" date_month "-" date_year - SPACE time SPACE zone <"> - -delete ::= "DELETE" SPACE mailbox - ;; Use of INBOX gives a NO error - -digit ::= "0" / digit_nz - -digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / - "9" - - - - - -Crispin Standards Track [Page 68] - -RFC 2060 IMAP4rev1 December 1996 - - -envelope ::= "(" env_date SPACE env_subject SPACE env_from - SPACE env_sender SPACE env_reply_to SPACE env_to - SPACE env_cc SPACE env_bcc SPACE env_in_reply_to - SPACE env_message_id ")" - -env_bcc ::= "(" 1*address ")" / nil - -env_cc ::= "(" 1*address ")" / nil - -env_date ::= nstring - -env_from ::= "(" 1*address ")" / nil - -env_in_reply_to ::= nstring - -env_message_id ::= nstring - -env_reply_to ::= "(" 1*address ")" / nil - -env_sender ::= "(" 1*address ")" / nil - -env_subject ::= nstring - -env_to ::= "(" 1*address ")" / nil - -examine ::= "EXAMINE" SPACE mailbox - -fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / - "FAST" / fetch_att / "(" 1#fetch_att ")") - -fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / - "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / - "BODY" ["STRUCTURE"] / "UID" / - "BODY" [".PEEK"] section - ["<" number "." nz_number ">"] - -flag ::= "\Answered" / "\Flagged" / "\Deleted" / - "\Seen" / "\Draft" / flag_keyword / flag_extension - -flag_extension ::= "\" atom - ;; Future expansion. Client implementations - ;; MUST accept flag_extension flags. Server - ;; implementations MUST NOT generate - ;; flag_extension flags except as defined by - ;; future standard or standards-track - ;; revisions of this specification. - -flag_keyword ::= atom - - - -Crispin Standards Track [Page 69] - -RFC 2060 IMAP4rev1 December 1996 - - -flag_list ::= "(" #flag ")" - -greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF - -header_fld_name ::= astring - -header_list ::= "(" 1#header_fld_name ")" - -LF ::= <ASCII LF, line feed, 0x0A> - -list ::= "LIST" SPACE mailbox SPACE list_mailbox - -list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string - -list_wildcards ::= "%" / "*" - -literal ::= "{" number "}" CRLF *CHAR8 - ;; Number represents the number of CHAR8 octets - -login ::= "LOGIN" SPACE userid SPACE password - -lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox - -mailbox ::= "INBOX" / astring - ;; INBOX is case-insensitive. All case variants of - ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX - ;; not as an astring. Refer to section 5.1 for - ;; further semantic details of mailbox names. - -mailbox_data ::= "FLAGS" SPACE flag_list / - "LIST" SPACE mailbox_list / - "LSUB" SPACE mailbox_list / - "MAILBOX" SPACE text / - "SEARCH" [SPACE 1#nz_number] / - "STATUS" SPACE mailbox SPACE - "(" #<status_att number ")" / - number SPACE "EXISTS" / number SPACE "RECENT" - -mailbox_list ::= "(" #("\Marked" / "\Noinferiors" / - "\Noselect" / "\Unmarked" / flag_extension) ")" - SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox - -media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / - "MESSAGE" / "VIDEO") <">) / string) - SPACE media_subtype - ;; Defined in [MIME-IMT] - -media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> - - - -Crispin Standards Track [Page 70] - -RFC 2060 IMAP4rev1 December 1996 - - - ;; Defined in [MIME-IMT] - -media_subtype ::= string - ;; Defined in [MIME-IMT] - -media_text ::= <"> "TEXT" <"> SPACE media_subtype - ;; Defined in [MIME-IMT] - -message_data ::= nz_number SPACE ("EXPUNGE" / - ("FETCH" SPACE msg_att)) - -msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / - "FLAGS" SPACE "(" #(flag / "\Recent") ")" / - "INTERNALDATE" SPACE date_time / - "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / - "RFC822.SIZE" SPACE number / - "BODY" ["STRUCTURE"] SPACE body / - "BODY" section ["<" number ">"] SPACE nstring / - "UID" SPACE uniqueid) ")" - -nil ::= "NIL" - -nstring ::= string / nil - -number ::= 1*digit - ;; Unsigned 32-bit integer - ;; (0 <= n < 4,294,967,296) - -nz_number ::= digit_nz *digit - ;; Non-zero unsigned 32-bit integer - ;; (0 < n < 4,294,967,296) - -password ::= astring - -quoted ::= <"> *QUOTED_CHAR <"> - -QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> / - "\" quoted_specials - -quoted_specials ::= <"> / "\" - -rename ::= "RENAME" SPACE mailbox SPACE mailbox - ;; Use of INBOX as a destination gives a NO error - -response ::= *(continue_req / response_data) response_done - -response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / - mailbox_data / message_data / capability_data) - - - -Crispin Standards Track [Page 71] - -RFC 2060 IMAP4rev1 December 1996 - - - CRLF - -response_done ::= response_tagged / response_fatal - -response_fatal ::= "*" SPACE resp_cond_bye CRLF - ;; Server closes connection immediately - -response_tagged ::= tag SPACE resp_cond_state CRLF - -resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text - ;; Authentication condition - -resp_cond_bye ::= "BYE" SPACE resp_text - -resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text - ;; Status condition - -resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) - ;; text SHOULD NOT begin with "[" or "=" - -resp_text_code ::= "ALERT" / "PARSE" / - "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / - "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / - "UIDVALIDITY" SPACE nz_number / - "UNSEEN" SPACE nz_number / - atom [SPACE 1*<any TEXT_CHAR except "]">] - -search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] - 1#search_key - ;; [CHARSET] MUST be registered with IANA - -search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / - "BEFORE" SPACE date / "BODY" SPACE astring / - "CC" SPACE astring / "DELETED" / "FLAGGED" / - "FROM" SPACE astring / - "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / - "ON" SPACE date / "RECENT" / "SEEN" / - "SINCE" SPACE date / "SUBJECT" SPACE astring / - "TEXT" SPACE astring / "TO" SPACE astring / - "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / - "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / - ;; Above this line were in [IMAP2] - "DRAFT" / - "HEADER" SPACE header_fld_name SPACE astring / - "LARGER" SPACE number / "NOT" SPACE search_key / - "OR" SPACE search_key SPACE search_key / - "SENTBEFORE" SPACE date / "SENTON" SPACE date / - "SENTSINCE" SPACE date / "SMALLER" SPACE number / - - - -Crispin Standards Track [Page 72] - -RFC 2060 IMAP4rev1 December 1996 - - - "UID" SPACE set / "UNDRAFT" / set / - "(" 1#search_key ")" - -section ::= "[" [section_text / (nz_number *["." nz_number] - ["." (section_text / "MIME")])] "]" - -section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] - SPACE header_list / "TEXT" - -select ::= "SELECT" SPACE mailbox - -sequence_num ::= nz_number / "*" - ;; * is the largest number in use. For message - ;; sequence numbers, it is the number of messages - ;; in the mailbox. For unique identifiers, it is - ;; the unique identifier of the last message in - ;; the mailbox. - -set ::= sequence_num / (sequence_num ":" sequence_num) / - (set "," set) - ;; Identifies a set of messages. For message - ;; sequence numbers, these are consecutive - ;; numbers from 1 to the number of messages in - ;; the mailbox - ;; Comma delimits individual numbers, colon - ;; delimits between two numbers inclusive. - ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, - ;; 14,15 for a mailbox with 15 messages. - -SPACE ::= <ASCII SP, space, 0x20> - -status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" - -status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / - "UNSEEN" - -store ::= "STORE" SPACE set SPACE store_att_flags - -store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE - (flag_list / #flag) - -string ::= quoted / literal - -subscribe ::= "SUBSCRIBE" SPACE mailbox - -tag ::= 1*<any ATOM_CHAR except "+"> - -text ::= 1*TEXT_CHAR - - - -Crispin Standards Track [Page 73] - -RFC 2060 IMAP4rev1 December 1996 - - -text_mime2 ::= "=?" <charset> "?" <encoding> "?" - <encoded-text> "?=" - ;; Syntax defined in [MIME-HDRS] - -TEXT_CHAR ::= <any CHAR except CR and LF> - -time ::= 2digit ":" 2digit ":" 2digit - ;; Hours minutes seconds - -uid ::= "UID" SPACE (copy / fetch / search / store) - ;; Unique identifiers used instead of message - ;; sequence numbers - -uniqueid ::= nz_number - ;; Strictly ascending - -unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox - -userid ::= astring - -x_command ::= "X" atom <experimental command arguments> - -zone ::= ("+" / "-") 4digit - ;; Signed four-digit value of hhmm representing - ;; hours and minutes west of Greenwich (that is, - ;; (the amount that the given time differs from - ;; Universal Time). Subtracting the timezone - ;; from the given time will give the UT form. - ;; The Universal Time zone is "+0000". - -10. Author's Note - - This document is a revision or rewrite of earlier documents, and - supercedes the protocol specification in those documents: RFC 1730, - unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. - -11. Security Considerations - - IMAP4rev1 protocol transactions, including electronic mail data, are - sent in the clear over the network unless privacy protection is - negotiated in the AUTHENTICATE command. - - A server error message for an AUTHENTICATE command which fails due to - invalid credentials SHOULD NOT detail why the credentials are - invalid. - - Use of the LOGIN command sends passwords in the clear. This can be - avoided by using the AUTHENTICATE command instead. - - - -Crispin Standards Track [Page 74] - -RFC 2060 IMAP4rev1 December 1996 - - - A server error message for a failing LOGIN command SHOULD NOT specify - that the user name, as opposed to the password, is invalid. - - Additional security considerations are discussed in the section - discussing the AUTHENTICATE and LOGIN commands. - -12. Author's Address - - Mark R. Crispin - Networks and Distributed Computing - University of Washington - 4545 15th Aveneue NE - Seattle, WA 98105-4527 - - Phone: (206) 543-5762 - - EMail: MRC@CAC.Washington.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Crispin Standards Track [Page 75] - -RFC 2060 IMAP4rev1 December 1996 - - -Appendices - -A. References - -[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", -Work in Progress. - -[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, -RFC 1700, USC/Information Sciences Institute, October 1994. - -[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation -Information in Internet Messages: The Content-Disposition Header", -RFC 1806, June 1995. - -[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. -Carnegie-Mellon University, December 1994. - -[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC -2061, University of Washington, November 1996. - -[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected -IMAP4 Clients", Work in Progress. - -[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and -IMAP2bis", RFC 1732, University of Washington, December 1994. - -[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in -IMAP4", RFC 1733, University of Washington, December 1994. - -[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - -Obsolete Syntax", RFC 2062, University of Washington, November 1996. - -[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", -RFC 1176, University of Washington, August 1990. - -[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of -Languages", RFC 1766, March 1995. - -[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC -1864, October 1995. - -[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet -Mail Extensions) Part One: Format of Internet Message Bodies", RFC -2045, November 1996. - -[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose -Internet Mail Extensions) Part Two: Media Types", RFC 2046, -November 1996. - - - -Crispin Standards Track [Page 76] - -RFC 2060 IMAP4rev1 December 1996 - - -[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) -Part Three: Message Header Extensions for Non-ASCII Text", RFC -2047, November 1996. - -[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text -Messages", STD 11, RFC 822, University of Delaware, August 1982. - -[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, -RFC 821, USC/Information Sciences Institute, August 1982. - -[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe -Transformation Format of Unicode", RFC 1642, July 1994. - -B. Changes from RFC 1730 - -1) The STATUS command has been added. - -2) Clarify in the formal syntax that the "#" construct can never -refer to multiple spaces. - -3) Obsolete syntax has been moved to a separate document. - -4) The PARTIAL command has been obsoleted. - -5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and -RFC822.TEXT.PEEK fetch attributes have been obsoleted. - -6) The "<" origin "." size ">" suffix for BODY text attributes has -been added. - -7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part -specifiers have been added. - -8) Support for Content-Disposition and Content-Language has been -added. - -9) The restriction on fetching nested MULTIPART parts has been -removed. - -10) Body part number 0 has been obsoleted. - -11) Server-supported authenticators are now identified by -capabilities. - - - - - - - - -Crispin Standards Track [Page 77] - -RFC 2060 IMAP4rev1 December 1996 - - -12) The capability that identifies this protocol is now called -"IMAP4rev1". A server that provides backwards support for RFC 1730 -SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its -CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as -the first capability, it MUST listed first in the response. - -13) A description of the mailbox name namespace convention has been -added. - -14) A description of the international mailbox name convention has -been added. - -15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT -and UIDVALIDITY. This is a change from the IMAP STATUS -Work in Progress and not from RFC-1730 - -16) Add a clarification that a null mailbox name argument to the LIST -command returns an untagged LIST response with the hierarchy -delimiter and root of the reference argument. - -17) Define terms such as "MUST", "SHOULD", and "MUST NOT". - -18) Add a section which defines message attributes and more -thoroughly details the semantics of message sequence numbers, UIDs, -and flags. - -19) Add a clarification detailing the circumstances when a client may -send multiple commands without waiting for a response, and the -circumstances in which ambiguities may result. - -20) Add a recommendation on server behavior for DELETE and RENAME -when inferior hierarchical names of the given name exist. - -21) Add a clarification that a mailbox name may not be unilaterally -unsubscribed by the server, even if that mailbox name no longer -exists. - -22) Add a clarification that LIST should return its results quickly -without undue delay. - -23) Add a clarification that the date_time argument to APPEND sets -the internal date of the message. - -24) Add a clarification on APPEND behavior when the target mailbox is -the currently selected mailbox. - - - - - - -Crispin Standards Track [Page 78] - -RFC 2060 IMAP4rev1 December 1996 - - -25) Add a clarification that external changes to flags should be -always announced via an untagged FETCH even if the current command is -a STORE with the ".SILENT" suffix. - -26) Add a clarification that COPY appends to the target mailbox. - -27) Add the NEWNAME response code. - -28) Rewrite the description of the untagged BYE response to clarify -its semantics. - -29) Change the reference for the body MD5 to refer to the proper RFC. - -30) Clarify that the formal syntax contains rules which may overlap, -and that in the event of such an overlap the rule which occurs first -takes precedence. - -31) Correct the definition of body_fld_param. - -32) More formal syntax for capability_data. - -33) Clarify that any case variant of "INBOX" must be interpreted as -INBOX. - -34) Clarify that the human-readable text in resp_text should not -begin with "[" or "=". - -35) Change MIME references to Draft Standard documents. - -36) Clarify \Recent semantics. - -37) Additional examples. - -C. Key Word Index - - +FLAGS <flag list> (store command data item) ............... 45 - +FLAGS.SILENT <flag list> (store command data item) ........ 46 - -FLAGS <flag list> (store command data item) ............... 46 - -FLAGS.SILENT <flag list> (store command data item) ........ 46 - ALERT (response code) ...................................... 50 - ALL (fetch item) ........................................... 41 - ALL (search key) ........................................... 38 - ANSWERED (search key) ...................................... 38 - APPEND (command) ........................................... 34 - AUTHENTICATE (command) ..................................... 20 - BAD (response) ............................................. 52 - BCC <string> (search key) .................................. 38 - BEFORE <date> (search key) ................................. 39 - - - -Crispin Standards Track [Page 79] - -RFC 2060 IMAP4rev1 December 1996 - - - BODY (fetch item) .......................................... 41 - BODY (fetch result) ........................................ 58 - BODY <string> (search key) ................................. 39 - BODY.PEEK[<section>]<<partial>> (fetch item) ............... 44 - BODYSTRUCTURE (fetch item) ................................. 44 - BODYSTRUCTURE (fetch result) ............................... 59 - BODY[<section>]<<origin_octet>> (fetch result) ............. 58 - BODY[<section>]<<partial>> (fetch item) .................... 41 - BYE (response) ............................................. 52 - Body Structure (message attribute) ......................... 11 - CAPABILITY (command) ....................................... 18 - CAPABILITY (response) ...................................... 53 - CC <string> (search key) ................................... 39 - CHECK (command) ............................................ 36 - CLOSE (command) ............................................ 36 - COPY (command) ............................................. 46 - CREATE (command) ........................................... 25 - DELETE (command) ........................................... 26 - DELETED (search key) ....................................... 39 - DRAFT (search key) ......................................... 39 - ENVELOPE (fetch item) ...................................... 44 - ENVELOPE (fetch result) .................................... 62 - EXAMINE (command) .......................................... 24 - EXISTS (response) .......................................... 56 - EXPUNGE (command) .......................................... 37 - EXPUNGE (response) ......................................... 57 - Envelope Structure (message attribute) ..................... 11 - FAST (fetch item) .......................................... 44 - FETCH (command) ............................................ 41 - FETCH (response) ........................................... 58 - FLAGGED (search key) ....................................... 39 - FLAGS (fetch item) ......................................... 44 - FLAGS (fetch result) ....................................... 62 - FLAGS (response) ........................................... 56 - FLAGS <flag list> (store command data item) ................ 45 - FLAGS.SILENT <flag list> (store command data item) ......... 45 - FROM <string> (search key) ................................. 39 - FULL (fetch item) .......................................... 44 - Flags (message attribute) .................................. 9 - HEADER (part specifier) .................................... 41 - HEADER <field-name> <string> (search key) .................. 39 - HEADER.FIELDS <header_list> (part specifier) ............... 41 - HEADER.FIELDS.NOT <header_list> (part specifier) ........... 41 - INTERNALDATE (fetch item) .................................. 44 - INTERNALDATE (fetch result) ................................ 62 - Internal Date (message attribute) .......................... 10 - KEYWORD <flag> (search key) ................................ 39 - Keyword (type of flag) ..................................... 10 - - - -Crispin Standards Track [Page 80] - -RFC 2060 IMAP4rev1 December 1996 - - - LARGER <n> (search key) .................................... 39 - LIST (command) ............................................. 30 - LIST (response) ............................................ 54 - LOGIN (command) ............................................ 22 - LOGOUT (command) ........................................... 20 - LSUB (command) ............................................. 32 - LSUB (response) ............................................ 55 - MAY (specification requirement term) ....................... 5 - MESSAGES (status item) ..................................... 33 - MIME (part specifier) ...................................... 42 - MUST (specification requirement term) ...................... 4 - MUST NOT (specification requirement term) .................. 4 - Message Sequence Number (message attribute) ................ 9 - NEW (search key) ........................................... 39 - NEWNAME (response code) .................................... 50 - NO (response) .............................................. 51 - NOOP (command) ............................................. 19 - NOT <search-key> (search key) .............................. 39 - OK (response) .............................................. 51 - OLD (search key) ........................................... 39 - ON <date> (search key) ..................................... 39 - OPTIONAL (specification requirement term) .................. 5 - OR <search-key1> <search-key2> (search key) ................ 39 - PARSE (response code) ...................................... 50 - PERMANENTFLAGS (response code) ............................. 50 - PREAUTH (response) ......................................... 52 - Permanent Flag (class of flag) ............................. 10 - READ-ONLY (response code) .................................. 50 - READ-WRITE (response code) ................................. 50 - RECENT (response) .......................................... 57 - RECENT (search key) ........................................ 39 - RECENT (status item) ....................................... 33 - RENAME (command) ........................................... 27 - REQUIRED (specification requirement term) .................. 4 - RFC822 (fetch item) ........................................ 44 - RFC822 (fetch result) ...................................... 63 - RFC822.HEADER (fetch item) ................................. 44 - RFC822.HEADER (fetch result) ............................... 62 - RFC822.SIZE (fetch item) ................................... 44 - RFC822.SIZE (fetch result) ................................. 62 - RFC822.TEXT (fetch item) ................................... 44 - RFC822.TEXT (fetch result) ................................. 62 - SEARCH (command) ........................................... 37 - SEARCH (response) .......................................... 55 - SEEN (search key) .......................................... 40 - SELECT (command) ........................................... 23 - SENTBEFORE <date> (search key) ............................. 40 - SENTON <date> (search key) ................................. 40 - - - -Crispin Standards Track [Page 81] - -RFC 2060 IMAP4rev1 December 1996 - - - SENTSINCE <date> (search key) .............................. 40 - SHOULD (specification requirement term) .................... 5 - SHOULD NOT (specification requirement term) ................ 5 - SINCE <date> (search key) .................................. 40 - SMALLER <n> (search key) ................................... 40 - STATUS (command) ........................................... 33 - STATUS (response) .......................................... 55 - STORE (command) ............................................ 45 - SUBJECT <string> (search key) .............................. 40 - SUBSCRIBE (command) ........................................ 29 - Session Flag (class of flag) ............................... 10 - System Flag (type of flag) ................................. 9 - TEXT (part specifier) ...................................... 42 - TEXT <string> (search key) ................................. 40 - TO <string> (search key) ................................... 40 - TRYCREATE (response code) .................................. 51 - UID (command) .............................................. 47 - UID (fetch item) ........................................... 44 - UID (fetch result) ......................................... 63 - UID <message set> (search key) ............................. 40 - UIDNEXT (status item) ...................................... 33 - UIDVALIDITY (response code) ................................ 51 - UIDVALIDITY (status item) .................................. 34 - UNANSWERED (search key) .................................... 40 - UNDELETED (search key) ..................................... 40 - UNDRAFT (search key) ....................................... 40 - UNFLAGGED (search key) ..................................... 40 - UNKEYWORD <flag> (search key) .............................. 40 - UNSEEN (response code) ..................................... 51 - UNSEEN (search key) ........................................ 40 - UNSEEN (status item) ....................................... 34 - UNSUBSCRIBE (command) ...................................... 30 - Unique Identifier (UID) (message attribute) ................ 7 - X<atom> (command) .......................................... 48 - [RFC-822] Size (message attribute) ......................... 11 - \Answered (system flag) .................................... 9 - \Deleted (system flag) ..................................... 9 - \Draft (system flag) ....................................... 9 - \Flagged (system flag) ..................................... 9 - \Marked (mailbox name attribute) ........................... 54 - \Noinferiors (mailbox name attribute) ...................... 54 - \Noselect (mailbox name attribute) ......................... 54 - \Recent (system flag) ...................................... 10 - \Seen (system flag) ........................................ 9 - \Unmarked (mailbox name attribute) ......................... 54 - - - - - - -Crispin Standards Track [Page 82] - diff --git a/RFC/rfc2061.txt b/RFC/rfc2061.txt deleted file mode 100644 index 7cb02bb2..00000000 --- a/RFC/rfc2061.txt +++ /dev/null @@ -1,171 +0,0 @@ - - - - - - -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 deleted file mode 100644 index 865d1dad..00000000 --- a/RFC/rfc2062.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group M. Crispin -Request for Comments: 2062 University of Washington -Category: Informational December 1996 - - - Internet Message Access Protocol - Obsolete Syntax - -Status of this Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -Abstract - - This document describes obsolete syntax which may be encountered by - IMAP4 implementations which deal with older versions of the Internet - Mail Access Protocol. IMAP4 implementations MAY implement this - syntax in order to maximize interoperability with older - implementations. - - This document repeats information from earlier documents, most - notably RFC 1176 and RFC 1730. - -Obsolete Commands and Fetch Data Items - - The following commands are OBSOLETE. It is NOT required to support - any of these commands or fetch data items in new server - implementations. These commands are documented here for the benefit - of implementors who may wish to support them for compatibility with - old client implementations. - - The section headings of these commands are intended to correspond - with where they would be located in the main document if they were - not obsoleted. - -6.3.OBS.1. FIND ALL.MAILBOXES Command - - Arguments: mailbox name with possible wildcards - - Data: untagged responses: MAILBOX - - Result: OK - find completed - NO - find failure: can't list that name - BAD - command unknown or arguments invalid - - - - - - -Crispin Informational [Page 1] - -RFC 2062 IMAP4 Obsolete December 1996 - - - The FIND ALL.MAILBOXES command returns a subset of names from the - complete set of all names available to the user. It returns zero - or more untagged MAILBOX replies. The mailbox argument to FIND - ALL.MAILBOXES is similar to that for LIST with an empty reference, - except that the characters "%" and "?" match a single character. - - Example: C: A002 FIND ALL.MAILBOXES * - S: * MAILBOX blurdybloop - S: * MAILBOX INBOX - S: A002 OK FIND ALL.MAILBOXES completed - -6.3.OBS.2. FIND MAILBOXES Command - - Arguments: mailbox name with possible wildcards - - Data: untagged responses: MAILBOX - - Result: OK - find completed - NO - find failure: can't list that name - BAD - command unknown or arguments invalid - - The FIND MAILBOXES command returns a subset of names from the set - of names that the user has declared as being "active" or - "subscribed". It returns zero or more untagged MAILBOX replies. - The mailbox argument to FIND MAILBOXES is similar to that for LSUB - with an empty reference, except that the characters "%" and "?" - match a single character. - - Example: C: A002 FIND MAILBOXES * - S: * MAILBOX blurdybloop - S: * MAILBOX INBOX - S: A002 OK FIND MAILBOXES completed - -6.3.OBS.3. SUBSCRIBE MAILBOX Command - - Arguments: mailbox name - - Data: no specific data for this command - - Result: OK - subscribe completed - NO - subscribe failure: can't subscribe to that name - BAD - command unknown or arguments invalid - - The SUBSCRIBE MAILBOX command is identical in effect to the - SUBSCRIBE command. A server which implements this command must be - able to distinguish between a SUBSCRIBE MAILBOX command and a - SUBSCRIBE command with a mailbox name argument of "MAILBOX". - - - - -Crispin Informational [Page 2] - -RFC 2062 IMAP4 Obsolete December 1996 - - - Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime - S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime - completed - C: A003 SUBSCRIBE MAILBOX - S: A003 OK SUBSCRIBE to MAILBOX completed - - -6.3.OBS.4. UNSUBSCRIBE MAILBOX Command - - Arguments: mailbox name - - Data: no specific data for this command - - Result: OK - unsubscribe completed - NO - unsubscribe failure: can't unsubscribe that name - BAD - command unknown or arguments invalid - - The UNSUBSCRIBE MAILBOX command is identical in effect to the - UNSUBSCRIBE command. A server which implements this command must - be able to distinguish between a UNSUBSCRIBE MAILBOX command and - an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX". - - Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime - S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime - completed - C: A003 UNSUBSCRIBE MAILBOX - S: A003 OK UNSUBSCRIBE from MAILBOX completed - -6.4.OBS.1 PARTIAL Command - - Arguments: message sequence number - message data item name - position of first octet - number of octets - - Data: untagged responses: FETCH - - Result: OK - partial completed - NO - partial error: can't fetch that data - BAD - command unknown or arguments invalid - - The PARTIAL command is equivalent to the associated FETCH command, - with the added functionality that only the specified number of - octets, beginning at the specified starting octet, are returned. - Only a single message can be fetched at a time. The first octet - of a message, and hence the minimum for the starting octet, is - octet 1. - - - - -Crispin Informational [Page 3] - -RFC 2062 IMAP4 Obsolete December 1996 - - - The following FETCH items are valid data for PARTIAL: RFC822, - RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK - forms of these. - - Any partial fetch that attempts to read beyond the end of the text - is truncated as appropriate. If the starting octet is beyond the - end of the text, an empty string is returned. - - The data are returned with the FETCH response. There is no - indication of the range of the partial data in this response. It - is not possible to stream multiple PARTIAL commands of the same - data item without processing and synchronizing at each step, since - streamed commands may be executed out of order. - - There is no requirement that partial fetches follow any sequence. - For example, if a partial fetch of octets 1 through 10000 breaks - in an awkward place for BASE64 decoding, it is permitted to - continue with a partial fetch of 9987 through 19987, etc. - - The handling of the \Seen flag is the same as in the associated - FETCH command. - - Example: C: A005 PARTIAL 4 RFC822 1 1024 - S: * 1 FETCH (RFC822 {1024} - S: Return-Path: <gray@cac.washington.edu> - S: ... - S: ......... FLAGS (\Seen)) - S: A005 OK PARTIAL completed - -6.4.5.OBS.1 Obsolete FETCH Data Items - - The following FETCH data items are obsolete: - - BODY[<...>0] A body part number of 0 is the [RFC-822] header of - the message. BODY[0] is functionally equivalent to - BODY[HEADER], differing in the syntax of the - resulting untagged FETCH data (BODY[0] is - returned). - - RFC822.HEADER.LINES <header_list> - Functionally equivalent to BODY.PEEK[HEADER.LINES - <header_list>], differing in the syntax of the - resulting untagged FETCH data (RFC822.HEADER is - returned). - - - - - - - -Crispin Informational [Page 4] - -RFC 2062 IMAP4 Obsolete December 1996 - - - RFC822.HEADER.LINES.NOT <header_list> - Functionally equivalent to - BODY.PEEK[HEADER.LINES.NOT <header_list>], - differing in the syntax of the resulting untagged - FETCH data (RFC822.HEADER is returned). - - RFC822.PEEK Functionally equivalent to BODY.PEEK[], except for - the syntax of the resulting untagged FETCH data - (RFC822 is returned). - - RFC822.TEXT.PEEK - Functionally equivalent to BODY.PEEK[TEXT], except - for the syntax of the resulting untagged FETCH data - (RFC822.TEXT is returned). - -Obsolete Responses - - The following responses are OBSOLETE. Except as noted below, these - responses MUST NOT be transmitted by new server implementations. - Client implementations SHOULD accept these responses. - - The section headings of these responses are intended to correspond - with where they would be located in the main document if they were - not obsoleted. - -7.2.OBS.1. MAILBOX Response - - Data: name - - The MAILBOX response MUST NOT be transmitted by server - implementations except in response to the obsolete FIND MAILBOXES - and FIND ALL.MAILBOXES commands. Client implementations that do - not use these commands MAY ignore this response. It is documented - here for the benefit of implementors who may wish to support it - for compatibility with old client implementations. - - This response occurs as a result of the FIND MAILBOXES and FIND - ALL.MAILBOXES commands. It returns a single name that matches the - FIND specification. There are no attributes or hierarchy - delimiter. - - Example: S: * MAILBOX blurdybloop - - - - - - - - - -Crispin Informational [Page 5] - -RFC 2062 IMAP4 Obsolete December 1996 - - -7.3.OBS.1. COPY Response - - Data: none - - The COPY response MUST NOT be transmitted by new server - implementations. Client implementations MUST ignore the COPY - response. It is documented here for the benefit of client - implementors who may encounter this response from old server - implementations. - - In some experimental versions of this protocol, this response was - returned in response to a COPY command to indicate on a - per-message basis that the message was copied successfully. - - Example: S: * 44 COPY - -7.3.OBS.2. STORE Response - - Data: message data - - The STORE response MUST NOT be transmitted by new server - implementations. Client implementations MUST treat the STORE - response as equivalent to the FETCH response. It is documented - here for the benefit of client implementors who may encounter this - response from old server implementations. - - In some experimental versions of this protocol, this response was - returned instead of FETCH in response to a STORE command to report - the new value of the flags. - - Example: S: * 69 STORE (FLAGS (\Deleted)) - -Formal Syntax of Obsolete Commands and Responses - - Each obsolete syntax rule that is suffixed with "_old" is added to - the corresponding name in the formal syntax. For example, - command_auth_old adds the FIND command to command_auth. - - command_auth_old ::= find - - command_select_old - ::= partial - - date_year_old ::= 2digit - ;; (year - 1900) - - date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year - SPACE time "-" zone_name <"> - - - -Crispin Informational [Page 6] - -RFC 2062 IMAP4 Obsolete December 1996 - - - find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE - list_mailbox - - fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list / - fetch_text_old - - fetch_text_old ::= "BODY" [".PEEK"] section_old / - "RFC822" [".HEADER" / ".TEXT" [".PEEK"]] - - msg_data_old ::= "COPY" / ("STORE" SPACE msg_att) - - partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE - number SPACE number - - section_old ::= "[" (number ["." number]) "]" - - subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox - - unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox - - zone_name ::= "UT" / "GMT" / "Z" / ;; +0000 - "AST" / "EDT" / ;; -0400 - "EST" / "CDT" / ;; -0500 - "CST" / "MDT" / ;; -0600 - "MST" / "PDT" / ;; -0700 - "PST" / "YDT" / ;; -0800 - "YST" / "HDT" / ;; -0900 - "HST" / "BDT" / ;; -1000 - "BST" / ;; -1100 - "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6 - "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12 - "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6 - "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12 - -Security Considerations - - Security issues are not discussed in this memo. - - - - - - - - - - - - - - -Crispin Informational [Page 7] - -RFC 2062 IMAP4 Obsolete December 1996 - - -Author's Address - - Mark R. Crispin - Networks and Distributed Computing - University of Washington - 4545 15th Aveneue NE - Seattle, WA 98105-4527 - - Phone: (206) 543-5762 - EMail: MRC@CAC.Washington.EDU - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Crispin Informational [Page 8] - diff --git a/RFC/rfc2177.txt b/RFC/rfc2177.txt deleted file mode 100644 index ef28fad3..00000000 --- a/RFC/rfc2177.txt +++ /dev/null @@ -1,227 +0,0 @@ -
-
-
-
-
-
-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 deleted file mode 100644 index 4a2725bf..00000000 --- a/RFC/rfc2195.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -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 deleted file mode 100644 index dbea10b2..00000000 --- a/RFC/rfc2449.txt +++ /dev/null @@ -1,1067 +0,0 @@ -
-
-
-
-
-
-Network Working Group R. Gellens
-Request for Comments: 2449 Qualcomm
-Updates: 1939 C. Newman
-Category: Standards Track Innosoft
- L. Lundblade
- Qualcomm
- November 1998
-
-
- POP3 Extension Mechanism
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
-IESG Note
-
- This extension to the POP3 protocol is to be used by a server to
- express policy descisions taken by the server administrator. It is
- not an endorsement of implementations of further POP3 extensions
- generally. It is the general view that the POP3 protocol should stay
- simple, and for the simple purpose of downloading email from a mail
- server. If more complicated operations are needed, the IMAP protocol
- [RFC 2060] should be used. The first paragraph of section 7 should
- be read very carefully.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Conventions Used in this Document . . . . . . . . . . . . . 3
- 3. General Command and Response Grammar . . . . . . . . . . . . 3
- 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
- 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
- 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
- 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
- 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
- 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
- 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
- 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
- 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
-
-
-
-Gellens, et. al. Standards Track [Page 1]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
- 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
- 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
- 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
- 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
- 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
- 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
- 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
- 10. Security Considerations . . . . . . . . . . . . . . . . . . 17
- 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
- 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
- 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
-
-1. Introduction
-
- The Post Office Protocol version 3 [POP3] is very widely used.
- However, while it includes some optional commands (and some useful
- protocol extensions have been published), it lacks a mechanism for
- advertising support for these extensions or for behavior variations.
-
- Currently these optional features and extensions can only be detected
- by probing, if at all. This is at best inefficient, and possibly
- worse. As a result, some clients have manual configuration options
- for POP3 server capabilities.
-
- Because one of the most important characteristics of POP3 is its
- simplicity, it is desirable that extensions be few in number (see
- section 7). However, some extensions are necessary (such as ones
- that provide improved security [POP-AUTH]), while others are very
- desirable in certain situations. In addition, a means for
- discovering server behavior is needed.
-
- This memo updates RFC 1939 [POP3] to define a mechanism to announce
- support for optional commands, extensions, and unconditional server
- behavior. Included is an initial set of currently deployed
- capabilities which vary between server implementations, and several
- new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE
- and IMPLEMENTATION). This document also extends POP3 error messages
- so that machine parsable codes can be provided to the client. An
- initial set of response codes is included. In addition, an [ABNF]
- specification of POP3 commands and responses is defined.
-
- Public comments should be sent to the IETF POP3 Extensions mailing
- list, <ietf-pop3ext@imc.org>. To subscribe, send a message
- containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.
-
-
-
-
-Gellens, et. al. Standards Track [Page 2]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-2. Conventions Used in this Document
-
- The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
- and "MAY" in this document are to be interpreted as described in "Key
- words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
-3. General Command and Response Grammar
-
- The general form of POP3 commands and responses is described using
- [ABNF]:
-
- POP3 commands:
-
- command = keyword *(SP param) CRLF ;255 octets maximum
- keyword = 3*4VCHAR
- param = 1*VCHAR
-
- POP3 responses:
-
- response = greeting / single-line / capa-resp / multi-line
- capa-resp = single-line *capability "." CRLF
- capa-tag = 1*cchar
- capability = capa-tag *(SP param) CRLF ;512 octets maximum
- cchar = %x21-2D / %x2F-7F
- ;printable ASCII, excluding "."
- dot-stuffed = *CHAR CRLF ;must be dot-stuffed
- gchar = %x21-3B / %x3D-7F
- ;printable ASCII, excluding "<"
- greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
- ;512 octets maximum
- multi-line = single-line *dot-stuffed "." CRLF
- rchar = %x21-2E / %x30-5C / %x5E-7F
- ;printable ASCII, excluding "/" and "]"
- resp-code = "[" resp-level *("/" resp-level) "]"
- resp-level = 1*rchar
- schar = %x21-5A / %x5C-7F
- ;printable ASCII, excluding "["
- single-line = status [SP text] CRLF ;512 octets maximum
- status = "+OK" / "-ERR"
- text = *schar / resp-code *CHAR
- timestamp = "<" *VCHAR ">"
- ;MUST conform to RFC-822 msg-id
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 3]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-4. Parameter and Response Lengths
-
- This specification increases the length restrictions on commands and
- parameters imposed by RFC 1939.
-
- The maximum length of a command is increased from 47 characters (4
- character command, single space, 40 character argument, CRLF) to 255
- octets, including the terminating CRLF.
-
- Servers which support the CAPA command MUST support commands up to
- 255 octets. Servers MUST also support the largest maximum command
- length specified by any supported capability.
-
- The maximum length of the first line of a command response (including
- the initial greeting) is unchanged at 512 octets (including the
- terminating CRLF).
-
-5. The CAPA Command
-
- The POP3 CAPA command returns a list of capabilities supported by the
- POP3 server. It is available in both the AUTHORIZATION and
- TRANSACTION states.
-
- A capability description MUST document in which states the capability
- is announced, and in which states the commands are valid.
-
- Capabilities available in the AUTHORIZATION state MUST be announced
- in both states.
-
- If a capability is announced in both states, but the argument might
- differ after authentication, this possibility MUST be stated in the
- capability description.
-
- (These requirements allow a client to issue only one CAPA command if
- it does not use any TRANSACTION-only capabilities, or any
- capabilities whose values may differ after authentication.)
-
- If the authentication step negotiates an integrity protection layer,
- the client SHOULD reissue the CAPA command after authenticating, to
- check for active down-negotiation attacks.
-
- Each capability may enable additional protocol commands, additional
- parameters and responses for existing commands, or describe an aspect
- of server behavior. These details are specified in the description
- of the capability.
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 4]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Section 3 describes the CAPA response using [ABNF]. When a
- capability response describes an optional command, the <capa-tag>
- SHOULD be identical to the command keyword. CAPA response tags are
- case-insensitive.
-
- CAPA
-
- Arguments:
- none
-
- Restrictions:
- none
-
- Discussion:
- An -ERR response indicates the capability command is not
- implemented and the client will have to probe for
- capabilities as before.
-
- An +OK response is followed by a list of capabilities, one
- per line. Each capability name MAY be followed by a single
- space and a space-separated list of parameters. Each
- capability line is limited to 512 octets (including the
- CRLF). The capability list is terminated by a line
- containing a termination octet (".") and a CRLF pair.
-
- Possible Responses:
- +OK -ERR
-
- Examples:
- C: CAPA
- S: +OK Capability list follows
- S: TOP
- S: USER
- S: SASL CRAM-MD5 KERBEROS_V4
- S: RESP-CODES
- S: LOGIN-DELAY 900
- S: PIPELINING
- S: EXPIRE 60
- S: UIDL
- S: IMPLEMENTATION Shlemazle-Plotz-v302
- S: .
-
-6. Initial Set of Capabilities
-
- This section defines an initial set of POP3 capabilities. These
- include the optional POP3 commands, already published POP3
- extensions, and behavior variations between POP3 servers which can
- impact clients.
-
-
-
-Gellens, et. al. Standards Track [Page 5]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Note that there is no APOP capability, even though APOP is an
- optional command in [POP3]. Clients discover server support of APOP
- by the presence in the greeting banner of an initial challenge
- enclosed in angle brackets ("<>"). Therefore, an APOP capability
- would introduce two ways for a server to announce the same thing.
-
-6.1. TOP capability
-
- CAPA tag:
- TOP
-
- Arguments:
- none
-
- Added commands:
- TOP
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- TRANSACTION
-
- Specification reference:
- [POP3]
-
- Discussion:
- The TOP capability indicates the optional TOP command is
- available.
-
-6.2. USER capability
-
- CAPA tag:
- USER
-
- Arguments:
- none
-
- Added commands:
- USER PASS
-
- Standard commands affected:
- none
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 6]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- AUTHENTICATION
-
- Specification reference:
- [POP3]
-
- Discussion:
- The USER capability indicates that the USER and PASS commands
- are supported, although they may not be available to all users.
-
-6.3. SASL capability
-
- CAPA tag:
- SASL
-
- Arguments:
- Supported SASL mechanisms
-
- Added commands:
- AUTH
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- AUTHENTICATION
-
- Specification reference:
- [POP-AUTH, SASL]
-
- Discussion:
- The POP3 AUTH command [POP-AUTH] permits the use of [SASL]
- authentication mechanisms with POP3. The SASL capability
- indicates that the AUTH command is available and that it supports
- an optional base64 encoded second argument for an initial client
- response as described in the SASL specification. The argument to
- the SASL capability is a space separated list of SASL mechanisms
- which are supported.
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 7]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-6.4. RESP-CODES capability
-
- CAPA tag:
- RESP-CODES
-
- Arguments:
- none
-
- Added commands:
- none
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- n/a
-
- Specification reference:
- this document
-
- Discussion:
- The RESP-CODES capability indicates that any response text issued
- by this server which begins with an open square bracket ("[") is
- an extended response code (see section 8).
-
-6.5. LOGIN-DELAY capability
-
- CAPA tag:
- LOGIN-DELAY
-
- Arguments:
- minimum seconds between logins; optionally followed by USER in
- AUTHENTICATION state.
-
- Added commands:
- none
-
- Standard commands affected:
- USER PASS APOP AUTH
-
- Announced states / possible differences:
- both / yes
-
- Commands valid in states:
- n/a
-
-
-
-Gellens, et. al. Standards Track [Page 8]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Specification reference:
- this document
-
- Discussion:
- POP3 clients often login frequently to check for new mail.
- Unfortunately, the process of creating a connection,
- authenticating the user, and opening the user's maildrop can be
- very resource intensive on the server. A number of deployed POP3
- servers try to reduce server load by requiring a delay between
- logins. The LOGIN-DELAY capability includes an integer argument
- which indicates the number of seconds after an "+OK" response to
- a PASS, APOP, or AUTH command before another authentication will
- be accepted. Clients which permit the user to configure a mail
- check interval SHOULD use this capability to determine the
- minimum permissible interval. Servers which advertise LOGIN-
- DELAY SHOULD enforce it.
-
- If the minimum login delay period could differ per user (that is,
- the LOGIN-DELAY argument might change after authentication), the
- server MUST announce in AUTHENTICATION state the largest value
- which could be set for any user. This might be the largest value
- currently in use for any user (so only one value per server), or
- even the largest value which the server permits to be set for any
- user. The server SHOULD append the token "USER" to the LOGIN-
- DELAY parameter in AUTHENTICATION state, to inform the client
- that a more accurate value is available after authentication.
- The server SHOULD announce the more accurate value in TRANSACTION
- state. (The "USER" token allows the client to decide if a second
- CAPA command is needed or not.)
-
- Servers enforce LOGIN-DELAY by rejecting an authentication
- command with or without the LOGIN-DELAY error response. See
- section 8.1.1 for more information.
-
-6.6. PIPELINING capability
-
- CAPA tag:
- PIPELINING
-
- Arguments:
- none
-
- Added commands:
- none
-
- Standard commands affected:
- all
-
-
-
-
-Gellens, et. al. Standards Track [Page 9]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- n/a
-
- Specification reference:
- this document
-
- Discussion:
- The PIPELINING capability indicates the server is capable of
- accepting multiple commands at a time; the client does not have
- to wait for the response to a command before issuing a subsequent
- command. If a server supports PIPELINING, it MUST process each
- command in turn. If a client uses PIPELINING, it MUST keep track
- of which commands it has outstanding, and match server responses
- to commands in order. If either the client or server uses
- blocking writes, it MUST not exceed the window size of the
- underlying transport layer.
-
- Some POP3 clients have an option to indicate the server supports
- "Overlapped POP3 commands." This capability removes the need to
- configure this at the client.
-
- This is roughly synonymous with the ESMTP PIPELINING extension
- [PIPELINING], however, since SMTP [SMTP] tends to have short
- commands and responses, the benefit is in grouping multiple
- commands and sending them as a unit. While there are cases of
- this in POP (for example, USER and PASS could be batched,
- multiple RETR and/or DELE commands could be sent as a group),
- because POP has short commands and sometimes lengthy responses,
- there is also an advantage is sending new commands while still
- receiving the response to an earlier command (for example,
- sending RETR and/or DELE commands while processing a UIDL reply).
-
-6.7. EXPIRE capability
-
- CAPA tag:
- EXPIRE
-
- Arguments:
- server-guaranteed minimum retention days, or NEVER; optionally
- followed by USER in AUTHENTICATION state
-
- Added commands:
- none
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 10]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / yes
-
- Commands valid in states:
- n/a
-
- Specification reference:
- this document
-
- Discussion:
- While POP3 allows clients to leave messages on the server, RFC
- 1939 [POP3] warns about the problems that may arise from this,
- and allows servers to delete messages based on site policy.
-
- The EXPIRE capability avoids the problems mentioned in RFC 1939,
- by allowing the server to inform the client as to the policy in
- effect. The argument to the EXPIRE capability indicates the
- minimum server retention period, in days, for messages on the
- server.
-
- EXPIRE 0 indicates the client is not permitted to leave mail on
- the server; when the session enters the UPDATE state the server
- MAY assume an implicit DELE for each message which was downloaded
- with RETR.
-
- EXPIRE NEVER asserts that the server does not delete messages.
-
- The concept of a "retention period" is intentionally vague.
- Servers may start counting days to expiration when a message is
- added to a maildrop, when a client becomes aware of the existence
- of a message through the LIST or UIDL commands, when a message
- has been acted upon in some way (for example, TOP or RETR), or at
- some other event. The EXPIRE capability cannot provide a precise
- indication as to exactly when any specific message will expire.
- The capability is intended to make it easier for clients to
- behave in ways which conform to site policy and user wishes. For
- example, a client might display a warning for attempts to
- configure a "leave mail on server" period which is greater than
- or equal to some percentage of the value announced by the server.
-
- If a site uses any automatic deletion policy, it SHOULD use the
- EXPIRE capability to announce this.
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 11]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- The EXPIRE capability, with a parameter other than 0 or NEVER, is
- intended to let the client know that the server does permit mail
- to be left on the server, and to present a value which is the
- smallest which might be in force.
-
- Sites which permit users to retain messages indefinitely SHOULD
- announce this with the EXPIRE NEVER response.
-
- If the expiration policy differs per user (that is, the EXPIRE
- argument might change after authentication), the server MUST
- announce in AUTHENTICATION state the smallest value which could
- be set for any user. This might be the smallest value currently
- in use for any user (so only one value per server), or even the
- smallest value which the server permits to be set for any user.
- The server SHOULD append the token "USER" to the EXPIRE parameter
- in AUTHENTICATION state, to inform the client that a more
- accurate value is available after authentication. The server
- SHOULD announce the more accurate value in TRANSACTION state.
- (The "USER" token allows the client to decide if a second CAPA
- command is needed or not.)
-
- A site may have a message expiration policy which treats messages
- differently depending on which user actions have been performed,
- or based on other factors. For example, a site might delete
- unseen messages after 60 days, and completely- or partially-seen
- messages after 15 days.
-
- The announced EXPIRE value is the smallest retention period which
- is or might be used by any category or condition of the current
- site policy, for any user (in AUTHENTICATION state) or the
- specific user (in TRANSACTION state). That is, EXPIRE informs
- the client of the minimum number of days messages may remain on
- the server under any circumstances.
-
- Examples:
- EXPIRE 5 USER
- EXPIRE 30
- EXPIRE NEVER
- EXPIRE 0
-
- The first example indicates the server might delete messages
- after five days, but the period differs per user, and so a more
- accurate value can be obtained by issuing a second CAPA command
- in TRANSACTION state. The second example indicates the server
- could delete messages after 30 days. In the third example, the
- server announces it does not delete messages. The fourth example
- specifies that the site does not permit messages to be left on
- the server.
-
-
-
-Gellens, et. al. Standards Track [Page 12]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-6.8. UIDL capability
-
- CAPA tag:
- UIDL
-
- Arguments:
- none
-
- Added commands:
- UIDL
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both / no
-
- Commands valid in states:
- TRANSACTION
-
- Specification reference:
- [POP3]
-
- Discussion:
- The UIDL capability indicates that the optional UIDL command is
- supported.
-
-6.9. IMPLEMENTATION capability
-
- CAPA tag:
- IMPLEMENTATION
-
- Arguments:
- string giving server implementation information
-
- Added commands:
- none
-
- Standard commands affected:
- none
-
- Announced states / possible differences:
- both (optionally TRANSACTION only) / no
-
- Commands valid in states:
- n/a
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 13]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- Specification reference:
- this document
-
- Discussion:
- It is often useful to identify an implementation of a particular
- server (for example, when logging). This is commonly done in the
- welcome banner, but one must guess if a string is an
- implementation ID or not.
-
- The argument to the IMPLEMENTATION capability consists of one or
- more tokens which identify the server. (Note that since CAPA
- response tag arguments are space-separated, it may be convenient
- for the IMPLEMENTATION capability argument to not contain spaces,
- so that it is a single token.)
-
- Normally, servers announce IMPLEMENTATION in both states.
- However, a server MAY chose to do so only in TRANSACTION state.
-
- A server MAY include the implementation identification both in
- the welcome banner and in the IMPLEMENTATION capability.
-
- Clients MUST NOT modify their behavior based on the server
- implementation. Instead the server and client should agree on a
- private extension.
-
-7. Future Extensions to POP3
-
- Future extensions to POP3 are in general discouraged, as POP3's
- usefulness lies in its simplicity. POP3 is intended as a download-
- and-delete protocol; mail access capabilities are available in IMAP
- [IMAP4]. Extensions which provide support for additional mailboxes,
- allow uploading of messages to the server, or which deviate from
- POP's download-and-delete model are strongly discouraged and unlikely
- to be permitted on the IETF standards track.
-
- Clients MUST NOT require the presence of any extension for basic
- functionality, with the exception of the authentication commands
- (APOP, AUTH [section 6.3] and USER/PASS).
-
- Section 9 specifies how additional capabilities are defined.
-
-8. Extended POP3 Response Codes
-
- Unextended POP3 is only capable of indicating success or failure to
- most commands. Unfortunately, clients often need to know more
- information about the cause of a failure in order to gracefully
- recover. This is especially important in response to a failed login
-
-
-
-
-Gellens, et. al. Standards Track [Page 14]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- (there are widely-deployed clients which attempt to decode the error
- text of a PASS command result, to try and distinguish between "unable
- to get maildrop lock" and "bad login").
-
- This specification amends the POP3 standard to permit an optional
- response code, enclosed in square brackets, at the beginning of the
- human readable text portion of an "+OK" or "-ERR" response. Clients
- supporting this extension MAY remove any information enclosed in
- square brackets prior to displaying human readable text to the user.
- Immediately following the open square bracket "[" character is a
- response code which is interpreted in a case-insensitive fashion by
- the client.
-
- The response code is hierarchical, with a "/" separating levels of
- detail about the error. Clients MUST ignore unknown hierarchical
- detail about the response code. This is important, as it could be
- necessary to provide further detail for response codes in the future.
-
- Section 3 describes response codes using [ABNF].
-
- If a server supports extended response codes, it indicates this by
- including the RESP-CODES capability in the CAPA response.
-
- Examples:
- C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
- S: -ERR [IN-USE] Do you have another POP session running?
-
-8.1. Initial POP3 response codes
-
- This specification defines two POP3 response codes which can be used
- to determine the reason for a failed login. Section 9 specifies how
- additional response codes are defined.
-
-8.1.1. The LOGIN-DELAY response code
-
- This occurs on an -ERR response to an AUTH, USER (see note), PASS or
- APOP command and indicates that the user has logged in recently and
- will not be allowed to login again until the login delay period has
- expired.
-
- NOTE: Returning the LOGIN-DELAY response code to the USER command
- avoids the work of authenticating the user but reveals to the client
- that the specified user exists. Unless the server is operating in an
- environment where user names are not secret (for example, many
- popular email clients advertise the POP server and user name in an
- outgoing mail header), or where server access is restricted, or the
- server can verify that the connection is to the same user, it is
-
-
-
-
-Gellens, et. al. Standards Track [Page 15]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- strongly recommended that the server not issue this response code to
- the USER command. The server still saves the cost of opening the
- maildrop, which in some environments is the most expensive step.
-
-8.1.2. The IN-USE response code
-
- This occurs on an -ERR response to an AUTH, APOP, or PASS command.
- It indicates the authentication was successful, but the user's
- maildrop is currently in use (probably by another POP3 client).
-
-9. IANA Considerations
-
- This document requests that IANA maintain two new registries: POP3
- capabilities and POP3 response codes.
-
- New POP3 capabilities MUST be defined in a standards track or IESG
- approved experimental RFC, and MUST NOT begin with the letter "X".
-
- New POP3 capabilities MUST include the following information:
- CAPA tag
- Arguments
- Added commands
- Standard commands affected
- Announced states / possible differences
- Commands valid in states
- Specification reference
- Discussion
-
- In addition, new limits for POP3 command and response lengths may
- need to be included.
-
- New POP3 response codes MUST be defined in an RFC or other permanent
- and readily available reference, in sufficient detail so that
- interoperability between independent implementations is possible.
- (This is the "Specification Required" policy described in [IANA]).
-
- New POP3 response code specifications MUST include the following
- information: the complete response code, for which responses (+OK
- or -ERR) and commands it is valid, and a definition of its meaning and
- expected client behavior.
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 16]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-10. Security Considerations
-
- A capability list can reveal information about the server's
- authentication mechanisms which can be used to determine if certain
- attacks will be successful. However, allowing clients to
- automatically detect availability of stronger mechanisms and alter
- their configurations to use them can improve overall security at a
- site.
-
- Section 8.1 discusses the security issues related to use of the
- LOGIN-DELAY response code with the USER command.
-
-11. Acknowledgments
-
- This document has been revised in part based on comments and
- discussions which took place on and off the IETF POP3 Extensions
- mailing list. The help of those who took the time to review this
- memo and make suggestions is appreciated, especially that of Alexey
- Melnikov, Harald Alvestrand, and Mike Gahrns.
-
-12. References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [IMAP4] Crispin, M., "Internet Message Access Protocol --
- Version 4rev1", RFC 2060, December 1996.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [PIPELINING] Freed, N., "SMTP Service Extension for Command
- Pipelining", RFC 2197, September 1997.
-
- [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version
- 3", STD 53, RFC 1939, May 1996.
-
- [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
- December 1994.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 17]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
- [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
- 821, August 1982.
-
-13. Authors' Addresses
-
- Randall Gellens
- QUALCOMM Incorporated
- 6455 Lusk Blvd.
- San Diego, CA 92121-2779
- USA
-
- Phone: +1 619 651 5115
- Fax: +1 619 845 7268
- EMail: randy@qualcomm.com
-
-
- Chris Newman
- Innosoft International, Inc.
- 1050 Lakes Drive
- West Covina, CA 91790
- USA
-
- EMail: chris.newman@innosoft.com
-
-
- Laurence Lundblade
- QUALCOMM Incorporated
- 6455 Lusk Blvd.
- San Diego, Ca, 92121-2779
- USA
-
- Phone: +1 619 658 3584
- Fax: +1 619 845 7268
- EMail: lgl@qualcomm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 18]
-
-RFC 2449 POP3 Extension Mechanism November 1998
-
-
-14. Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gellens, et. al. Standards Track [Page 19]
-
diff --git a/RFC/rfc2554.txt b/RFC/rfc2554.txt deleted file mode 100644 index 2922deae..00000000 --- a/RFC/rfc2554.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group J. Myers -Request for Comments: 2554 Netscape Communications -Category: Standards Track March 1999 - - - SMTP Service Extension - for Authentication - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - -1. Introduction - - This document defines an SMTP service extension [ESMTP] whereby an - SMTP client may indicate an authentication mechanism to the server, - perform an authentication protocol exchange, and optionally negotiate - a security layer for subsequent protocol interactions. This - extension is a profile of the Simple Authentication and Security - Layer [SASL]. - - -2. Conventions Used in this Document - - In examples, "C:" and "S:" indicate lines sent by the client and - server respectively. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as defined in "Key words for - use in RFCs to Indicate Requirement Levels" [KEYWORDS]. - - -3. The Authentication service extension - - - (1) the name of the SMTP service extension is "Authentication" - - (2) the EHLO keyword value associated with this extension is "AUTH" - - - - -Myers Standards Track [Page 1] - -RFC 2554 SMTP Authentication March 1999 - - - (3) The AUTH EHLO keyword contains as a parameter a space separated - list of the names of supported SASL mechanisms. - - (4) a new SMTP verb "AUTH" is defined - - (5) an optional parameter using the keyword "AUTH" is added to the - MAIL FROM command, and extends the maximum line length of the - MAIL FROM command by 500 characters. - - (6) this extension is appropriate for the submission protocol - [SUBMIT]. - - -4. The AUTH command - - AUTH mechanism [initial-response] - - Arguments: - a string identifying a SASL authentication mechanism. - an optional base64-encoded response - - Restrictions: - After an AUTH command has successfully completed, no more AUTH - commands may be issued in the same session. After a successful - AUTH command completes, a server MUST reject any further AUTH - commands with a 503 reply. - - The AUTH command is not permitted during a mail transaction. - - Discussion: - The AUTH command indicates an authentication mechanism to the - server. If the server supports the requested authentication - mechanism, it performs an authentication protocol exchange to - authenticate and identify the user. Optionally, it also - negotiates a security layer for subsequent protocol - interactions. If the requested authentication mechanism is not - supported, the server rejects the AUTH command with a 504 - reply. - - The authentication protocol exchange consists of a series of - server challenges and client answers that are specific to the - authentication mechanism. A server challenge, otherwise known - as a ready response, is a 334 reply with the text part - containing a BASE64 encoded string. The client answer consists - of a line containing a BASE64 encoded string. If the client - wishes to cancel an authentication exchange, it issues a line - with a single "*". If the server receives such an answer, it - MUST reject the AUTH command by sending a 501 reply. - - - -Myers Standards Track [Page 2] - -RFC 2554 SMTP Authentication March 1999 - - - The optional initial-response argument to the AUTH command is - used to save a round trip when using authentication mechanisms - that are defined to send no data in the initial challenge. - When the initial-response argument is used with such a - mechanism, the initial empty challenge is not sent to the - client and the server uses the data in the initial-response - argument as if it were sent in response to the empty challenge. - Unlike a zero-length client answer to a 334 reply, a zero- - length initial response is sent as a single equals sign ("="). - If the client uses an initial-response argument to the AUTH - command with a mechanism that sends data in the initial - challenge, the server rejects the AUTH command with a 535 - reply. - - If the server cannot BASE64 decode the argument, it rejects the - AUTH command with a 501 reply. If the server rejects the - authentication data, it SHOULD reject the AUTH command with a - 535 reply unless a more specific error code, such as one listed - in section 6, is appropriate. Should the client successfully - complete the authentication exchange, the SMTP server issues a - 235 reply. - - The service name specified by this protocol's profile of SASL - is "smtp". - - If a security layer is negotiated through the SASL - authentication exchange, it takes effect immediately following - the CRLF that concludes the authentication exchange for the - client, and the CRLF of the success reply for the server. Upon - a security layer's taking effect, the SMTP protocol is reset to - the initial state (the state in SMTP after a server issues a - 220 service ready greeting). The server MUST discard any - knowledge obtained from the client, such as the argument to the - EHLO command, which was not obtained from the SASL negotiation - itself. The client MUST discard any knowledge obtained from - the server, such as the list of SMTP service extensions, which - was not obtained from the SASL negotiation itself (with the - exception that a client MAY compare the list of advertised SASL - mechanisms before and after authentication in order to detect - an active down-negotiation attack). The client SHOULD send an - EHLO command as the first command after a successful SASL - negotiation which results in the enabling of a security layer. - - The server is not required to support any particular - authentication mechanism, nor are authentication mechanisms - required to support any security layers. If an AUTH command - fails, the client may try another authentication mechanism by - issuing another AUTH command. - - - -Myers Standards Track [Page 3] - -RFC 2554 SMTP Authentication March 1999 - - - If an AUTH command fails, the server MUST behave the same as if - the client had not issued the AUTH command. - - The BASE64 string may in general be arbitrarily long. Clients - and servers MUST be able to support challenges and responses - that are as long as are generated by the authentication - mechanisms they support, independent of any line length - limitations the client or server may have in other parts of its - protocol implementation. - - Examples: - S: 220 smtp.example.com ESMTP server ready - C: EHLO jgm.example.com - S: 250-smtp.example.com - S: 250 AUTH CRAM-MD5 DIGEST-MD5 - C: AUTH FOOBAR - S: 504 Unrecognized authentication type. - C: AUTH CRAM-MD5 - S: 334 - PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= - C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== - S: 235 Authentication successful. - - - -5. The AUTH parameter to the MAIL FROM command - - AUTH=addr-spec - - Arguments: - An addr-spec containing the identity which submitted the message - to the delivery system, or the two character sequence "<>" - indicating such an identity is unknown or insufficiently - authenticated. To comply with the restrictions imposed on ESMTP - parameters, the addr-spec is encoded inside an xtext. The syntax - of an xtext is described in section 5 of [ESMTP-DSN]. - - Discussion: - The optional AUTH parameter to the MAIL FROM command allows - cooperating agents in a trusted environment to communicate the - authentication of individual messages. - - If the server trusts the authenticated identity of the client to - assert that the message was originally submitted by the supplied - addr-spec, then the server SHOULD supply the same addr-spec in an - AUTH parameter when relaying the message to any server which - supports the AUTH extension. - - - - -Myers Standards Track [Page 4] - -RFC 2554 SMTP Authentication March 1999 - - - A MAIL FROM parameter of AUTH=<> indicates that the original - submitter of the message is not known. The server MUST NOT treat - the message as having been originally submitted by the client. - - If the AUTH parameter to the MAIL FROM is not supplied, the - client has authenticated, and the server believes the message is - an original submission by the client, the server MAY supply the - client's identity in the addr-spec in an AUTH parameter when - relaying the message to any server which supports the AUTH - extension. - - If the server does not sufficiently trust the authenticated - identity of the client, or if the client is not authenticated, - then the server MUST behave as if the AUTH=<> parameter was - supplied. The server MAY, however, write the value of the AUTH - parameter to a log file. - - If an AUTH=<> parameter was supplied, either explicitly or due to - the requirement in the previous paragraph, then the server MUST - supply the AUTH=<> parameter when relaying the message to any - server which it has authenticated to using the AUTH extension. - - A server MAY treat expansion of a mailing list as a new - submission, setting the AUTH parameter to the mailing list - address or mailing list administration address when relaying the - message to list subscribers. - - It is conforming for an implementation to be hard-coded to treat - all clients as being insufficiently trusted. In that case, the - implementation does nothing more than parse and discard - syntactically valid AUTH parameters to the MAIL FROM command and - supply AUTH=<> parameters to any servers to which it - authenticates using the AUTH extension. - - Examples: - C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com - S: 250 OK - - - - - - - - - - - - - - -Myers Standards Track [Page 5] - -RFC 2554 SMTP Authentication March 1999 - - -6. Error Codes - - The following error codes may be used to indicate various conditions - as described. - - 432 A password transition is needed - - This response to the AUTH command indicates that the user needs to - transition to the selected authentication mechanism. This typically - done by authenticating once using the PLAIN authentication mechanism. - - 534 Authentication mechanism is too weak - - This response to the AUTH command indicates that the selected - authentication mechanism is weaker than server policy permits for - that user. - - 538 Encryption required for requested authentication mechanism - - This response to the AUTH command indicates that the selected - authentication mechanism may only be used when the underlying SMTP - connection is encrypted. - - 454 Temporary authentication failure - - This response to the AUTH command indicates that the authentication - failed due to a temporary server failure. - - 530 Authentication required - - This response may be returned by any command other than AUTH, EHLO, - HELO, NOOP, RSET, or QUIT. It indicates that server policy requires - authentication in order to perform the requested action. - - - - - - - - - - - - - - - - - - -Myers Standards Track [Page 6] - -RFC 2554 SMTP Authentication March 1999 - - -7. Formal Syntax - - The following syntax specification uses the augmented Backus-Naur - Form (BNF) notation as specified in [ABNF]. - - Except as noted otherwise, all alphabetic characters are case- - insensitive. The use of upper or lower case characters to define - token strings is for editorial clarity only. Implementations MUST - accept these strings in a case-insensitive fashion. - - UPALPHA = %x41-5A ;; Uppercase: A-Z - - LOALPHA = %x61-7A ;; Lowercase: a-z - - ALPHA = UPALPHA / LOALPHA ;; case insensitive - - DIGIT = %x30-39 ;; Digits 0-9 - - HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase) - - hexchar = "+" HEXDIGIT HEXDIGIT - - xchar = %x21-2A / %x2C-3C / %x3E-7E - ;; US-ASCII except for "+", "=", SPACE and CTL - - xtext = *(xchar / hexchar) - - AUTH_CHAR = ALPHA / DIGIT / "-" / "_" - - auth_type = 1*20AUTH_CHAR - - auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] - *(CRLF [base64]) CRLF - - auth_param = "AUTH=" xtext - ;; The decoded form of the xtext MUST be either - ;; an addr-spec or the two characters "<>" - - base64 = base64_terminal / - ( 1*(4base64_CHAR) [base64_terminal] ) - - base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" - ;; Case-sensitive - - base64_terminal = (2base64_char "==") / (3base64_char "=") - - continue_req = "334" SPACE [base64] CRLF - - - - -Myers Standards Track [Page 7] - -RFC 2554 SMTP Authentication March 1999 - - - CR = %x0C ;; ASCII CR, carriage return - - CRLF = CR LF - - CTL = %x00-1F / %x7F ;; any ASCII control character and DEL - - LF = %x0A ;; ASCII LF, line feed - - SPACE = %x20 ;; ASCII SP, space - - - - -8. References - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP - AUTHorize Extension for Simple Challenge/Response", RFC - 2195, September 1997. - - [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. - Crocker, "SMTP Service Extensions", RFC 1869, November - 1995. - - [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status - Notifications", RFC 1891, January 1996. - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [SASL] Myers, J., "Simple Authentication and Security Layer - (SASL)", RFC 2222, October 1997. - - [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC - 2476, December 1998. - - [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC - 821, August 1982. - - [RFC822] Crocker, D., "Standard for the Format of ARPA Internet - Text Messages", STD 11, RFC 822, August 1982. - - - - - - - - -Myers Standards Track [Page 8] - -RFC 2554 SMTP Authentication March 1999 - - -9. Security Considerations - - Security issues are discussed throughout this memo. - - If a client uses this extension to get an encrypted tunnel through an - insecure network to a cooperating server, it needs to be configured - to never send mail to that server when the connection is not mutually - authenticated and encrypted. Otherwise, an attacker could steal the - client's mail by hijacking the SMTP connection and either pretending - the server does not support the Authentication extension or causing - all AUTH commands to fail. - - Before the SASL negotiation has begun, any protocol interactions are - performed in the clear and may be modified by an active attacker. - For this reason, clients and servers MUST discard any knowledge - obtained prior to the start of the SASL negotiation upon completion - of a SASL negotiation which results in a security layer. - - This mechanism does not protect the TCP port, so an active attacker - may redirect a relay connection attempt to the submission port - [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing - an relayed message without an envelope authentication to pick up the - authentication of the relay client. - - A message submission client may require the user to authenticate - whenever a suitable SASL mechanism is advertised. Therefore, it may - not be desirable for a submission server [SUBMIT] to advertise a SASL - mechanism when use of that mechanism grants the client no benefits - over anonymous submission. - - This extension is not intended to replace or be used instead of end- - to-end message signature and encryption systems such as S/MIME or - PGP. This extension addresses a different problem than end-to-end - systems; it has the following key differences: - - (1) it is generally useful only within a trusted enclave - - (2) it protects the entire envelope of a message, not just the - message's body. - - (3) it authenticates the message submission, not authorship of the - message content - - (4) it can give the sender some assurance the message was - delivered to the next hop in the case where the sender - mutually authenticates with the next hop and negotiates an - appropriate security layer. - - - - -Myers Standards Track [Page 9] - -RFC 2554 SMTP Authentication March 1999 - - - Additional security considerations are mentioned in the SASL - specification [SASL]. - - - -10. Author's Address - - John Gardiner Myers - Netscape Communications - 501 East Middlefield Road - Mail Stop MV-029 - Mountain View, CA 94043 - - EMail: jgmyers@netscape.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers Standards Track [Page 10] - -RFC 2554 SMTP Authentication March 1999 - - -11. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Myers Standards Track [Page 11] - diff --git a/RFC/rfc2645.txt b/RFC/rfc2645.txt deleted file mode 100644 index cb99fc84..00000000 --- a/RFC/rfc2645.txt +++ /dev/null @@ -1,507 +0,0 @@ - - - - - - -Network Working Group R. Gellens -Request for Comments: 2645 Qualcomm -Category: Standards Track August 1999 - - - ON-DEMAND MAIL RELAY (ODMR) - SMTP with Dynamic IP Addresses - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -Table of Contents - - 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 - 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 5. States . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 5.1. Initial State . . . . . . . . . . . . . . . . . . . . . . 4 - 5.1.1. EHLO . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5.1.2. AUTH . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5.1.3. QUIT . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5.2. Authenticated State . . . . . . . . . . . . . . . . . . . 4 - 5.2.1. ATRN (Authenticated TURN) . . . . . . . . . . . . . 4 - 5.3. Reversed State . . . . . . . . . . . . . . . . . . . . . 5 - 5.4. Other Commands . . . . . . . . . . . . . . . . . . . . . 6 - 6. Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6 - 7. Response Codes . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 7 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 11. Author's Address . . . . . . . . . . . . . . . . . . . . . 8 - 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 9 - -1. Abstract - - With the spread of low-cost computer systems and Internet - connectivity, the demand for local mail servers has been rising. - Many people now want to operate a mail server on a system which has - - - -Gellens Standards Track [Page 1] - -RFC 2645 On-Demand Mail Relay August 1999 - - - only an intermittent connection to a service provider. If the system - has a static IP address, the ESMTP ETRN command [ETRN] can be used. - However, systems with dynamic IP addresses (which are very common - with low-cost connections) have no widely-deployed solution. - - This memo proposes a new service, On-Demand Mail Relay (ODMR), which - is a profile of SMTP [SMTP, ESMTP], providing for a secure, - extensible, easy to implement approach to the problem. - -2. Conventions Used in this Document - - Because the client and server roles reverse during the session, to - avoid confusion, the terms "customer" and "provider" will be used in - place of "client" and "server", although of course this protocol may - be useful in cases other than commercial service providers and - customers. - - In examples, "P:" is used to indicate lines sent by the provider, and - "C:" indicates those sent by the customer. Line breaks within a - command are for editorial purposes only. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" - in this document are to be interpreted as defined in [KEYWORDS]. - - Examples use 'example.net' as the provider, and 'example.org' and ' - example.com' as the customers. - -3. Comments - - Private comments should be sent to the author. Public comments may - be sent to the IETF Disconnected SMTP mailing list, - <ietf-disconn-smtp@imc.org>. To subscribe, send a message to - <ietf-disconn-smtp-request@imc.org> containing the word SUBSCRIBE as - the body. - -4. Description - - On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP]. - Port 366 is reserved for On-Demand Mail Relay. The initial client - and server roles are short-lived, as the point is to allow the - intermittently-connected host to request mail held for it by a - service provider. - - The customer initiates a connection to the provider, authenticates, - and requests its mail. The roles of client and server then reverse, - and normal SMTP [SMTP, ESMTP] proceeds. - - - - - -Gellens Standards Track [Page 2] - -RFC 2645 On-Demand Mail Relay August 1999 - - - The provider has an On-Demand Mail Relay process listening for - connections on the ODMR port. This process does not need to be a - full SMTP server. It does need to be an SMTP client with access to - the outgoing mail queues, and as a server implement the EHLO, AUTH, - ATRN, and QUIT commands. - - An MTA normally has a mail client component which processes the - outgoing mail queues, attempting to send mail for particular domains, - based on time or event (such as new mail being placed in the queue, - or receipt of an ETRN command by the SMTP server component). The - On-Demand Mail Relay service processes the outgoing queue not on a - timer or new mail creation, but on request. - - The provider side has normal SMTP server responsibilities [SMTP], - including generation of delivery failure notices, etc. as needed. - -5. States - - The On-Demand Mail Relay service has three states: an initial state, - an authenticated state, and a reversed state. The state progression - is illustrated in the following diagram: - - --------------------------- - ! initial state ! - --------------------------- - ! ! - QUIT AUTH - ! ! - ! V - ! ----------------------- - ! ! authenticated state ! - ! ----------------------- - ! ! ! - ! QUIT ATRN - ! ! ! - ! ! V - ! ! ------------------ - ! ! ! reversed state ! - ! ! ------------------ - ! ! ! - ! ! QUIT - ! ! ! - V V V - --------------------- - ! termination ! - --------------------- - - - - - -Gellens Standards Track [Page 3] - -RFC 2645 On-Demand Mail Relay August 1999 - - - (Note that in the reversed state, commands are sent by the provider, - not the customer.) - -5.1. Initial State - - In the initial state, the provider is the server and the customer is - the client. Three commands are valid: EHLO, AUTH, and QUIT. - -5.1.1. EHLO - - The EHLO command is the same as in [ESMTP]. The response MUST - include AUTH and ATRN. - -5.1.2. AUTH - - The AUTH command is specified in [AUTH]. The AUTH command uses a - [SASL] mechanism to authenticate the session. The session is not - considered authenticated until a success response to AUTH has been - sent. - - For interoperability, implementations MUST support the CRAM-MD5 - mechanism [CRAM]. Other SASL mechanisms may be supported. A site - MAY disable CRAM-MD5 support if it uses more secure methods. The - EXTERNAL mechanism [SASL] might be useful in some cases, for example, - if the provider has already authenticated the client, such as during - a PPP connection. - -5.1.3. QUIT - - The QUIT command is the same as in [SMTP]. - -5.2. Authenticated State - - The authenticated state is entered after a successful AUTH command. - Two commands are valid in the authenticated state: ATRN and QUIT. - -5.2.1. ATRN (Authenticated TURN) - - Unlike the TURN command in [SMTP], the ATRN command optionally takes - one or more domains as a parameter. The ATRN command MUST be - rejected if the session has not been authenticated. Response code - 530 [AUTH] is used for this. - - The timeout for this command MUST be at least 10 minutes to allow the - provider time to process its mail queue. - - An ATRN command sent with no domains is equivalent to an ATRN command - specifying all domains to which the customer has access. - - - -Gellens Standards Track [Page 4] - -RFC 2645 On-Demand Mail Relay August 1999 - - - If the authentication used by the customer does not provide access to - all of the domains specified in ATRN, the provider MUST NOT send mail - for any domains to the customer; the provider MUST reject the ATRN - command with a 450 code. - - If the customer does have access to all of the specified domains, but - none of them have any queued mail, the provider normally rejects the - ATRN command with response code 453. The provider MAY instead issue - a 250 success code, and after the roles are reversed, send a QUIT - following the EHLO. - - The provider MAY also reject the ATRN command with a 450 response to - indicate refusal to accept multiple requests issued within a - particular time interval. - - If the customer has access to all of the specified domains and mail - exists in at least one of them, the provider issues a 250 success - code. - - If the server is unable to verify access to the requested domains - (for example, a mapping database is temporarily unavailable), - response code 451 is sent. - - [ABNF] for ATRN: - - atrn = "ATRN" [SP domain *("," domain)] - - domain = sub-domain 1*("." sub-domain) - - sub-domain = (ALPHA / DIGIT) *(ldh-str) - - ldh-str = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) - -5.3. Reversed State - - After the provider has sent a success reply to the ATRN command, the - roles reverse, and the customer becomes the server, and the provider - becomes the client. - - After receiving the success response to ATRN, the customer sends a - standard SMTP initial greeting line. At this point normal SMTP - [SMTP, ESMTP] commands are used. Typically the provider sends EHLO - after seeing the customer's greeting, to be followed by MAIL FROM and - so on. - - - - - - - -Gellens Standards Track [Page 5] - -RFC 2645 On-Demand Mail Relay August 1999 - - -5.4. Other Commands - - The provider MAY reject all commands other than EHLO, AUTH, ATRN, and - QUIT with response code 502. - -6. Example On-Demand Mail Relay Session - - P: 220 EXAMPLE.NET on-demand mail relay server ready - C: EHLO example.org - P: 250-EXAMPLE.NET - P: 250-AUTH CRAM-MD5 EXTERNAL - P: 250 ATRN - C: AUTH CRAM-MD5 - P: 334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo= - C: Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo= - P: 235 now authenticated as example.org - C: ATRN example.org,example.com - P: 250 OK now reversing the connection - C: 220 example.org ready to receive email - P: EHLO EXAMPLE.NET - C: 250-example.org - C: 250 SIZE - P: MAIL FROM: <Lester.Tester@dot.foo.bar> - C: 250 OK - P: RCPT TO: <l.eva.msg@example.com> - C: 250 OK, recipient accepted - ... - P: QUIT - C: 221 example.org closing connection - -7. Response Codes - - The response codes used in this document are: - - 250 Requested mail action okay, completed - 450 ATRN request refused - 451 Unable to process ATRN request now - 453 You have no mail - 502 Command not implemented - 530 Authentication required [AUTH] - -8. Security Considerations - - Because access to the On-Demand Mail Relay server is only useful with - a prior arrangement between the parties (so the provider is the - target of MX records for the customer's domains and thus has mail to - relay), it may be useful for the provider to restrict access to the - On-Demand Mail Relay port. For example, the ODMR server could be - - - -Gellens Standards Track [Page 6] - -RFC 2645 On-Demand Mail Relay August 1999 - - - configurable, or a TCP wrapper or firewall could be used, to block - access to port 366 except within the provider's network. This might - be useful when the provider is the customer's ISP. Use of such - mechanisms does not reduce the need for the AUTH command, however, - but can increase the security it provides. - - Use of SASL in the AUTH command allows for substitution of more - secure authentication mechanisms in the future. - - See sections 5.1.2 and 5.2.1 for additional security details. - -9. Acknowledgments - - This memo has been developed in part based on comments and - discussions which took place on and off the IETF-disconn-smtp mailing - list. Special thanks to Chris Newman and Ned Freed for their - comments. - -10. References - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [AUTH] Myers, J., "SMTP Service Extension for Authentication", - RFC 2554, March 1999. - - [CRAM] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP - AUTHorize Extension for Simple Challenge/Response", RFC - 2195, September 1997. - - [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. - Crocker, "SMTP Service Extensions", RFC 1869, November - 1995. - - [ETRN] De Winter, J., "SMTP Service Extension for Remote Message - Queue Starting", RFC 1985, August 1996. - - [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [SASL] Myers, J., "Simple Authentication and Security Layer - (SASL)", RFC 2222, October 1997. - - [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC - 821, August 1982. - - - - - - -Gellens Standards Track [Page 7] - -RFC 2645 On-Demand Mail Relay August 1999 - - -11. Author's Address - - Randall Gellens - QUALCOMM Incorporated - 5775 Morehouse Dr. - San Diego, CA 92121-2779 - U.S.A. - - Phone: +1.619.651.5115 - EMail: randy@qualcomm.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gellens Standards Track [Page 8] - -RFC 2645 On-Demand Mail Relay August 1999 - - -12. Full Copyright Statement - - Copyright (C) The Internet Society (1999). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Gellens Standards Track [Page 9] - diff --git a/RFC/rfc2683.txt b/RFC/rfc2683.txt deleted file mode 100644 index 651447b3..00000000 --- a/RFC/rfc2683.txt +++ /dev/null @@ -1,1291 +0,0 @@ -
-
-
-
-
-
-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 deleted file mode 100644 index d877b72c..00000000 --- a/RFC/rfc821.txt +++ /dev/null @@ -1,4050 +0,0 @@ - - - - RFC 821 - - - - - - SIMPLE MAIL TRANSFER PROTOCOL - - - - Jonathan B. Postel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 1982 - - - - Information Sciences Institute - University of Southern California - 4676 Admiralty Way - Marina del Rey, California 90291 - - (213) 822-1511 - - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - TABLE OF CONTENTS - - 1. INTRODUCTION .................................................. 1 - - 2. THE SMTP MODEL ................................................ 2 - - 3. THE SMTP PROCEDURE ............................................ 4 - - 3.1. Mail ..................................................... 4 - 3.2. Forwarding ............................................... 7 - 3.3. Verifying and Expanding .................................. 8 - 3.4. Sending and Mailing ..................................... 11 - 3.5. Opening and Closing ..................................... 13 - 3.6. Relaying ................................................ 14 - 3.7. Domains ................................................. 17 - 3.8. Changing Roles .......................................... 18 - - 4. THE SMTP SPECIFICATIONS ...................................... 19 - - 4.1. SMTP Commands ........................................... 19 - 4.1.1. Command Semantics ..................................... 19 - 4.1.2. Command Syntax ........................................ 27 - 4.2. SMTP Replies ............................................ 34 - 4.2.1. Reply Codes by Function Group ......................... 35 - 4.2.2. Reply Codes in Numeric Order .......................... 36 - 4.3. Sequencing of Commands and Replies ...................... 37 - 4.4. State Diagrams .......................................... 39 - 4.5. Details ................................................. 41 - 4.5.1. Minimum Implementation ................................ 41 - 4.5.2. Transparency .......................................... 41 - 4.5.3. Sizes ................................................. 42 - - APPENDIX A: TCP ................................................. 44 - APPENDIX B: NCP ................................................. 45 - APPENDIX C: NITS ................................................ 46 - APPENDIX D: X.25 ................................................ 47 - APPENDIX E: Theory of Reply Codes ............................... 48 - APPENDIX F: Scenarios ........................................... 51 - - GLOSSARY ......................................................... 64 - - REFERENCES ....................................................... 67 - - - - -Network Working Group J. Postel -Request for Comments: DRAFT ISI -Replaces: RFC 788, 780, 772 August 1982 - - SIMPLE MAIL TRANSFER PROTOCOL - - -1. INTRODUCTION - - The objective of Simple Mail Transfer Protocol (SMTP) is to transfer - mail reliably and efficiently. - - SMTP is independent of the particular transmission subsystem and - requires only a reliable ordered data stream channel. Appendices A, - B, C, and D describe the use of SMTP with various transport services. - A Glossary provides the definitions of terms as used in this - document. - - An important feature of SMTP is its capability to relay mail across - transport service environments. A transport service provides an - interprocess communication environment (IPCE). An IPCE may cover one - network, several networks, or a subset of a network. It is important - to realize that transport systems (or IPCEs) are not one-to-one with - networks. A process can communicate directly with another process - through any mutually known IPCE. Mail is an application or use of - interprocess communication. Mail can be communicated between - processes in different IPCEs by relaying through a process connected - to two (or more) IPCEs. More specifically, mail can be relayed - between hosts on different transport systems by a host on both - transport systems. - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 1] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -2. THE SMTP MODEL - - The SMTP design is based on the following model of communication: as - the result of a user mail request, the sender-SMTP establishes a - two-way transmission channel to a receiver-SMTP. The receiver-SMTP - may be either the ultimate destination or an intermediate. SMTP - commands are generated by the sender-SMTP and sent to the - receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the - sender-SMTP in response to the commands. - - Once the transmission channel is established, the SMTP-sender sends a - MAIL command indicating the sender of the mail. If the SMTP-receiver - can accept mail it responds with an OK reply. The SMTP-sender then - sends a RCPT command identifying a recipient of the mail. If the - SMTP-receiver can accept mail for that recipient it responds with an - OK reply; if not, it responds with a reply rejecting that recipient - (but not the whole mail transaction). The SMTP-sender and - SMTP-receiver may negotiate several recipients. When the recipients - have been negotiated the SMTP-sender sends the mail data, terminating - with a special sequence. If the SMTP-receiver successfully processes - the mail data it responds with an OK reply. The dialog is purposely - lock-step, one-at-a-time. - - ------------------------------------------------------------- - - - +----------+ +----------+ - +------+ | | | | - | User |<-->| | SMTP | | - +------+ | Sender- |Commands/Replies| Receiver-| - +------+ | SMTP |<-------------->| SMTP | +------+ - | File |<-->| | and Mail | |<-->| File | - |System| | | | | |System| - +------+ +----------+ +----------+ +------+ - - - Sender-SMTP Receiver-SMTP - - Model for SMTP Use - - Figure 1 - - ------------------------------------------------------------- - - The SMTP provides mechanisms for the transmission of mail; directly - from the sending user's host to the receiving user's host when the - - - -[Page 2] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - two host are connected to the same transport service, or via one or - more relay SMTP-servers when the source and destination hosts are not - connected to the same transport service. - - To be able to provide the relay capability the SMTP-server must be - supplied with the name of the ultimate destination host as well as - the destination mailbox name. - - The argument to the MAIL command is a reverse-path, which specifies - who the mail is from. The argument to the RCPT command is a - forward-path, which specifies who the mail is to. The forward-path - is a source route, while the reverse-path is a return route (which - may be used to return a message to the sender when an error occurs - with a relayed message). - - When the same message is sent to multiple recipients the SMTP - encourages the transmission of only one copy of the data for all the - recipients at the same destination host. - - The mail commands and replies have a rigid syntax. Replies also have - a numeric code. In the following, examples appear which use actual - commands and replies. The complete lists of commands and replies - appears in Section 4 on specifications. - - Commands and replies are not case sensitive. That is, a command or - reply word may be upper case, lower case, or any mixture of upper and - lower case. Note that this is not true of mailbox user names. For - some hosts the user name is case sensitive, and SMTP implementations - must take case to preserve the case of user names as they appear in - mailbox arguments. Host names are not case sensitive. - - Commands and replies are composed of characters from the ASCII - character set [1]. When the transport service provides an 8-bit byte - (octet) transmission channel, each 7-bit character is transmitted - right justified in an octet with the high order bit cleared to zero. - - When specifying the general form of a command or reply, an argument - (or special symbol) will be denoted by a meta-linguistic variable (or - constant), for example, "<string>" or "<reverse-path>". Here the - angle brackets indicate these are meta-linguistic variables. - However, some arguments use the angle brackets literally. For - example, an actual reverse-path is enclosed in angle brackets, i.e., - "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the - angle brackets are actually transmitted in the command or reply). - - - - - -Postel [Page 3] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -3. THE SMTP PROCEDURES - - This section presents the procedures used in SMTP in several parts. - First comes the basic mail procedure defined as a mail transaction. - Following this are descriptions of forwarding mail, verifying mailbox - names and expanding mailing lists, sending to terminals instead of or - in combination with mailboxes, and the opening and closing exchanges. - At the end of this section are comments on relaying, a note on mail - domains, and a discussion of changing roles. Throughout this section - are examples of partial command and reply sequences, several complete - scenarios are presented in Appendix F. - - 3.1. MAIL - - There are three steps to SMTP mail transactions. The transaction - is started with a MAIL command which gives the sender - identification. A series of one or more RCPT commands follows - giving the receiver information. Then a DATA command gives the - mail data. And finally, the end of mail data indicator confirms - the transaction. - - The first step in the procedure is the MAIL command. The - <reverse-path> contains the source mailbox. - - MAIL <SP> FROM:<reverse-path> <CRLF> - - This command tells the SMTP-receiver that a new mail - transaction is starting and to reset all its state tables and - buffers, including any recipients or mail data. It gives the - reverse-path which can be used to report errors. If accepted, - the receiver-SMTP returns a 250 OK reply. - - The <reverse-path> can contain more than just a mailbox. The - <reverse-path> is a reverse source routing list of hosts and - source mailbox. The first host in the <reverse-path> should be - the host sending this command. - - The second step in the procedure is the RCPT command. - - RCPT <SP> TO:<forward-path> <CRLF> - - This command gives a forward-path identifying one recipient. - If accepted, the receiver-SMTP returns a 250 OK reply, and - stores the forward-path. If the recipient is unknown the - receiver-SMTP returns a 550 Failure reply. This second step of - the procedure can be repeated any number of times. - - - -[Page 4] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - The <forward-path> can contain more than just a mailbox. The - <forward-path> is a source routing list of hosts and the - destination mailbox. The first host in the <forward-path> - should be the host receiving this command. - - The third step in the procedure is the DATA command. - - DATA <CRLF> - - If accepted, the receiver-SMTP returns a 354 Intermediate reply - and considers all succeeding lines to be the message text. - When the end of text is received and stored the SMTP-receiver - sends a 250 OK reply. - - Since the mail data is sent on the transmission channel the end - of the mail data must be indicated so that the command and - reply dialog can be resumed. SMTP indicates the end of the - mail data by sending a line containing only a period. A - transparency procedure is used to prevent this from interfering - with the user's text (see Section 4.5.2). - - Please note that the mail data includes the memo header - items such as Date, Subject, To, Cc, From [2]. - - The end of mail data indicator also confirms the mail - transaction and tells the receiver-SMTP to now process the - stored recipients and mail data. If accepted, the - receiver-SMTP returns a 250 OK reply. The DATA command should - fail only if the mail transaction was incomplete (for example, - no recipients), or if resources are not available. - - The above procedure is an example of a mail transaction. These - commands must be used only in the order discussed above. - Example 1 (below) illustrates the use of these commands in a mail - transaction. - - - - - - - - - - - - - - -Postel [Page 5] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example of the SMTP Procedure - - This SMTP example shows mail sent by Smith at host Alpha.ARPA, - to Jones, Green, and Brown at host Beta.ARPA. Here we assume - that host Alpha contacts host Beta directly. - - S: MAIL FROM:<Smith@Alpha.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@Beta.ARPA> - R: 250 OK - - S: RCPT TO:<Green@Beta.ARPA> - R: 550 No such user here - - S: RCPT TO:<Brown@Beta.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: <CRLF>.<CRLF> - R: 250 OK - - The mail has now been accepted for Jones and Brown. Green did - not have a mailbox at host Beta. - - Example 1 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - -[Page 6] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.2. FORWARDING - - There are some cases where the destination information in the - <forward-path> is incorrect, but the receiver-SMTP knows the - correct destination. In such cases, one of the following replies - should be used to allow the sender to contact the correct - destination. - - 251 User not local; will forward to <forward-path> - - This reply indicates that the receiver-SMTP knows the user's - mailbox is on another host and indicates the correct - forward-path to use in the future. Note that either the - host or user or both may be different. The receiver takes - responsibility for delivering the message. - - 551 User not local; please try <forward-path> - - This reply indicates that the receiver-SMTP knows the user's - mailbox is on another host and indicates the correct - forward-path to use. Note that either the host or user or - both may be different. The receiver refuses to accept mail - for this user, and the sender must either redirect the mail - according to the information provided or return an error - response to the originating user. - - Example 2 illustrates the use of these responses. - - ------------------------------------------------------------- - - Example of Forwarding - - Either - - S: RCPT TO:<Postel@USC-ISI.ARPA> - R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA> - - Or - - S: RCPT TO:<Paul@USC-ISIB.ARPA> - R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA> - - Example 2 - - ------------------------------------------------------------- - - - - -Postel [Page 7] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 3.3. VERIFYING AND EXPANDING - - SMTP provides as additional features, commands to verify a user - name or expand a mailing list. This is done with the VRFY and - EXPN commands, which have character string arguments. For the - VRFY command, the string is a user name, and the response may - include the full name of the user and must include the mailbox of - the user. For the EXPN command, the string identifies a mailing - list, and the multiline response may include the full name of the - users and must give the mailboxes on the mailing list. - - "User name" is a fuzzy term and used purposely. If a host - implements the VRFY or EXPN commands then at least local mailboxes - must be recognized as "user names". If a host chooses to - recognize other strings as "user names" that is allowed. - - In some hosts the distinction between a mailing list and an alias - for a single mailbox is a bit fuzzy, since a common data structure - may hold both types of entries, and it is possible to have mailing - lists of one mailbox. If a request is made to verify a mailing - list a positive response can be given if on receipt of a message - so addressed it will be delivered to everyone on the list, - otherwise an error should be reported (e.g., "550 That is a - mailing list, not a user"). If a request is made to expand a user - name a positive response can be formed by returning a list - containing one name, or an error can be reported (e.g., "550 That - is a user name, not a mailing list"). - - In the case of a multiline reply (normal for EXPN) exactly one - mailbox is to be specified on each line of the reply. In the case - of an ambiguous request, for example, "VRFY Smith", where there - are two Smith's the response must be "553 User ambiguous". - - The case of verifying a user name is straightforward as shown in - example 3. - - - - - - - - - - - - - - -[Page 8] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example of Verifying a User Name - - Either - - S: VRFY Smith - R: 250 Fred Smith <Smith@USC-ISIF.ARPA> - - Or - - S: VRFY Smith - R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA> - - Or - - S: VRFY Jones - R: 550 String does not match anything. - - Or - - S: VRFY Jones - R: 551 User not local; please try <Jones@USC-ISIQ.ARPA> - - Or - - S: VRFY Gourzenkyinplatz - R: 553 User ambiguous. - - Example 3 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - -Postel [Page 9] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The case of expanding a mailbox list requires a multiline reply as - shown in example 4. - - ------------------------------------------------------------- - - Example of Expanding a Mailing List - - Either - - S: EXPN Example-People - R: 250-Jon Postel <Postel@USC-ISIF.ARPA> - R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> - R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<joe@foo-unix.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - Or - - S: EXPN Executive-Washroom-List - R: 550 Access Denied to You. - - Example 4 - - ------------------------------------------------------------- - - The character string arguments of the VRFY and EXPN commands - cannot be further restricted due to the variety of implementations - of the user name and mailbox list concepts. On some systems it - may be appropriate for the argument of the EXPN command to be a - file name for a file containing a mailing list, but again there is - a variety of file naming conventions in the Internet. - - The VRFY and EXPN commands are not included in the minimum - implementation (Section 4.5.1), and are not required to work - across relays when they are implemented. - - - - - - - - - - - - - -[Page 10] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.4. SENDING AND MAILING - - The main purpose of SMTP is to deliver messages to user's - mailboxes. A very similar service provided by some hosts is to - deliver messages to user's terminals (provided the user is active - on the host). The delivery to the user's mailbox is called - "mailing", the delivery to the user's terminal is called - "sending". Because in many hosts the implementation of sending is - nearly identical to the implementation of mailing these two - functions are combined in SMTP. However the sending commands are - not included in the required minimum implementation - (Section 4.5.1). Users should have the ability to control the - writing of messages on their terminals. Most hosts permit the - users to accept or refuse such messages. - - The following three command are defined to support the sending - options. These are used in the mail transaction instead of the - MAIL command and inform the receiver-SMTP of the special semantics - of this transaction: - - SEND <SP> FROM:<reverse-path> <CRLF> - - The SEND command requires that the mail data be delivered to - the user's terminal. If the user is not active (or not - accepting terminal messages) on the host a 450 reply may - returned to a RCPT command. The mail transaction is - successful if the message is delivered the terminal. - - SOML <SP> FROM:<reverse-path> <CRLF> - - The Send Or MaiL command requires that the mail data be - delivered to the user's terminal if the user is active (and - accepting terminal messages) on the host. If the user is - not active (or not accepting terminal messages) then the - mail data is entered into the user's mailbox. The mail - transaction is successful if the message is delivered either - to the terminal or the mailbox. - - SAML <SP> FROM:<reverse-path> <CRLF> - - The Send And MaiL command requires that the mail data be - delivered to the user's terminal if the user is active (and - accepting terminal messages) on the host. In any case the - mail data is entered into the user's mailbox. The mail - transaction is successful if the message is delivered the - mailbox. - - - -Postel [Page 11] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The same reply codes that are used for the MAIL commands are used - for these commands. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 12] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.5. OPENING AND CLOSING - - At the time the transmission channel is opened there is an - exchange to ensure that the hosts are communicating with the hosts - they think they are. - - The following two commands are used in transmission channel - opening and closing: - - HELO <SP> <domain> <CRLF> - - QUIT <CRLF> - - In the HELO command the host sending the command identifies - itself; the command may be interpreted as saying "Hello, I am - <domain>". - - ------------------------------------------------------------- - - Example of Connection Opening - - R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BBN-UNIX.ARPA - - Example 5 - - ------------------------------------------------------------- - - ------------------------------------------------------------- - - Example of Connection Closing - - S: QUIT - R: 221 BBN-UNIX.ARPA Service closing transmission channel - - Example 6 - - ------------------------------------------------------------- - - - - - - - - - - -Postel [Page 13] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 3.6. RELAYING - - The forward-path may be a source route of the form - "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This - form is used to emphasize the distinction between an address and a - route. The mailbox is an absolute address, and the route is - information about how to get there. The two concepts should not - be confused. - - Conceptually the elements of the forward-path are moved to the - reverse-path as the message is relayed from one server-SMTP to - another. The reverse-path is a reverse source route, (i.e., a - source route from the current location of the message to the - originator of the message). When a server-SMTP deletes its - identifier from the forward-path and inserts it into the - reverse-path, it must use the name it is known by in the - environment it is sending into, not the environment the mail came - from, in case the server-SMTP is known by different names in - different environments. - - If when the message arrives at an SMTP the first element of the - forward-path is not the identifier of that SMTP the element is not - deleted from the forward-path and is used to determine the next - SMTP to send the message to. In any case, the SMTP adds its own - identifier to the reverse-path. - - Using source routing the receiver-SMTP receives mail to be relayed - to another server-SMTP The receiver-SMTP may accept or reject the - task of relaying the mail in the same way it accepts or rejects - mail for a local user. The receiver-SMTP transforms the command - arguments by moving its own identifier from the forward-path to - the beginning of the reverse-path. The receiver-SMTP then becomes - a sender-SMTP, establishes a transmission channel to the next SMTP - in the forward-path, and sends it the mail. - - The first host in the reverse-path should be the host sending the - SMTP commands, and the first host in the forward-path should be - the host receiving the SMTP commands. - - Notice that the forward-path and reverse-path appear in the SMTP - commands and replies, but not necessarily in the message. That - is, there is no need for these paths and especially this syntax to - appear in the "To:" , "From:", "CC:", etc. fields of the message - header. - - If a server-SMTP has accepted the task of relaying the mail and - - - -[Page 14] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - later finds that the forward-path is incorrect or that the mail - cannot be delivered for whatever reason, then it must construct an - "undeliverable mail" notification message and send it to the - originator of the undeliverable mail (as indicated by the - reverse-path). - - This notification message must be from the server-SMTP at this - host. Of course, server-SMTPs should not send notification - messages about problems with notification messages. One way to - prevent loops in error reporting is to specify a null reverse-path - in the MAIL command of a notification message. When such a - message is relayed it is permissible to leave the reverse-path - null. A MAIL command with a null reverse-path appears as follows: - - MAIL FROM:<> - - An undeliverable mail notification message is shown in example 7. - This notification is in response to a message originated by JOE at - HOSTW and sent via HOSTX to HOSTY with instructions to relay it on - to HOSTZ. What we see in the example is the transaction between - HOSTY and HOSTX, which is the first step in the return of the - notification message. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 15] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example Undeliverable Mail Notification Message - - S: MAIL FROM:<> - R: 250 ok - S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA> - R: 250 ok - S: DATA - R: 354 send the mail data, end with . - S: Date: 23 Oct 81 11:22:33 - S: From: SMTP@HOSTY.ARPA - S: To: JOE@HOSTW.ARPA - S: Subject: Mail System Problem - S: - S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost. - S: HOSTZ.ARPA said this: - S: "550 No Such User" - S: . - R: 250 ok - - Example 7 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 16] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 3.7. DOMAINS - - Domains are a recently introduced concept in the ARPA Internet - mail system. The use of domains changes the address space from a - flat global space of simple character string host names to a - hierarchically structured rooted tree of global addresses. The - host name is replaced by a domain and host designator which is a - sequence of domain element strings separated by periods with the - understanding that the domain elements are ordered from the most - specific to the most general. - - For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and - "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers. - - Whenever domain names are used in SMTP only the official names are - used, the use of nicknames or aliases is not allowed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 17] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 3.8. CHANGING ROLES - - The TURN command may be used to reverse the roles of the two - programs communicating over the transmission channel. - - If program-A is currently the sender-SMTP and it sends the TURN - command and receives an ok reply (250) then program-A becomes the - receiver-SMTP. - - If program-B is currently the receiver-SMTP and it receives the - TURN command and sends an ok reply (250) then program-B becomes - the sender-SMTP. - - To refuse to change roles the receiver sends the 502 reply. - - Please note that this command is optional. It would not normally - be used in situations where the transmission channel is TCP. - However, when the cost of establishing the transmission channel is - high, this command may be quite useful. For example, this command - may be useful in supporting be mail exchange using the public - switched telephone system as a transmission channel, especially if - some hosts poll other hosts for mail exchanges. - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 18] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -4. THE SMTP SPECIFICATIONS - - 4.1. SMTP COMMANDS - - 4.1.1. COMMAND SEMANTICS - - The SMTP commands define the mail transfer or the mail system - function requested by the user. SMTP commands are character - strings terminated by <CRLF>. The command codes themselves are - alphabetic characters terminated by <SP> if parameters follow - and <CRLF> otherwise. The syntax of mailboxes must conform to - receiver site conventions. The SMTP commands are discussed - below. The SMTP replies are discussed in the Section 4.2. - - A mail transaction involves several data objects which are - communicated as arguments to different commands. The - reverse-path is the argument of the MAIL command, the - forward-path is the argument of the RCPT command, and the mail - data is the argument of the DATA command. These arguments or - data objects must be transmitted and held pending the - confirmation communicated by the end of mail data indication - which finalizes the transaction. The model for this is that - distinct buffers are provided to hold the types of data - objects, that is, there is a reverse-path buffer, a - forward-path buffer, and a mail data buffer. Specific commands - cause information to be appended to a specific buffer, or cause - one or more buffers to be cleared. - - HELLO (HELO) - - This command is used to identify the sender-SMTP to the - receiver-SMTP. The argument field contains the host name of - the sender-SMTP. - - The receiver-SMTP identifies itself to the sender-SMTP in - the connection greeting reply, and in the response to this - command. - - This command and an OK reply to it confirm that both the - sender-SMTP and the receiver-SMTP are in the initial state, - that is, there is no transaction in progress and all state - tables and buffers are cleared. - - - - - - - -Postel [Page 19] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - MAIL (MAIL) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more mailboxes. The - argument field contains a reverse-path. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). In some types of error - reporting messages (for example, undeliverable mail - notifications) the reverse-path may be null (see Example 7). - - This command clears the reverse-path buffer, the - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - RECIPIENT (RCPT) - - This command is used to identify an individual recipient of - the mail data; multiple recipients are specified by multiple - use of this command. - - The forward-path consists of an optional list of hosts and a - required destination mailbox. When the list of hosts is - present, it is a source route and indicates that the mail - must be relayed to the next host on the list. If the - receiver-SMTP does not implement the relay function it may - user the same reply it would for an unknown local user - (550). - - When mail is relayed, the relay host must remove itself from - the beginning forward-path and put itself at the beginning - of the reverse-path. When mail reaches its ultimate - destination (the forward-path contains only a destination - mailbox), the receiver-SMTP inserts it into the destination - mailbox in accordance with its host mail conventions. - - - - - -[Page 20] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - For example, mail received at relay host A with arguments - - FROM:<USERX@HOSTY.ARPA> - TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA> - - will be relayed on to host B with arguments - - FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA> - TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>. - - This command causes its forward-path argument to be appended - to the forward-path buffer. - - DATA (DATA) - - The receiver treats the lines following the command as mail - data from the sender. This command causes the mail data - from this command to be appended to the mail data buffer. - The mail data may contain any of the 128 ASCII character - codes. - - The mail data is terminated by a line containing only a - period, that is the character sequence "<CRLF>.<CRLF>" (see - Section 4.5.2 on Transparency). This is the end of mail - data indication. - - The end of mail data indication requires that the receiver - must now process the stored mail transaction information. - This processing consumes the information in the reverse-path - buffer, the forward-path buffer, and the mail data buffer, - and on the completion of this command these buffers are - cleared. If the processing is successful the receiver must - send an OK reply. If the processing fails completely the - receiver must send a failure reply. - - When the receiver-SMTP accepts a message either for relaying - or for final delivery it inserts at the beginning of the - mail data a time stamp line. The time stamp line indicates - the identity of the host that sent the message, and the - identity of the host that received the message (and is - inserting this time stamp), and the date and time the - message was received. Relayed messages will have multiple - time stamp lines. - - When the receiver-SMTP makes the "final delivery" of a - message it inserts at the beginning of the mail data a - - - -Postel [Page 21] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - return path line. The return path line preserves the - information in the <reverse-path> from the MAIL command. - Here, final delivery means the message leaves the SMTP - world. Normally, this would mean it has been delivered to - the destination user, but in some cases it may be further - processed and transmitted by another mail system. - - It is possible for the mailbox in the return path be - different from the actual sender's mailbox, for example, - if error responses are to be delivered a special error - handling mailbox rather than the message senders. - - The preceding two paragraphs imply that the final mail data - will begin with a return path line, followed by one or more - time stamp lines. These lines will be followed by the mail - data header and body [2]. See Example 8. - - Special mention is needed of the response and further action - required when the processing following the end of mail data - indication is partially successful. This could arise if - after accepting several recipients and the mail data, the - receiver-SMTP finds that the mail data can be successfully - delivered to some of the recipients, but it cannot be to - others (for example, due to mailbox space allocation - problems). In such a situation, the response to the DATA - command must be an OK reply. But, the receiver-SMTP must - compose and send an "undeliverable mail" notification - message to the originator of the message. Either a single - notification which lists all of the recipients that failed - to get the message, or separate notification messages must - be sent for each failed recipient (see Example 7). All - undeliverable mail notification messages are sent using the - MAIL command (even if they result from processing a SEND, - SOML, or SAML command). - - - - - - - - - - - - - - - -[Page 22] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Example of Return Path and Received Time Stamps - - Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA> - Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST - Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST - Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST - Date: 27 Oct 81 15:01:01 PST - From: JOE@ABC.ARPA - Subject: Improved Mailing System Installed - To: SAM@JKL.ARPA - - This is to inform you that ... - - Example 8 - - ------------------------------------------------------------- - - SEND (SEND) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more terminals. The - argument field contains a reverse-path. This command is - successful if the message is delivered to a terminal. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). - - This command clears the reverse-path buffer, the - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - SEND OR MAIL (SOML) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more terminals or - - - -Postel [Page 23] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - mailboxes. For each recipient the mail data is delivered to - the recipient's terminal if the recipient is active on the - host (and accepting terminal messages), otherwise to the - recipient's mailbox. The argument field contains a - reverse-path. This command is successful if the message is - delivered to a terminal or the mailbox. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). - - This command clears the reverse-path buffer, the - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - SEND AND MAIL (SAML) - - This command is used to initiate a mail transaction in which - the mail data is delivered to one or more terminals and - mailboxes. For each recipient the mail data is delivered to - the recipient's terminal if the recipient is active on the - host (and accepting terminal messages), and for all - recipients to the recipient's mailbox. The argument field - contains a reverse-path. This command is successful if the - message is delivered to the mailbox. - - The reverse-path consists of an optional list of hosts and - the sender mailbox. When the list of hosts is present, it - is a "reverse" source route and indicates that the mail was - relayed through each host on the list (the first host in the - list was the most recent relay). This list is used as a - source route to return non-delivery notices to the sender. - As each relay host adds itself to the beginning of the list, - it must use its name as known in the IPCE to which it is - relaying the mail rather than the IPCE from which the mail - came (if they are different). - - This command clears the reverse-path buffer, the - - - -[Page 24] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - forward-path buffer, and the mail data buffer; and inserts - the reverse-path information from this command into the - reverse-path buffer. - - RESET (RSET) - - This command specifies that the current mail transaction is - to be aborted. Any stored sender, recipients, and mail data - must be discarded, and all buffers and state tables cleared. - The receiver must send an OK reply. - - VERIFY (VRFY) - - This command asks the receiver to confirm that the argument - identifies a user. If it is a user name, the full name of - the user (if known) and the fully specified mailbox are - returned. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - EXPAND (EXPN) - - This command asks the receiver to confirm that the argument - identifies a mailing list, and if so, to return the - membership of that list. The full name of the users (if - known) and the fully specified mailboxes are returned in a - multiline reply. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - HELP (HELP) - - This command causes the receiver to send helpful information - to the sender of the HELP command. The command may take an - argument (e.g., any command name) and return more specific - information as a response. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - - - - - - - -Postel [Page 25] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - NOOP (NOOP) - - This command does not affect any parameters or previously - entered commands. It specifies no action other than that - the receiver send an OK reply. - - This command has no effect on any of the reverse-path - buffer, the forward-path buffer, or the mail data buffer. - - QUIT (QUIT) - - This command specifies that the receiver must send an OK - reply, and then close the transmission channel. - - The receiver should not close the transmission channel until - it receives and replies to a QUIT command (even if there was - an error). The sender should not close the transmission - channel until it send a QUIT command and receives the reply - (even if there was an error response to a previous command). - If the connection is closed prematurely the receiver should - act as if a RSET command had been received (canceling any - pending transaction, but not undoing any previously - completed transaction), the sender should act as if the - command or transaction in progress had received a temporary - error (4xx). - - TURN (TURN) - - This command specifies that the receiver must either (1) - send an OK reply and then take on the role of the - sender-SMTP, or (2) send a refusal reply and retain the role - of the receiver-SMTP. - - If program-A is currently the sender-SMTP and it sends the - TURN command and receives an OK reply (250) then program-A - becomes the receiver-SMTP. Program-A is then in the initial - state as if the transmission channel just opened, and it - then sends the 220 service ready greeting. - - If program-B is currently the receiver-SMTP and it receives - the TURN command and sends an OK reply (250) then program-B - becomes the sender-SMTP. Program-B is then in the initial - state as if the transmission channel just opened, and it - then expects to receive the 220 service ready greeting. - - To refuse to change roles the receiver sends the 502 reply. - - - -[Page 26] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - There are restrictions on the order in which these command may - be used. - - The first command in a session must be the HELO command. - The HELO command may be used later in a session as well. If - the HELO command argument is not acceptable a 501 failure - reply must be returned and the receiver-SMTP must stay in - the same state. - - The NOOP, HELP, EXPN, and VRFY commands can be used at any - time during a session. - - The MAIL, SEND, SOML, or SAML commands begin a mail - transaction. Once started a mail transaction consists of - one of the transaction beginning commands, one or more RCPT - commands, and a DATA command, in that order. A mail - transaction may be aborted by the RSET command. There may - be zero or more transactions in a session. - - If the transaction beginning command argument is not - acceptable a 501 failure reply must be returned and the - receiver-SMTP must stay in the same state. If the commands - in a transaction are out of order a 503 failure reply must - be returned and the receiver-SMTP must stay in the same - state. - - The last command in a session must be the QUIT command. The - QUIT command can not be used at any other time in a session. - - 4.1.2. COMMAND SYNTAX - - The commands consist of a command code followed by an argument - field. Command codes are four alphabetic characters. Upper - and lower case alphabetic characters are to be treated - identically. Thus, any of the following may represent the mail - command: - - MAIL Mail mail MaIl mAIl - - This also applies to any symbols representing parameter values, - such as "TO" or "to" for the forward-path. Command codes and - the argument fields are separated by one or more spaces. - However, within the reverse-path and forward-path arguments - case is important. In particular, in some hosts the user - "smith" is different from the user "Smith". - - - - -Postel [Page 27] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The argument field consists of a variable length character - string ending with the character sequence <CRLF>. The receiver - is to take no action until this sequence is received. - - Square brackets denote an optional argument field. If the - option is not taken, the appropriate default is implied. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 28] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - The following are the SMTP commands: - - HELO <SP> <domain> <CRLF> - - MAIL <SP> FROM:<reverse-path> <CRLF> - - RCPT <SP> TO:<forward-path> <CRLF> - - DATA <CRLF> - - RSET <CRLF> - - SEND <SP> FROM:<reverse-path> <CRLF> - - SOML <SP> FROM:<reverse-path> <CRLF> - - SAML <SP> FROM:<reverse-path> <CRLF> - - VRFY <SP> <string> <CRLF> - - EXPN <SP> <string> <CRLF> - - HELP [<SP> <string>] <CRLF> - - NOOP <CRLF> - - QUIT <CRLF> - - TURN <CRLF> - - - - - - - - - - - - - - - - - - - - -Postel [Page 29] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The syntax of the above argument fields (using BNF notation - where applicable) is given below. The "..." notation indicates - that a field may be repeated one or more times. - - <reverse-path> ::= <path> - - <forward-path> ::= <path> - - <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">" - - <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l> - - <at-domain> ::= "@" <domain> - - <domain> ::= <element> | <element> "." <domain> - - <element> ::= <name> | "#" <number> | "[" <dotnum> "]" - - <mailbox> ::= <local-part> "@" <domain> - - <local-part> ::= <dot-string> | <quoted-string> - - <name> ::= <a> <ldh-str> <let-dig> - - <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str> - - <let-dig> ::= <a> | <d> - - <let-dig-hyp> ::= <a> | <d> | "-" - - <dot-string> ::= <string> | <string> "." <dot-string> - - <string> ::= <char> | <char> <string> - - <quoted-string> ::= """ <qtext> """ - - <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext> - - <char> ::= <c> | "\" <x> - - <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> - - <number> ::= <d> | <d> <number> - - <CRLF> ::= <CR> <LF> - - - - -[Page 30] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - <CR> ::= the carriage return character (ASCII code 13) - - <LF> ::= the line feed character (ASCII code 10) - - <SP> ::= the space character (ASCII code 32) - - <snum> ::= one, two, or three digits representing a decimal - integer value in the range 0 through 255 - - <a> ::= any one of the 52 alphabetic characters A through Z - in upper case and a through z in lower case - - <c> ::= any one of the 128 ASCII characters, but not any - <special> or <SP> - - <d> ::= any one of the ten digits 0 through 9 - - <q> ::= any one of the 128 ASCII characters except <CR>, - <LF>, quote ("), or backslash (\) - - <x> ::= any one of the 128 ASCII characters (no exceptions) - - <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." - | "," | ";" | ":" | "@" """ | the control - characters (ASCII codes 0 through 31 inclusive and - 127) - - Note that the backslash, "\", is a quote character, which is - used to indicate that the next character is to be used - literally (instead of its normal interpretation). For example, - "Joe\,Smith" could be used to indicate a single nine character - user field with comma being the fourth character of the field. - - Hosts are generally known by names which are translated to - addresses in each host. Note that the name elements of domains - are the official names -- no use of nicknames or aliases is - allowed. - - Sometimes a host is not known to the translation function and - communication is blocked. To bypass this barrier two numeric - forms are also allowed for host "names". One form is a decimal - integer prefixed by a pound sign, "#", which indicates the - number is the address of the host. Another form is four small - decimal integers separated by dots and enclosed by brackets, - e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet - Address in four 8-bit fields. - - - -Postel [Page 31] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - The time stamp line and the return path line are formally - defined as follows: - - <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF> - - <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF> - - <stamp> ::= <from-domain> <by-domain> <opt-info> ";" - <daytime> - - <from-domain> ::= "FROM" <SP> <domain> <SP> - - <by-domain> ::= "BY" <SP> <domain> <SP> - - <opt-info> ::= [<via>] [<with>] [<id>] [<for>] - - <via> ::= "VIA" <SP> <link> <SP> - - <with> ::= "WITH" <SP> <protocol> <SP> - - <id> ::= "ID" <SP> <string> <SP> - - <for> ::= "FOR" <SP> <path> <SP> - - <link> ::= The standard names for links are registered with - the Network Information Center. - - <protocol> ::= The standard names for protocols are - registered with the Network Information Center. - - <daytime> ::= <SP> <date> <SP> <time> - - <date> ::= <dd> <SP> <mon> <SP> <yy> - - <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone> - - <dd> ::= the one or two decimal integer day of the month in - the range 1 to 31. - - <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | - "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" - - <yy> ::= the two decimal integer year of the century in the - range 00 to 99. - - - - - -[Page 32] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - <hh> ::= the two decimal integer hour of the day in the - range 00 to 24. - - <mm> ::= the two decimal integer minute of the hour in the - range 00 to 59. - - <ss> ::= the two decimal integer second of the minute in the - range 00 to 59. - - <zone> ::= "UT" for Universal Time (the default) or other - time zone designator (as in [2]). - - - - ------------------------------------------------------------- - - Return Path Example - - Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> - - Example 9 - - ------------------------------------------------------------- - - ------------------------------------------------------------- - - Time Stamp Line Example - - Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT - - Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 - id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT - - Example 10 - - ------------------------------------------------------------- - - - - - - - - - - - - - -Postel [Page 33] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 4.2. SMTP REPLIES - - Replies to SMTP commands are devised to ensure the synchronization - of requests and actions in the process of mail transfer, and to - guarantee that the sender-SMTP always knows the state of the - receiver-SMTP. Every command must generate exactly one reply. - - The details of the command-reply sequence are made explicit in - Section 5.3 on Sequencing and Section 5.4 State Diagrams. - - An SMTP reply consists of a three digit number (transmitted as - three alphanumeric characters) followed by some text. The number - is intended for use by automata to determine what state to enter - next; the text is meant for the human user. It is intended that - the three digits contain enough encoded information that the - sender-SMTP need not examine the text and may either discard it or - pass it on to the user, as appropriate. In particular, the text - may be receiver-dependent and context dependent, so there are - likely to be varying texts for each reply code. A discussion of - the theory of reply codes is given in Appendix E. Formally, a - reply is defined to be the sequence: a three-digit code, <SP>, - one line of text, and <CRLF>, or a multiline reply (as defined in - Appendix E). Only the EXPN and HELP commands are expected to - result in multiline replies in normal circumstances, however - multiline replies are allowed for any command. - - - - - - - - - - - - - - - - - - - - - - - - -[Page 34] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.2.1. REPLY CODES BY FUNCTION GROUPS - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access] - 451 Requested action aborted: error in processing - 551 User not local; please try <forward-path> - 452 Requested action not taken: insufficient system storage - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 354 Start mail input; end with <CRLF>.<CRLF> - 554 Transaction failed - - - - - - - - - - - - - -Postel [Page 35] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - 4.2.2. NUMERIC ORDER LIST OF REPLY CODES - - 211 System status, or system help reply - 214 Help message - [Information on how to use the receiver or the meaning of a - particular non-standard command; this reply is useful only - to the human user] - 220 <domain> Service ready - 221 <domain> Service closing transmission channel - 250 Requested mail action okay, completed - 251 User not local; will forward to <forward-path> - - 354 Start mail input; end with <CRLF>.<CRLF> - - 421 <domain> Service not available, - closing transmission channel - [This may be a reply to any command if the service knows it - must shut down] - 450 Requested mail action not taken: mailbox unavailable - [E.g., mailbox busy] - 451 Requested action aborted: local error in processing - 452 Requested action not taken: insufficient system storage - - 500 Syntax error, command unrecognized - [This may include errors such as command line too long] - 501 Syntax error in parameters or arguments - 502 Command not implemented - 503 Bad sequence of commands - 504 Command parameter not implemented - 550 Requested action not taken: mailbox unavailable - [E.g., mailbox not found, no access] - 551 User not local; please try <forward-path> - 552 Requested mail action aborted: exceeded storage allocation - 553 Requested action not taken: mailbox name not allowed - [E.g., mailbox syntax incorrect] - 554 Transaction failed - - - - - - - - - - - - - -[Page 36] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.3. SEQUENCING OF COMMANDS AND REPLIES - - The communication between the sender and receiver is intended to - be an alternating dialogue, controlled by the sender. As such, - the sender issues a command and the receiver responds with a - reply. The sender must wait for this response before sending - further commands. - - One important reply is the connection greeting. Normally, a - receiver will send a 220 "Service ready" reply when the connection - is completed. The sender should wait for this greeting message - before sending any commands. - - Note: all the greeting type replies have the official name of - the server host as the first word following the reply code. - - For example, - - 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF> - - The table below lists alternative success and failure replies for - each command. These must be strictly adhered to; a receiver may - substitute text in the replies, but the meaning and action implied - by the code numbers and by the specific command reply sequence - cannot be altered. - - COMMAND-REPLY SEQUENCES - - Each command is listed with its possible replies. The prefixes - used before the possible replies are "P" for preliminary (not - used in SMTP), "I" for intermediate, "S" for success, "F" for - failure, and "E" for error. The 421 reply (service not - available, closing transmission channel) may be given to any - command if the SMTP-receiver knows it must shut down. This - listing forms the basis for the State Diagrams in Section 4.4. - - CONNECTION ESTABLISHMENT - S: 220 - F: 421 - HELO - S: 250 - E: 500, 501, 504, 421 - MAIL - S: 250 - F: 552, 451, 452 - E: 500, 501, 421 - - - -Postel [Page 37] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - RCPT - S: 250, 251 - F: 550, 551, 552, 553, 450, 451, 452 - E: 500, 501, 503, 421 - DATA - I: 354 -> data -> S: 250 - F: 552, 554, 451, 452 - F: 451, 554 - E: 500, 501, 503, 421 - RSET - S: 250 - E: 500, 501, 504, 421 - SEND - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SOML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - SAML - S: 250 - F: 552, 451, 452 - E: 500, 501, 502, 421 - VRFY - S: 250, 251 - F: 550, 551, 553 - E: 500, 501, 502, 504, 421 - EXPN - S: 250 - F: 550 - E: 500, 501, 502, 504, 421 - HELP - S: 211, 214 - E: 500, 501, 502, 504, 421 - NOOP - S: 250 - E: 500, 421 - QUIT - S: 221 - E: 500 - TURN - S: 250 - F: 502 - E: 500, 503 - - - - -[Page 38] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.4. STATE DIAGRAMS - - Following are state diagrams for a simple-minded SMTP - implementation. Only the first digit of the reply codes is used. - There is one state diagram for each group of SMTP commands. The - command groupings were determined by constructing a model for each - command and then collecting together the commands with - structurally identical models. - - For each command there are three possible outcomes: "success" - (S), "failure" (F), and "error" (E). In the state diagrams below - we use the symbol B for "begin", and the symbol W for "wait for - reply". - - First, the diagram that represents most of the SMTP commands: - - - 1,3 +---+ - ----------->| E | - | +---+ - | - +---+ cmd +---+ 2 +---+ - | B |---------->| W |---------->| S | - +---+ +---+ +---+ - | - | 4,5 +---+ - ----------->| F | - +---+ - - - This diagram models the commands: - - HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, - NOOP, QUIT, TURN. - - - - - - - - - - - - - - - -Postel [Page 39] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - A more complex diagram models the DATA command: - - - +---+ DATA +---+ 1,2 +---+ - | B |---------->| W |-------------------->| E | - +---+ +---+ ------------>+---+ - 3| |4,5 | - | | | - -------------- ----- | - | | | +---+ - | ---------- -------->| S | - | | | | +---+ - | | ------------ - | | | | - V 1,3| |2 | - +---+ data +---+ --------------->+---+ - | |---------->| W | | F | - +---+ +---+-------------------->+---+ - 4,5 - - - Note that the "data" here is a series of lines sent from the - sender to the receiver with no response expected until the last - line is sent. - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 40] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - 4.5. DETAILS - - 4.5.1. MINIMUM IMPLEMENTATION - - In order to make SMTP workable, the following minimum - implementation is required for all receivers: - - COMMANDS -- HELO - MAIL - RCPT - DATA - RSET - NOOP - QUIT - - 4.5.2. TRANSPARENCY - - Without some provision for data transparency the character - sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent - by the user. In general, users are not aware of such - "forbidden" sequences. To allow all user composed text to be - transmitted transparently the following procedures are used. - - 1. Before sending a line of mail text the sender-SMTP checks - the first character of the line. If it is a period, one - additional period is inserted at the beginning of the line. - - 2. When a line of mail text is received by the receiver-SMTP - it checks the line. If the line is composed of a single - period it is the end of mail. If the first character is a - period and there are other characters on the line, the first - character is deleted. - - The mail data may contain any of the 128 ASCII characters. All - characters are to be delivered to the recipient's mailbox - including format effectors and other control characters. If - the transmission channel provides an 8-bit byte (octets) data - stream, the 7-bit ASCII codes are transmitted right justified - in the octets with the high order bits cleared to zero. - - In some systems it may be necessary to transform the data as - it is received and stored. This may be necessary for hosts - that use a different character set than ASCII as their local - character set, or that store data in records rather than - - - - - -Postel [Page 41] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - strings. If such transforms are necessary, they must be - reversible -- especially if such transforms are applied to - mail being relayed. - - 4.5.3. SIZES - - There are several objects that have required minimum maximum - sizes. That is, every implementation must be able to receive - objects of at least these sizes, but must not send objects - larger than these sizes. - - - **************************************************** - * * - * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * - * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * - * OF THESE OBJECTS SHOULD BE USED. * - * * - **************************************************** - - user - - The maximum total length of a user name is 64 characters. - - domain - - The maximum total length of a domain name or number is 64 - characters. - - path - - The maximum total length of a reverse-path or - forward-path is 256 characters (including the punctuation - and element separators). - - command line - - The maximum total length of a command line including the - command word and the <CRLF> is 512 characters. - - reply line - - The maximum total length of a reply line including the - reply code and the <CRLF> is 512 characters. - - - - - -[Page 42] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - text line - - The maximum total length of a text line including the - <CRLF> is 1000 characters (but not counting the leading - dot duplicated for transparency). - - recipients buffer - - The maximum total number of recipients that must be - buffered is 100 recipients. - - - **************************************************** - * * - * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * - * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * - * OF THESE OBJECTS SHOULD BE USED. * - * * - **************************************************** - - Errors due to exceeding these limits may be reported by using - the reply codes, for example: - - 500 Line too long. - - 501 Path too long - - 552 Too many recipients. - - 552 Too much mail data. - - - - - - - - - - - - - - - - - - - -Postel [Page 43] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX A - - TCP Transport service - - The Transmission Control Protocol [3] is used in the ARPA - Internet, and in any network following the US DoD standards for - internetwork protocols. - - Connection Establishment - - The SMTP transmission channel is a TCP connection established - between the sender process port U and the receiver process port - L. This single full duplex connection is used as the - transmission channel. This protocol is assigned the service - port 25 (31 octal), that is L=25. - - Data Transfer - - The TCP connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 44] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX B - - NCP Transport service - - The ARPANET Host-to-Host Protocol [4] (implemented by the Network - Control Program) may be used in the ARPANET. - - Connection Establishment - - The SMTP transmission channel is established via NCP between - the sender process socket U and receiver process socket L. The - Initial Connection Protocol [5] is followed resulting in a pair - of simplex connections. This pair of connections is used as - the transmission channel. This protocol is assigned the - contact socket 25 (31 octal), that is L=25. - - Data Transfer - - The NCP data connections are established in 8-bit byte mode. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 45] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX C - - NITS - - The Network Independent Transport Service [6] may be used. - - Connection Establishment - - The SMTP transmission channel is established via NITS between - the sender process and receiver process. The sender process - executes the CONNECT primitive, and the waiting receiver - process executes the ACCEPT primitive. - - Data Transfer - - The NITS connection supports the transmission of 8-bit bytes. - The SMTP data is 7-bit ASCII characters. Each character is - transmitted as an 8-bit byte with the high-order bit cleared to - zero. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 46] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX D - - X.25 Transport service - - It may be possible to use the X.25 service [7] as provided by the - Public Data Networks directly, however, it is suggested that a - reliable end-to-end protocol such as TCP be used on top of X.25 - connections. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 47] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -APPENDIX E - - Theory of Reply Codes - - The three digits of the reply each have a special significance. - The first digit denotes whether the response is good, bad or - incomplete. An unsophisticated sender-SMTP will be able to - determine its next action (proceed as planned, redo, retrench, - etc.) by simply examining this first digit. A sender-SMTP that - wants to know approximately what kind of error occurred (e.g., - mail system error, command syntax error) may examine the second - digit, reserving the third digit for the finest gradation of - information. - - There are five values for the first digit of the reply code: - - 1yz Positive Preliminary reply - - The command has been accepted, but the requested action - is being held in abeyance, pending confirmation of the - information in this reply. The sender-SMTP should send - another command specifying whether to continue or abort - the action. - - [Note: SMTP does not have any commands that allow this - type of reply, and so does not have the continue or - abort commands.] - - 2yz Positive Completion reply - - The requested action has been successfully completed. A - new request may be initiated. - - 3yz Positive Intermediate reply - - The command has been accepted, but the requested action - is being held in abeyance, pending receipt of further - information. The sender-SMTP should send another command - specifying this information. This reply is used in - command sequence groups. - - 4yz Transient Negative Completion reply - - The command was not accepted and the requested action did - not occur. However, the error condition is temporary and - the action may be requested again. The sender should - - - -[Page 48] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - return to the beginning of the command sequence (if any). - It is difficult to assign a meaning to "transient" when - two different sites (receiver- and sender- SMTPs) must - agree on the interpretation. Each reply in this category - might have a different time value, but the sender-SMTP is - encouraged to try again. A rule of thumb to determine if - a reply fits into the 4yz or the 5yz category (see below) - is that replies are 4yz if they can be repeated without - any change in command form or in properties of the sender - or receiver. (E.g., the command is repeated identically - and the receiver does not put up a new implementation.) - - 5yz Permanent Negative Completion reply - - The command was not accepted and the requested action did - not occur. The sender-SMTP is discouraged from repeating - the exact request (in the same sequence). Even some - "permanent" error conditions can be corrected, so the - human user may want to direct the sender-SMTP to - reinitiate the command sequence by direct action at some - point in the future (e.g., after the spelling has been - changed, or the user has altered the account status). - - The second digit encodes responses in specific categories: - - x0z Syntax -- These replies refer to syntax errors, - syntactically correct commands that don't fit any - functional category, and unimplemented or superfluous - commands. - - x1z Information -- These are replies to requests for - information, such as status or help. - - x2z Connections -- These are replies referring to the - transmission channel. - - x3z Unspecified as yet. - - x4z Unspecified as yet. - - x5z Mail system -- These replies indicate the status of - the receiver mail system vis-a-vis the requested - transfer or other mail system action. - - The third digit gives a finer gradation of meaning in each - category specified by the second digit. The list of replies - - - -Postel [Page 49] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - illustrates this. Each reply text is recommended rather than - mandatory, and may even change according to the command with - which it is associated. On the other hand, the reply codes - must strictly follow the specifications in this section. - Receiver implementations should not invent new codes for - slightly different situations from the ones described here, but - rather adapt codes already defined. - - For example, a command such as NOOP whose successful execution - does not offer the sender-SMTP any new information will return - a 250 reply. The response is 502 when the command requests an - unimplemented non-site-specific action. A refinement of that - is the 504 reply for a command that is implemented, but that - requests an unimplemented parameter. - - The reply text may be longer than a single line; in these cases - the complete text must be marked so the sender-SMTP knows when it - can stop reading the reply. This requires a special format to - indicate a multiple line reply. - - The format for multiline replies requires that every line, - except the last, begin with the reply code, followed - immediately by a hyphen, "-" (also known as minus), followed by - text. The last line will begin with the reply code, followed - immediately by <SP>, optionally some text, and <CRLF>. - - For example: - 123-First line - 123-Second line - 123-234 text beginning with numbers - 123 The last line - - In many cases the sender-SMTP then simply needs to search for - the reply code followed by <SP> at the beginning of a line, and - ignore all preceding lines. In a few cases, there is important - data for the sender in the reply "text". The sender will know - these cases from the current context. - - - - - - - - - - - - -[Page 50] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -APPENDIX F - - Scenarios - - This section presents complete scenarios of several types of SMTP - sessions. - - A Typical SMTP Transaction Scenario - - This SMTP example shows mail sent by Smith at host USC-ISIF, to - Jones, Green, and Brown at host BBN-UNIX. Here we assume that - host USC-ISIF contacts host BBN-UNIX directly. The mail is - accepted for Jones and Brown. Green does not have a mailbox at - host BBN-UNIX. - - ------------------------------------------------------------- - - R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BBN-UNIX.ARPA - - S: MAIL FROM:<Smith@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<Green@BBN-UNIX.ARPA> - R: 550 No such user here - - S: RCPT TO:<Brown@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BBN-UNIX.ARPA Service closing transmission channel - - Scenario 1 - - ------------------------------------------------------------- - - - -Postel [Page 51] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Aborted SMTP Transaction Scenario - - ------------------------------------------------------------- - - R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready - S: HELO ISI-VAXA.ARPA - R: 250 MIT-Multics.ARPA - - S: MAIL FROM:<Smith@ISI-VAXA.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@MIT-Multics.ARPA> - R: 250 OK - - S: RCPT TO:<Green@MIT-Multics.ARPA> - R: 550 No such user here - - S: RSET - R: 250 OK - - S: QUIT - R: 221 MIT-Multics.ARPA Service closing transmission channel - - Scenario 2 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - - -[Page 52] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Relayed Mail Scenario - - ------------------------------------------------------------- - - Step 1 -- Source Host to Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-AI.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - -Postel [Page 53] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Step 2 -- Relay Host to Destination Host - - R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIE.ARPA - R: 250 BBN-VAX.ARPA - - S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@BBN-VAX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; - 2 Nov 81 22:40:10 UT - S: Date: 2 Nov 81 22:33:44 - S: From: John Q. Public <JQP@MIT-AI.ARPA> - S: Subject: The Next Meeting of the Board - S: To: Jones@BBN-Vax.ARPA - S: - S: Bill: - S: The next meeting of the board of directors will be - S: on Tuesday. - S: John. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 3 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - -[Page 54] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Verifying and Sending Scenario - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SEND FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 4 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - -Postel [Page 55] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Sending and Mailing Scenarios - - First the user's name is verified, then an attempt is made to - send to the user's terminal. When that fails, the messages is - mailed to the user's mailbox. - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SEND FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 450 User not active now - - S: RSET - R: 250 OK - - S: MAIL FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 5 - - ------------------------------------------------------------- - - - - - - -[Page 56] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Doing the preceding scenario more efficiently. - - ------------------------------------------------------------- - - R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready - S: HELO MIT-MC.ARPA - R: 250 SU-SCORE.ARPA - - S: VRFY Crispin - R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA> - - S: SOML FROM:<EAK@MIT-MC.ARPA> - R: 250 OK - - S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA> - R: 250 User not active now, so will do mail. - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 SU-SCORE.ARPA Service closing transmission channel - - Scenario 6 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - -Postel [Page 57] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Mailing List Scenario - - First each of two mailing lists are expanded in separate sessions - with different hosts. Then the message is sent to everyone that - appeared on either list (but no duplicates) via a relay host. - - ------------------------------------------------------------- - - Step 1 -- Expanding the First List - - R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-AI.ARPA - - S: EXPN Example-People - R: 250-<ABC@MIT-MC.ARPA> - R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA> - R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<joe@foo-unix.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-AI.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 58] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Step 2 -- Expanding the Second List - - R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 MIT-MC.ARPA - - S: EXPN Interested-Parties - R: 250-Al Calico <ABC@MIT-MC.ARPA> - R: 250-<XYZ@MIT-AI.ARPA> - R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250-<fred@BBN-UNIX.ARPA> - R: 250 <xyz@bar-unix.ARPA> - - S: QUIT - R: 221 MIT-MC.ARPA Service closing transmission channel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 59] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - Step 3 -- Mailing to All via a Relay Host - - R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready - S: HELO SU-SCORE.ARPA - R: 250 USC-ISIE.ARPA - - S: MAIL FROM:<Account.Person@SU-SCORE.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> - R: 250 OK - S: RCPT - TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> - R: 250 OK - S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIE.ARPA Service closing transmission channel - - Scenario 7 - - ------------------------------------------------------------- - - - - - - - - - - - - -[Page 60] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Forwarding Scenarios - - ------------------------------------------------------------- - - R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISIF.ARPA - - S: MAIL FROM:<mo@LBL-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<fred@USC-ISIF.ARPA> - R: 251 User not local; will forward to <Jones@USC-ISI.ARPA> - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISIF.ARPA Service closing transmission channel - - Scenario 8 - - ------------------------------------------------------------- - - - - - - - - - - - - - - - - - - - - - - -Postel [Page 61] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - ------------------------------------------------------------- - - Step 1 -- Trying the Mailbox at the First Host - - R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISIF.ARPA - - S: MAIL FROM:<mo@LBL-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<fred@USC-ISIF.ARPA> - R: 251 User not local; will forward to <Jones@USC-ISI.ARPA> - - S: RSET - R: 250 OK - - S: QUIT - R: 221 USC-ISIF.ARPA Service closing transmission channel - - Step 2 -- Delivering the Mail at the Second Host - - R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready - S: HELO LBL-UNIX.ARPA - R: 250 USC-ISI.ARPA - - S: MAIL FROM:<mo@LBL-UNIX.ARPA> - R: 250 OK - - S: RCPT TO:<Jones@USC-ISI.ARPA> - R: OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 USC-ISI.ARPA Service closing transmission channel - - Scenario 9 - - ------------------------------------------------------------- - - - - -[Page 62] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - Too Many Recipients Scenario - - ------------------------------------------------------------- - - R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready - S: HELO USC-ISIF.ARPA - R: 250 BERKELEY.ARPA - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<fabry@BERKELEY.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 552 Recipient storage full, try again in another transaction - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: MAIL FROM:<Postel@USC-ISIF.ARPA> - R: 250 OK - - S: RCPT TO:<eric@BERKELEY.ARPA> - R: 250 OK - - S: DATA - R: 354 Start mail input; end with <CRLF>.<CRLF> - S: Blah blah blah... - S: ...etc. etc. etc. - S: . - R: 250 OK - - S: QUIT - R: 221 BERKELEY.ARPA Service closing transmission channel - - Scenario 10 - - ------------------------------------------------------------- - - Note that a real implementation must handle many recipients as - specified in Section 4.5.3. - - - -Postel [Page 63] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - -GLOSSARY - - ASCII - - American Standard Code for Information Interchange [1]. - - command - - A request for a mail service action sent by the sender-SMTP to the - receiver-SMTP. - - domain - - The hierarchially structured global character string address of a - host computer in the mail system. - - end of mail data indication - - A special sequence of characters that indicates the end of the - mail data. In particular, the five characters carriage return, - line feed, period, carriage return, line feed, in that order. - - host - - A computer in the internetwork environment on which mailboxes or - SMTP processes reside. - - line - - A a sequence of ASCII characters ending with a <CRLF>. - - mail data - - A sequence of ASCII characters of arbitrary length, which conforms - to the standard set in the Standard for the Format of ARPA - Internet Text Messages (RFC 822 [2]). - - mailbox - - A character string (address) which identifies a user to whom mail - is to be sent. Mailbox normally consists of the host and user - specifications. The standard mailbox naming convention is defined - to be "user@domain". Additionally, the "container" in which mail - is stored. - - - - - -[Page 64] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - - receiver-SMTP process - - A process which transfers mail in cooperation with a sender-SMTP - process. It waits for a connection to be established via the - transport service. It receives SMTP commands from the - sender-SMTP, sends replies, and performs the specified operations. - - reply - - A reply is an acknowledgment (positive or negative) sent from - receiver to sender via the transmission channel in response to a - command. The general form of a reply is a completion code - (including error codes) followed by a text string. The codes are - for use by programs and the text is usually intended for human - users. - - sender-SMTP process - - A process which transfers mail in cooperation with a receiver-SMTP - process. A local language may be used in the user interface - command/reply dialogue. The sender-SMTP initiates the transport - service connection. It initiates SMTP commands, receives replies, - and governs the transfer of mail. - - session - - The set of exchanges that occur while the transmission channel is - open. - - transaction - - The set of exchanges required for one message to be transmitted - for one or more recipients. - - transmission channel - - A full-duplex communication path between a sender-SMTP and a - receiver-SMTP for the exchange of commands, replies, and mail - text. - - transport service - - Any reliable stream-oriented data communication services. For - example, NCP, TCP, NITS. - - - - - -Postel [Page 65] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - user - - A human being (or a process on behalf of a human being) wishing to - obtain mail transfer service. In addition, a recipient of - computer mail. - - word - - A sequence of printing characters. - - <CRLF> - - The characters carriage return and line feed (in that order). - - <SP> - - The space character. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 66] Postel - - - -RFC 821 August 1982 - Simple Mail Transfer Protocol - - - -REFERENCES - - [1] ASCII - - ASCII, "USA Code for Information Interchange", United States of - America Standards Institute, X3.4, 1968. Also in: Feinler, E. - and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for - the Defense Communications Agency by SRI International, Menlo - Park, California, Revised January 1978. - - [2] RFC 822 - - Crocker, D., "Standard for the Format of ARPA Internet Text - Messages," RFC 822, Department of Electrical Engineering, - University of Delaware, August 1982. - - [3] TCP - - Postel, J., ed., "Transmission Control Protocol - DARPA Internet - Program Protocol Specification", RFC 793, USC/Information Sciences - Institute, NTIS AD Number A111091, September 1981. Also in: - Feinler, E. and J. Postel, eds., "Internet Protocol Transition - Workbook", SRI International, Menlo Park, California, March 1982. - - [4] NCP - - McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, - January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET - Protocol Handbook", NIC 7104, for the Defense Communications - Agency by SRI International, Menlo Park, California, Revised - January 1978. - - [5] Initial Connection Protocol - - Postel, J., "Official Initial Connection Protocol", NIC 7101, - 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET - Protocol Handbook", NIC 7104, for the Defense Communications - Agency by SRI International, Menlo Park, California, Revised - January 1978. - - [6] NITS - - PSS/SG3, "A Network Independent Transport Service", Study Group 3, - The Post Office PSS Users Group, February 1980. Available from - the DCPU, National Physical Laboratory, Teddington, UK. - - - - -Postel [Page 67] - - - -August 1982 RFC 821 -Simple Mail Transfer Protocol - - - - [7] X.25 - - CCITT, "Recommendation X.25 - Interface Between Data Terminal - Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for - Terminals Operating in the Packet Mode on Public Data Networks," - CCITT Orange Book, Vol. VIII.2, International Telephone and - Telegraph Consultative Committee, Geneva, 1976. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -[Page 68] Postel - diff --git a/RFC/rfc822.txt b/RFC/rfc822.txt deleted file mode 100644 index 35b09a3c..00000000 --- a/RFC/rfc822.txt +++ /dev/null @@ -1,2901 +0,0 @@ - - - - - - - RFC # 822 - - Obsoletes: RFC #733 (NIC #41952) - - - - - - - - - - - - - STANDARD FOR THE FORMAT OF - - ARPA INTERNET TEXT MESSAGES - - - - - - - August 13, 1982 - - - - - - - Revised by - - David H. Crocker - - - Dept. of Electrical Engineering - University of Delaware, Newark, DE 19711 - Network: DCrocker @ UDel-Relay - - - - - - - - - - - - - - - - Standard for ARPA Internet Text Messages - - - TABLE OF CONTENTS - - - PREFACE .................................................... ii - - 1. INTRODUCTION ........................................... 1 - - 1.1. Scope ............................................ 1 - 1.2. Communication Framework .......................... 2 - - 2. NOTATIONAL CONVENTIONS ................................. 3 - - 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 - - 3.1. General Description .............................. 5 - 3.2. Header Field Definitions ......................... 9 - 3.3. Lexical Tokens ................................... 10 - 3.4. Clarifications ................................... 11 - - 4. MESSAGE SPECIFICATION .................................. 17 - - 4.1. Syntax ........................................... 17 - 4.2. Forwarding ....................................... 19 - 4.3. Trace Fields ..................................... 20 - 4.4. Originator Fields ................................ 21 - 4.5. Receiver Fields .................................. 23 - 4.6. Reference Fields ................................. 23 - 4.7. Other Fields ..................................... 24 - - 5. DATE AND TIME SPECIFICATION ............................ 26 - - 5.1. Syntax ........................................... 26 - 5.2. Semantics ........................................ 26 - - 6. ADDRESS SPECIFICATION .................................. 27 - - 6.1. Syntax ........................................... 27 - 6.2. Semantics ........................................ 27 - 6.3. Reserved Address ................................. 33 - - 7. BIBLIOGRAPHY ........................................... 34 - - - APPENDIX - - A. EXAMPLES ............................................... 36 - B. SIMPLE FIELD PARSING ................................... 40 - C. DIFFERENCES FROM RFC #733 .............................. 41 - D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 - - - August 13, 1982 - i - RFC #822 - - - - - Standard for ARPA Internet Text Messages - - - PREFACE - - - By 1977, the Arpanet employed several informal standards for - the text messages (mail) sent among its host computers. It was - felt necessary to codify these practices and provide for those - features that seemed imminent. The result of that effort was - Request for Comments (RFC) #733, "Standard for the Format of ARPA - Network Text Message", by Crocker, Vittal, Pogran, and Henderson. - The specification attempted to avoid major changes in existing - software, while permitting several new features. - - This document revises the specifications in RFC #733, in - order to serve the needs of the larger and more complex ARPA - Internet. Some of RFC #733's features failed to gain adequate - acceptance. In order to simplify the standard and the software - that follows it, these features have been removed. A different - addressing scheme is used, to handle the case of inter-network - mail; and the concept of re-transmission has been introduced. - - This specification is intended for use in the ARPA Internet. - However, an attempt has been made to free it of any dependence on - that environment, so that it can be applied to other network text - message systems. - - The specification of RFC #733 took place over the course of - one year, using the ARPANET mail environment, itself, to provide - an on-going forum for discussing the capabilities to be included. - More than twenty individuals, from across the country, partici- - pated in the original discussion. The development of this - revised specification has, similarly, utilized network mail-based - group discussion. Both specification efforts greatly benefited - from the comments and ideas of the participants. - - The syntax of the standard, in RFC #733, was originally - specified in the Backus-Naur Form (BNF) meta-language. Ken L. - Harrenstien, of SRI International, was responsible for re-coding - the BNF into an augmented BNF that makes the representation - smaller and easier to understand. - - - - - - - - - - - - - August 13, 1982 - ii - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 1. INTRODUCTION - - 1.1. SCOPE - - This standard specifies a syntax for text messages that are - sent among computer users, within the framework of "electronic - mail". The standard supersedes the one specified in ARPANET - Request for Comments #733, "Standard for the Format of ARPA Net- - work Text Messages". - - In this context, messages are viewed as having an envelope - and contents. The envelope contains whatever information is - needed to accomplish transmission and delivery. The contents - compose the object to be delivered to the recipient. This stan- - dard applies only to the format and some of the semantics of mes- - sage contents. It contains no specification of the information - in the envelope. - - However, some message systems may use information from the - contents to create the envelope. It is intended that this stan- - dard facilitate the acquisition of such information by programs. - - Some message systems may store messages in formats that - differ from the one specified in this standard. This specifica- - tion is intended strictly as a definition of what message content - format is to be passed BETWEEN hosts. - - Note: This standard is NOT intended to dictate the internal for- - mats used by sites, the specific message system features - that they are expected to support, or any of the charac- - teristics of user interface programs that create or read - messages. - - A distinction should be made between what the specification - REQUIRES and what it ALLOWS. Messages can be made complex and - rich with formally-structured components of information or can be - kept small and simple, with a minimum of such information. Also, - the standard simplifies the interpretation of differing visual - formats in messages; only the visual aspect of a message is - affected and not the interpretation of information within it. - Implementors may choose to retain such visual distinctions. - - The formal definition is divided into four levels. The bot- - tom level describes the meta-notation used in this document. The - second level describes basic lexical analyzers that feed tokens - to higher-level parsers. Next is an overall specification for - messages; it permits distinguishing individual fields. Finally, - there is definition of the contents of several structured fields. - - - - August 13, 1982 - 1 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 1.2. COMMUNICATION FRAMEWORK - - Messages consist of lines of text. No special provisions - are made for encoding drawings, facsimile, speech, or structured - text. No significant consideration has been given to questions - of data compression or to transmission and storage efficiency, - and the standard tends to be free with the number of bits con- - sumed. For example, field names are specified as free text, - rather than special terse codes. - - A general "memo" framework is used. That is, a message con- - sists of some information in a rigid format, followed by the main - part of the message, with a format that is not specified in this - document. The syntax of several fields of the rigidly-formated - ("headers") section is defined in this specification; some of - these fields must be included in all messages. - - The syntax that distinguishes between header fields is - specified separately from the internal syntax for particular - fields. This separation is intended to allow simple parsers to - operate on the general structure of messages, without concern for - the detailed structure of individual header fields. Appendix B - is provided to facilitate construction of these parsers. - - In addition to the fields specified in this document, it is - expected that other fields will gain common use. As necessary, - the specifications for these "extension-fields" will be published - through the same mechanism used to publish this document. Users - may also wish to extend the set of fields that they use - privately. Such "user-defined fields" are permitted. - - The framework severely constrains document tone and appear- - ance and is primarily useful for most intra-organization communi- - cations and well-structured inter-organization communication. - It also can be used for some types of inter-process communica- - tion, such as simple file transfer and remote job entry. A more - robust framework might allow for multi-font, multi-color, multi- - dimension encoding of information. A less robust one, as is - present in most single-machine message systems, would more - severely constrain the ability to add fields and the decision to - include specific fields. In contrast with paper-based communica- - tion, it is interesting to note that the RECEIVER of a message - can exercise an extraordinary amount of control over the - message's appearance. The amount of actual control available to - message receivers is contingent upon the capabilities of their - individual message systems. - - - - - - August 13, 1982 - 2 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 2. NOTATIONAL CONVENTIONS - - This specification uses an augmented Backus-Naur Form (BNF) - notation. The differences from standard BNF involve naming rules - and indicating repetition and "local" alternatives. - - 2.1. RULE NAMING - - Angle brackets ("<", ">") are not used, in general. The - name of a rule is simply the name itself, rather than "<name>". - Quotation-marks enclose literal text (which may be upper and/or - lower case). Certain basic rules are in uppercase, such as - SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in - rule definitions, and in the rest of this document, whenever - their presence will facilitate discerning the use of rule names. - - 2.2. RULE1 / RULE2: ALTERNATIVES - - Elements separated by slash ("/") are alternatives. There- - fore "foo / bar" will accept foo or bar. - - 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES - - Elements enclosed in parentheses are treated as a single - element. Thus, "(elem (foo / bar) elem)" allows the token - sequences "elem foo elem" and "elem bar elem". - - 2.4. *RULE: REPETITION - - The character "*" preceding an element indicates repetition. - The full form is: - - <l>*<m>element - - indicating at least <l> and at most <m> occurrences of element. - Default values are 0 and infinity so that "*(element)" allows any - number, including zero; "1*element" requires at least one; and - "1*2element" allows one or two. - - 2.5. [RULE]: OPTIONAL - - Square brackets enclose optional elements; "[foo bar]" is - equivalent to "*1(foo bar)". - - 2.6. NRULE: SPECIFIC REPETITION - - "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, - exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit - number, and 3ALPHA is a string of three alphabetic characters. - - - August 13, 1982 - 3 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 2.7. #RULE: LISTS - - A construct "#" is defined, similar to "*", as follows: - - <l>#<m>element - - indicating at least <l> and at most <m> elements, each separated - by one or more commas (","). This makes the usual form of lists - very easy; a rule such as '(element *("," element))' can be shown - as "1#element". Wherever this construct is used, null elements - are allowed, but do not contribute to the count of elements - present. That is, "(element),,(element)" is permitted, but - counts as only two elements. Therefore, where at least one ele- - ment is required, at least one non-null element must be present. - Default values are 0 and infinity so that "#(element)" allows any - number, including zero; "1#element" requires at least one; and - "1#2element" allows one or two. - - 2.8. ; COMMENTS - - A semi-colon, set off some distance to the right of rule - text, starts a comment that continues to the end of line. This - is a simple way of including useful notes in parallel with the - specifications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 4 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3. LEXICAL ANALYSIS OF MESSAGES - - 3.1. GENERAL DESCRIPTION - - A message consists of header fields and, optionally, a body. - The body is simply a sequence of lines containing ASCII charac- - ters. It is separated from the headers by a null line (i.e., a - line with nothing preceding the CRLF). - - 3.1.1. LONG HEADER FIELDS - - Each header field can be viewed as a single, logical line of - ASCII characters, comprising a field-name and a field-body. - For convenience, the field-body portion of this conceptual - entity can be split into a multiple-line representation; this - is called "folding". The general rule is that wherever there - may be linear-white-space (NOT simply LWSP-chars), a CRLF - immediately followed by AT LEAST one LWSP-char may instead be - inserted. Thus, the single line - - To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN - - can be represented as: - - To: "Joe & J. Harvey" <ddd @ Org>, - JJV@BBN - - and - - To: "Joe & J. Harvey" - <ddd@ Org>, JJV - @BBN - - and - - To: "Joe & - J. Harvey" <ddd @ Org>, JJV @ BBN - - The process of moving from this folded multiple-line - representation of a header field to its single line represen- - tation is called "unfolding". Unfolding is accomplished by - regarding CRLF immediately followed by a LWSP-char as - equivalent to the LWSP-char. - - Note: While the standard permits folding wherever linear- - white-space is permitted, it is recommended that struc- - tured fields, such as those containing addresses, limit - folding to higher-level syntactic breaks. For address - fields, it is recommended that such folding occur - - - August 13, 1982 - 5 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - between addresses, after the separating comma. - - 3.1.2. STRUCTURE OF HEADER FIELDS - - Once a field has been unfolded, it may be viewed as being com- - posed of a field-name followed by a colon (":"), followed by a - field-body, and terminated by a carriage-return/line-feed. - The field-name must be composed of printable ASCII characters - (i.e., characters that have values between 33. and 126., - decimal, except colon). The field-body may be composed of any - ASCII characters, except CR or LF. (While CR and/or LF may be - present in the actual text, they are removed by the action of - unfolding the field.) - - Certain field-bodies of headers may be interpreted according - to an internal syntax that some systems may wish to parse. - These fields are called "structured fields". Examples - include fields containing dates and addresses. Other fields, - such as "Subject" and "Comments", are regarded simply as - strings of text. - - Note: Any field which has a field-body that is defined as - other than simply <text> is to be treated as a struc- - tured field. - - Field-names, unstructured field bodies and structured - field bodies each are scanned by their own, independent - "lexical" analyzers. - - 3.1.3. UNSTRUCTURED FIELD BODIES - - For some fields, such as "Subject" and "Comments", no struc- - turing is assumed, and they are treated simply as <text>s, as - in the message body. Rules of folding apply to these fields, - so that such field bodies which occupy several lines must - therefore have the second and successive lines indented by at - least one LWSP-char. - - 3.1.4. STRUCTURED FIELD BODIES - - To aid in the creation and reading of structured fields, the - free insertion of linear-white-space (which permits folding - by inclusion of CRLFs) is allowed between lexical tokens. - Rather than obscuring the syntax specifications for these - structured fields with explicit syntax for this linear-white- - space, the existence of another "lexical" analyzer is assumed. - This analyzer does not apply for unstructured field bodies - that are simply strings of text, as described above. The - analyzer provides an interpretation of the unfolded text - - - August 13, 1982 - 6 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - composing the body of the field as a sequence of lexical sym- - bols. - - These symbols are: - - - individual special characters - - quoted-strings - - domain-literals - - comments - - atoms - - The first four of these symbols are self-delimiting. Atoms - are not; they are delimited by the self-delimiting symbols and - by linear-white-space. For the purposes of regenerating - sequences of atoms and quoted-strings, exactly one SPACE is - assumed to exist, and should be used, between them. (Also, in - the "Clarifications" section on "White Space", below, note the - rules about treatment of multiple contiguous LWSP-chars.) - - So, for example, the folded body of an address field - - ":sysmail"@ Some-Group. Some-Org, - Muhammed.(I am the greatest) Ali @(the)Vegas.WBA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 7 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - is analyzed into the following lexical symbols and types: - - :sysmail quoted string - @ special - Some-Group atom - . special - Some-Org atom - , special - Muhammed atom - . special - (I am the greatest) comment - Ali atom - @ atom - (the) comment - Vegas atom - . special - WBA atom - - The canonical representations for the data in these addresses - are the following strings: - - ":sysmail"@Some-Group.Some-Org - - and - - Muhammed.Ali@Vegas.WBA - - Note: For purposes of display, and when passing such struc- - tured information to other systems, such as mail proto- - col services, there must be NO linear-white-space - between <word>s that are separated by period (".") or - at-sign ("@") and exactly one SPACE between all other - <word>s. Also, headers should be in a folded form. - - - - - - - - - - - - - - - - - - - August 13, 1982 - 8 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.2. HEADER FIELD DEFINITIONS - - These rules show a field meta-syntax, without regard for the - particular type or internal syntax. Their purpose is to permit - detection of fields; also, they present to higher-level parsers - an image of each field as fitting on one line. - - field = field-name ":" [ field-body ] CRLF - - field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> - - field-body = field-body-contents - [CRLF LWSP-char field-body] - - field-body-contents = - <the ASCII characters making up the field-body, as - defined in the following sections, and consisting - of combinations of atom, quoted-string, and - specials tokens, or else consisting of texts> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 9 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.3. LEXICAL TOKENS - - The following rules are used to define an underlying lexical - analyzer, which feeds tokens to higher level parsers. See the - ANSI references, in the Bibliography. - - ; ( Octal, Decimal.) - CHAR = <any ASCII character> ; ( 0-177, 0.-127.) - ALPHA = <any ASCII alphabetic character> - ; (101-132, 65.- 90.) - ; (141-172, 97.-122.) - DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) - CTL = <any ASCII control ; ( 0- 37, 0.- 31.) - character and DEL> ; ( 177, 127.) - CR = <ASCII CR, carriage return> ; ( 15, 13.) - LF = <ASCII LF, linefeed> ; ( 12, 10.) - SPACE = <ASCII SP, space> ; ( 40, 32.) - HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) - <"> = <ASCII quote mark> ; ( 42, 34.) - CRLF = CR LF - - LWSP-char = SPACE / HTAB ; semantics = SPACE - - linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE - ; CRLF => folding - - specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- - / "," / ";" / ":" / "\" / <"> ; string, to use - / "." / "[" / "]" ; within a word. - - delimiters = specials / linear-white-space / comment - - text = <any CHAR, including bare ; => atoms, specials, - CR & bare LF, but NOT ; comments and - including CRLF> ; quoted-strings are - ; NOT recognized. - - atom = 1*<any CHAR except specials, SPACE and CTLs> - - quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or - ; quoted chars. - - qtext = <any CHAR excepting <">, ; => may be folded - "\" & CR, and including - linear-white-space> - - domain-literal = "[" *(dtext / quoted-pair) "]" - - - - - August 13, 1982 - 10 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - dtext = <any CHAR excluding "[", ; => may be folded - "]", "\" & CR, & including - linear-white-space> - - comment = "(" *(ctext / quoted-pair / comment) ")" - - ctext = <any CHAR excluding "(", ; => may be folded - ")", "\" & CR, & including - linear-white-space> - - quoted-pair = "\" CHAR ; may quote any char - - phrase = 1*word ; Sequence of words - - word = atom / quoted-string - - - 3.4. CLARIFICATIONS - - 3.4.1. QUOTING - - Some characters are reserved for special interpretation, such - as delimiting lexical tokens. To permit use of these charac- - ters as uninterpreted data, a quoting mechanism is provided. - To quote a character, precede it with a backslash ("\"). - - This mechanism is not fully general. Characters may be quoted - only within a subset of the lexical constructs. In particu- - lar, quoting is limited to use within: - - - quoted-string - - domain-literal - - comment - - Within these constructs, quoting is REQUIRED for CR and "\" - and for the character(s) that delimit the token (e.g., "(" and - ")" for a comment). However, quoting is PERMITTED for any - character. - - Note: In particular, quoting is NOT permitted within atoms. - For example when the local-part of an addr-spec must - contain a special character, a quoted string must be - used. Therefore, a specification such as: - - Full\ Name@Domain - - is not legal and must be specified as: - - "Full Name"@Domain - - - August 13, 1982 - 11 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.4.2. WHITE SPACE - - Note: In structured field bodies, multiple linear space ASCII - characters (namely HTABs and SPACEs) are treated as - single spaces and may freely surround any symbol. In - all header fields, the only place in which at least one - LWSP-char is REQUIRED is at the beginning of continua- - tion lines in a folded field. - - When passing text to processes that do not interpret text - according to this standard (e.g., mail protocol servers), then - NO linear-white-space characters should occur between a period - (".") or at-sign ("@") and a <word>. Exactly ONE SPACE should - be used in place of arbitrary linear-white-space and comment - sequences. - - Note: Within systems conforming to this standard, wherever a - member of the list of delimiters is allowed, LWSP-chars - may also occur before and/or after it. - - Writers of mail-sending (i.e., header-generating) programs - should realize that there is no network-wide definition of the - effect of ASCII HT (horizontal-tab) characters on the appear- - ance of text at another network host; therefore, the use of - tabs in message headers, though permitted, is discouraged. - - 3.4.3. COMMENTS - - A comment is a set of ASCII characters, which is enclosed in - matching parentheses and which is not within a quoted-string - The comment construct permits message originators to add text - which will be useful for human readers, but which will be - ignored by the formal semantics. Comments should be retained - while the message is subject to interpretation according to - this standard. However, comments must NOT be included in - other cases, such as during protocol exchanges with mail - servers. - - Comments nest, so that if an unquoted left parenthesis occurs - in a comment string, there must also be a matching right - parenthesis. When a comment acts as the delimiter between a - sequence of two lexical symbols, such as two atoms, it is lex- - ically equivalent with a single SPACE, for the purposes of - regenerating the sequence, such as when passing the sequence - onto a mail protocol server. Comments are detected as such - only within field-bodies of structured fields. - - If a comment is to be "folded" onto multiple lines, then the - syntax for folding must be adhered to. (See the "Lexical - - - August 13, 1982 - 12 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Analysis of Messages" section on "Folding Long Header Fields" - above, and the section on "Case Independence" below.) Note - that the official semantics therefore do not "see" any - unquoted CRLFs that are in comments, although particular pars- - ing programs may wish to note their presence. For these pro- - grams, it would be reasonable to interpret a "CRLF LWSP-char" - as being a CRLF that is part of the comment; i.e., the CRLF is - kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a - backslash followed by a CR followed by a LF) still must be - followed by at least one LWSP-char. - - 3.4.4. DELIMITING AND QUOTING CHARACTERS - - The quote character (backslash) and characters that delimit - syntactic units are not, generally, to be taken as data that - are part of the delimited or quoted unit(s). In particular, - the quotation-marks that define a quoted-string, the - parentheses that define a comment and the backslash that - quotes a following character are NOT part of the quoted- - string, comment or quoted character. A quotation-mark that is - to be part of a quoted-string, a parenthesis that is to be - part of a comment and a backslash that is to be part of either - must each be preceded by the quote-character backslash ("\"). - Note that the syntax allows any character to be quoted within - a quoted-string or comment; however only certain characters - MUST be quoted to be included as data. These characters are - the ones that are not part of the alternate text group (i.e., - ctext or qtext). - - The one exception to this rule is that a single SPACE is - assumed to exist between contiguous words in a phrase, and - this interpretation is independent of the actual number of - LWSP-chars that the creator places between the words. To - include more than one SPACE, the creator must make the LWSP- - chars be part of a quoted-string. - - Quotation marks that delimit a quoted string and backslashes - that quote the following character should NOT accompany the - quoted-string when the string is passed to processes that do - not interpret data according to this specification (e.g., mail - protocol servers). - - 3.4.5. QUOTED-STRINGS - - Where permitted (i.e., in words in structured fields) quoted- - strings are treated as a single symbol. That is, a quoted- - string is equivalent to an atom, syntactically. If a quoted- - string is to be "folded" onto multiple lines, then the syntax - for folding must be adhered to. (See the "Lexical Analysis of - - - August 13, 1982 - 13 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Messages" section on "Folding Long Header Fields" above, and - the section on "Case Independence" below.) Therefore, the - official semantics do not "see" any bare CRLFs that are in - quoted-strings; however particular parsing programs may wish - to note their presence. For such programs, it would be rea- - sonable to interpret a "CRLF LWSP-char" as being a CRLF which - is part of the quoted-string; i.e., the CRLF is kept and the - LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- - lowed by a CR followed by a LF) are also subject to rules of - folding, but the presence of the quoting character (backslash) - explicitly indicates that the CRLF is data to the quoted - string. Stripping off the first following LWSP-char is also - appropriate when parsing quoted CRLFs. - - 3.4.6. BRACKETING CHARACTERS - - There is one type of bracket which must occur in matched pairs - and may have pairs nested within each other: - - o Parentheses ("(" and ")") are used to indicate com- - ments. - - There are three types of brackets which must occur in matched - pairs, and which may NOT be nested: - - o Colon/semi-colon (":" and ";") are used in address - specifications to indicate that the included list of - addresses are to be treated as a group. - - o Angle brackets ("<" and ">") are generally used to - indicate the presence of a one machine-usable refer- - ence (e.g., delimiting mailboxes), possibly including - source-routing to the machine. - - o Square brackets ("[" and "]") are used to indicate the - presence of a domain-literal, which the appropriate - name-domain is to use directly, bypassing normal - name-resolution mechanisms. - - 3.4.7. CASE INDEPENDENCE - - Except as noted, alphabetic strings may be represented in any - combination of upper and lower case. The only syntactic units - - - - - - - - - August 13, 1982 - 14 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - which requires preservation of case information are: - - - text - - qtext - - dtext - - ctext - - quoted-pair - - local-part, except "Postmaster" - - When matching any other syntactic unit, case is to be ignored. - For example, the field-names "From", "FROM", "from", and even - "FroM" are semantically equal and should all be treated ident- - ically. - - When generating these units, any mix of upper and lower case - alphabetic characters may be used. The case shown in this - specification is suggested for message-creating processes. - - Note: The reserved local-part address unit, "Postmaster", is - an exception. When the value "Postmaster" is being - interpreted, it must be accepted in any mixture of - case, including "POSTMASTER", and "postmaster". - - 3.4.8. FOLDING LONG HEADER FIELDS - - Each header field may be represented on exactly one line con- - sisting of the name of the field and its body, and terminated - by a CRLF; this is what the parser sees. For readability, the - field-body portion of long header fields may be "folded" onto - multiple lines of the actual field. "Long" is commonly inter- - preted to mean greater than 65 or 72 characters. The former - length serves as a limit, when the message is to be viewed on - most simple terminals which use simple display software; how- - ever, the limit is not imposed by this standard. - - Note: Some display software often can selectively fold lines, - to suit the display terminal. In such cases, sender- - provided folding can interfere with the display - software. - - 3.4.9. BACKSPACE CHARACTERS - - ASCII BS characters (Backspace, decimal 8) may be included in - texts and quoted-strings to effect overstriking. However, any - use of backspaces which effects an overstrike to the left of - the beginning of the text or quoted-string is prohibited. - - - - - - August 13, 1982 - 15 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS - - During transmission through heterogeneous networks, it may be - necessary to force data to conform to a network's local con- - ventions. For example, it may be required that a CR be fol- - lowed either by LF, making a CRLF, or by <null>, if the CR is - to stand alone). Such transformations are reversed, when the - message exits that network. - - When crossing network boundaries, the message should be - treated as passing through two modules. It will enter the - first module containing whatever network-specific transforma- - tions that were necessary to permit migration through the - "current" network. It then passes through the modules: - - o Transformation Reversal - - The "current" network's idiosyncracies are removed and - the message is returned to the canonical form speci- - fied in this standard. - - o Transformation - - The "next" network's local idiosyncracies are imposed - on the message. - - ------------------ - From ==> | Remove Net-A | - Net-A | idiosyncracies | - ------------------ - || - \/ - Conformance - with standard - || - \/ - ------------------ - | Impose Net-B | ==> To - | idiosyncracies | Net-B - ------------------ - - - - - - - - - - - - August 13, 1982 - 16 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 4. MESSAGE SPECIFICATION - - 4.1. SYNTAX - - Note: Due to an artifact of the notational conventions, the syn- - tax indicates that, when present, some fields, must be in - a particular order. Header fields are NOT required to - occur in any particular order, except that the message - body must occur AFTER the headers. It is recommended - that, if present, headers be sent in the order "Return- - Path", "Received", "Date", "From", "Subject", "Sender", - "To", "cc", etc. - - This specification permits multiple occurrences of most - fields. Except as noted, their interpretation is not - specified here, and their use is discouraged. - - The following syntax for the bodies of various fields should - be thought of as describing each field body as a single long - string (or line). The "Lexical Analysis of Message" section on - "Long Header Fields", above, indicates how such long strings can - be represented on more than one line in the actual transmitted - message. - - message = fields *( CRLF *text ) ; Everything after - ; first null line - ; is message body - - fields = dates ; Creation time, - source ; author id & one - 1*destination ; address required - *optional-field ; others optional - - source = [ trace ] ; net traversals - originator ; original mail - [ resent ] ; forwarded - - trace = return ; path to sender - 1*received ; receipt tags - - return = "Return-path" ":" route-addr ; return address - - received = "Received" ":" ; one per relay - ["from" domain] ; sending host - ["by" domain] ; receiving host - ["via" atom] ; physical path - *("with" atom) ; link/mail protocol - ["id" msg-id] ; receiver msg id - ["for" addr-spec] ; initial form - - - August 13, 1982 - 17 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - ";" date-time ; time received - - originator = authentic ; authenticated addr - [ "Reply-To" ":" 1#address] ) - - authentic = "From" ":" mailbox ; Single author - / ( "Sender" ":" mailbox ; Actual submittor - "From" ":" 1#mailbox) ; Multiple authors - ; or not sender - - resent = resent-authentic - [ "Resent-Reply-To" ":" 1#address] ) - - resent-authentic = - = "Resent-From" ":" mailbox - / ( "Resent-Sender" ":" mailbox - "Resent-From" ":" 1#mailbox ) - - dates = orig-date ; Original - [ resent-date ] ; Forwarded - - orig-date = "Date" ":" date-time - - resent-date = "Resent-Date" ":" date-time - - destination = "To" ":" 1#address ; Primary - / "Resent-To" ":" 1#address - / "cc" ":" 1#address ; Secondary - / "Resent-cc" ":" 1#address - / "bcc" ":" #address ; Blind carbon - / "Resent-bcc" ":" #address - - optional-field = - / "Message-ID" ":" msg-id - / "Resent-Message-ID" ":" msg-id - / "In-Reply-To" ":" *(phrase / msg-id) - / "References" ":" *(phrase / msg-id) - / "Keywords" ":" #phrase - / "Subject" ":" *text - / "Comments" ":" *text - / "Encrypted" ":" 1#2word - / extension-field ; To be defined - / user-defined-field ; May be pre-empted - - msg-id = "<" addr-spec ">" ; Unique message id - - - - - - - August 13, 1982 - 18 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - extension-field = - <Any field which is defined in a document - published as a formal extension to this - specification; none will have names beginning - with the string "X-"> - - user-defined-field = - <Any field which has not been defined - in this specification or published as an - extension to this specification; names for - such fields must be unique and may be - pre-empted by published extensions> - - 4.2. FORWARDING - - Some systems permit mail recipients to forward a message, - retaining the original headers, by adding some new fields. This - standard supports such a service, through the "Resent-" prefix to - field names. - - Whenever the string "Resent-" begins a field name, the field - has the same semantics as a field whose name does not have the - prefix. However, the message is assumed to have been forwarded - by an original recipient who attached the "Resent-" field. This - new field is treated as being more recent than the equivalent, - original field. For example, the "Resent-From", indicates the - person that forwarded the message, whereas the "From" field indi- - cates the original author. - - Use of such precedence information depends upon partici- - pants' communication needs. For example, this standard does not - dictate when a "Resent-From:" address should receive replies, in - lieu of sending them to the "From:" address. - - Note: In general, the "Resent-" fields should be treated as con- - taining a set of information that is independent of the - set of original fields. Information for one set should - not automatically be taken from the other. The interpre- - tation of multiple "Resent-" fields, of the same type, is - undefined. - - In the remainder of this specification, occurrence of legal - "Resent-" fields are treated identically with the occurrence of - - - - - - - - - August 13, 1982 - 19 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - fields whose names do not contain this prefix. - - 4.3. TRACE FIELDS - - Trace information is used to provide an audit trail of mes- - sage handling. In addition, it indicates a route back to the - sender of the message. - - The list of known "via" and "with" values are registered - with the Network Information Center, SRI International, Menlo - Park, California. - - 4.3.1. RETURN-PATH - - This field is added by the final transport system that - delivers the message to its recipient. The field is intended - to contain definitive information about the address and route - back to the message's originator. - - Note: The "Reply-To" field is added by the originator and - serves to direct replies, whereas the "Return-Path" - field is used to identify a path back to the origina- - tor. - - While the syntax indicates that a route specification is - optional, every attempt should be made to provide that infor- - mation in this field. - - 4.3.2. RECEIVED - - A copy of this field is added by each transport service that - relays the message. The information in the field can be quite - useful for tracing transport problems. - - The names of the sending and receiving hosts and time-of- - receipt may be specified. The "via" parameter may be used, to - indicate what physical mechanism the message was sent over, - such as Arpanet or Phonenet, and the "with" parameter may be - used to indicate the mail-, or connection-, level protocol - that was used, such as the SMTP mail protocol, or X.25 tran- - sport protocol. - - Note: Several "with" parameters may be included, to fully - specify the set of protocols that were used. - - Some transport services queue mail; the internal message iden- - tifier that is assigned to the message may be noted, using the - "id" parameter. When the sending host uses a destination - address specification that the receiving host reinterprets, by - - - August 13, 1982 - 20 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - expansion or transformation, the receiving host may wish to - record the original specification, using the "for" parameter. - For example, when a copy of mail is sent to the member of a - distribution list, this parameter may be used to record the - original address that was used to specify the list. - - 4.4. ORIGINATOR FIELDS - - The standard allows only a subset of the combinations possi- - ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, - and Resent-Reply-To fields. The limitation is intentional. - - 4.4.1. FROM / RESENT-FROM - - This field contains the identity of the person(s) who wished - this message to be sent. The message-creation process should - default this field to be a single, authenticated machine - address, indicating the AGENT (person, system or process) - entering the message. If this is not done, the "Sender" field - MUST be present. If the "From" field IS defaulted this way, - the "Sender" field is optional and is redundant with the - "From" field. In all cases, addresses in the "From" field - must be machine-usable (addr-specs) and may not contain named - lists (groups). - - 4.4.2. SENDER / RESENT-SENDER - - This field contains the authenticated identity of the AGENT - (person, system or process) that sends the message. It is - intended for use when the sender is not the author of the mes- - sage, or to indicate who among a group of authors actually - sent the message. If the contents of the "Sender" field would - be completely redundant with the "From" field, then the - "Sender" field need not be present and its use is discouraged - (though still legal). In particular, the "Sender" field MUST - be present if it is NOT the same as the "From" Field. - - The Sender mailbox specification includes a word sequence - which must correspond to a specific agent (i.e., a human user - or a computer program) rather than a standard address. This - indicates the expectation that the field will identify the - single AGENT (person, system, or process) responsible for - sending the mail and not simply include the name of a mailbox - from which the mail was sent. For example in the case of a - shared login name, the name, by itself, would not be adequate. - The local-part address unit, which refers to this agent, is - expected to be a computer system term, and not (for example) a - generalized person reference which can be used outside the - network text message context. - - - August 13, 1982 - 21 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Since the critical function served by the "Sender" field is - identification of the agent responsible for sending mail and - since computer programs cannot be held accountable for their - behavior, it is strongly recommended that when a computer pro- - gram generates a message, the HUMAN who is responsible for - that program be referenced as part of the "Sender" field mail- - box specification. - - 4.4.3. REPLY-TO / RESENT-REPLY-TO - - This field provides a general mechanism for indicating any - mailbox(es) to which responses are to be sent. Three typical - uses for this feature can be distinguished. In the first - case, the author(s) may not have regular machine-based mail- - boxes and therefore wish(es) to indicate an alternate machine - address. In the second case, an author may wish additional - persons to be made aware of, or responsible for, replies. A - somewhat different use may be of some help to "text message - teleconferencing" groups equipped with automatic distribution - services: include the address of that service in the "Reply- - To" field of all messages submitted to the teleconference; - then participants can "reply" to conference submissions to - guarantee the correct distribution of any submission of their - own. - - Note: The "Return-Path" field is added by the mail transport - service, at the time of final deliver. It is intended - to identify a path back to the orginator of the mes- - sage. The "Reply-To" field is added by the message - originator and is intended to direct replies. - - 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO - - For systems which automatically generate address lists for - replies to messages, the following recommendations are made: - - o The "Sender" field mailbox should be sent notices of - any problems in transport or delivery of the original - messages. If there is no "Sender" field, then the - "From" field mailbox should be used. - - o The "Sender" field mailbox should NEVER be used - automatically, in a recipient's reply message. - - o If the "Reply-To" field exists, then the reply should - go to the addresses indicated in that field and not to - the address(es) indicated in the "From" field. - - - - - August 13, 1982 - 22 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - o If there is a "From" field, but no "Reply-To" field, - the reply should be sent to the address(es) indicated - in the "From" field. - - Sometimes, a recipient may actually wish to communicate with - the person that initiated the message transfer. In such - cases, it is reasonable to use the "Sender" address. - - This recommendation is intended only for automated use of - originator-fields and is not intended to suggest that replies - may not also be sent to other recipients of messages. It is - up to the respective mail-handling programs to decide what - additional facilities will be provided. - - Examples are provided in Appendix A. - - 4.5. RECEIVER FIELDS - - 4.5.1. TO / RESENT-TO - - This field contains the identity of the primary recipients of - the message. - - 4.5.2. CC / RESENT-CC - - This field contains the identity of the secondary (informa- - tional) recipients of the message. - - 4.5.3. BCC / RESENT-BCC - - This field contains the identity of additional recipients of - the message. The contents of this field are not included in - copies of the message sent to the primary and secondary reci- - pients. Some systems may choose to include the text of the - "Bcc" field only in the author(s)'s copy, while others may - also include it in the text sent to all those indicated in the - "Bcc" list. - - 4.6. REFERENCE FIELDS - - 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID - - This field contains a unique identifier (the local-part - address unit) which refers to THIS version of THIS message. - The uniqueness of the message identifier is guaranteed by the - host which generates it. This identifier is intended to be - machine readable and not necessarily meaningful to humans. A - message identifier pertains to exactly one instantiation of a - particular message; subsequent revisions to the message should - - - August 13, 1982 - 23 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - each receive new message identifiers. - - 4.6.2. IN-REPLY-TO - - The contents of this field identify previous correspon- - dence which this message answers. Note that if message iden- - tifiers are used in this field, they must use the msg-id - specification format. - - 4.6.3. REFERENCES - - The contents of this field identify other correspondence - which this message references. Note that if message identif- - iers are used, they must use the msg-id specification format. - - 4.6.4. KEYWORDS - - This field contains keywords or phrases, separated by - commas. - - 4.7. OTHER FIELDS - - 4.7.1. SUBJECT - - This is intended to provide a summary, or indicate the - nature, of the message. - - 4.7.2. COMMENTS - - Permits adding text comments onto the message without - disturbing the contents of the message's body. - - 4.7.3. ENCRYPTED - - Sometimes, data encryption is used to increase the - privacy of message contents. If the body of a message has - been encrypted, to keep its contents private, the "Encrypted" - field can be used to note the fact and to indicate the nature - of the encryption. The first <word> parameter indicates the - software used to encrypt the body, and the second, optional - <word> is intended to aid the recipient in selecting the - proper decryption key. This code word may be viewed as an - index to a table of keys held by the recipient. - - Note: Unfortunately, headers must contain envelope, as well - as contents, information. Consequently, it is neces- - sary that they remain unencrypted, so that mail tran- - sport services may access them. Since names, - addresses, and "Subject" field contents may contain - - - August 13, 1982 - 24 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - sensitive information, this requirement limits total - message privacy. - - Names of encryption software are registered with the Net- - work Information Center, SRI International, Menlo Park, Cali- - fornia. - - 4.7.4. EXTENSION-FIELD - - A limited number of common fields have been defined in - this document. As network mail requirements dictate, addi- - tional fields may be standardized. To provide user-defined - fields with a measure of safety, in name selection, such - extension-fields will never have names that begin with the - string "X-". - - Names of Extension-fields are registered with the Network - Information Center, SRI International, Menlo Park, California. - - 4.7.5. USER-DEFINED-FIELD - - Individual users of network mail are free to define and - use additional header fields. Such fields must have names - which are not already used in the current specification or in - any definitions of extension-fields, and the overall syntax of - these user-defined-fields must conform to this specification's - rules for delimiting and folding fields. Due to the - extension-field publishing process, the name of a user- - defined-field may be pre-empted - - Note: The prefatory string "X-" will never be used in the - names of Extension-fields. This provides user-defined - fields with a protected set of names. - - - - - - - - - - - - - - - - - - - August 13, 1982 - 25 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 5. DATE AND TIME SPECIFICATION - - 5.1. SYNTAX - - date-time = [ day "," ] date time ; dd mm yy - ; hh:mm:ss zzz - - day = "Mon" / "Tue" / "Wed" / "Thu" - / "Fri" / "Sat" / "Sun" - - date = 1*2DIGIT month 2DIGIT ; day month year - ; e.g. 20 Jun 82 - - month = "Jan" / "Feb" / "Mar" / "Apr" - / "May" / "Jun" / "Jul" / "Aug" - / "Sep" / "Oct" / "Nov" / "Dec" - - time = hour zone ; ANSI and Military - - hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] - ; 00:00:00 - 23:59:59 - - zone = "UT" / "GMT" ; Universal Time - ; North American : UT - / "EST" / "EDT" ; Eastern: - 5/ - 4 - / "CST" / "CDT" ; Central: - 6/ - 5 - / "MST" / "MDT" ; Mountain: - 7/ - 6 - / "PST" / "PDT" ; Pacific: - 8/ - 7 - / 1ALPHA ; Military: Z = UT; - ; A:-1; (J not used) - ; M:-12; N:+1; Y:+12 - / ( ("+" / "-") 4DIGIT ) ; Local differential - ; hours+min. (HHMM) - - 5.2. SEMANTICS - - If included, day-of-week must be the day implied by the date - specification. - - Time zone may be indicated in several ways. "UT" is Univer- - sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- - mitted as a reference to Universal Time. The military standard - uses a single character for each zone. "Z" is Universal Time. - "A" indicates one hour earlier, and "M" indicates 12 hours ear- - lier; "N" is one hour later, and "Y" is 12 hours later. The - letter "J" is not used. The other remaining two forms are taken - from ANSI standard X3.51-1975. One allows explicit indication of - the amount of offset from UT; the other uses common 3-character - strings for indicating time zones in North America. - - - August 13, 1982 - 26 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 6. ADDRESS SPECIFICATION - - 6.1. SYNTAX - - address = mailbox ; one addressee - / group ; named list - - group = phrase ":" [#mailbox] ";" - - mailbox = addr-spec ; simple address - / phrase route-addr ; name & addr-spec - - route-addr = "<" [route] addr-spec ">" - - route = 1#("@" domain) ":" ; path-relative - - addr-spec = local-part "@" domain ; global address - - local-part = word *("." word) ; uninterpreted - ; case-preserved - - domain = sub-domain *("." sub-domain) - - sub-domain = domain-ref / domain-literal - - domain-ref = atom ; symbolic reference - - 6.2. SEMANTICS - - A mailbox receives mail. It is a conceptual entity which - does not necessarily pertain to file storage. For example, some - sites may choose to print mail on their line printer and deliver - the output to the addressee's desk. - - A mailbox specification comprises a person, system or pro- - cess name reference, a domain-dependent string, and a name-domain - reference. The name reference is optional and is usually used to - indicate the human name of a recipient. The name-domain refer- - ence specifies a sequence of sub-domains. The domain-dependent - string is uninterpreted, except by the final sub-domain; the rest - of the mail service merely transmits it as a literal string. - - 6.2.1. DOMAINS - - A name-domain is a set of registered (mail) names. A name- - domain specification resolves to a subordinate name-domain - specification or to a terminal domain-dependent string. - Hence, domain specification is extensible, permitting any - number of registration levels. - - - August 13, 1982 - 27 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - Name-domains model a global, logical, hierarchical addressing - scheme. The model is logical, in that an address specifica- - tion is related to name registration and is not necessarily - tied to transmission path. The model's hierarchy is a - directed graph, called an in-tree, such that there is a single - path from the root of the tree to any node in the hierarchy. - If more than one path actually exists, they are considered to - be different addresses. - - The root node is common to all addresses; consequently, it is - not referenced. Its children constitute "top-level" name- - domains. Usually, a service has access to its own full domain - specification and to the names of all top-level name-domains. - - The "top" of the domain addressing hierarchy -- a child of the - root -- is indicated by the right-most field, in a domain - specification. Its child is specified to the left, its child - to the left, and so on. - - Some groups provide formal registration services; these con- - stitute name-domains that are independent logically of - specific machines. In addition, networks and machines impli- - citly compose name-domains, since their membership usually is - registered in name tables. - - In the case of formal registration, an organization implements - a (distributed) data base which provides an address-to-route - mapping service for addresses of the form: - - person@registry.organization - - Note that "organization" is a logical entity, separate from - any particular communication network. - - A mechanism for accessing "organization" is universally avail- - able. That mechanism, in turn, seeks an instantiation of the - registry; its location is not indicated in the address specif- - ication. It is assumed that the system which operates under - the name "organization" knows how to find a subordinate regis- - try. The registry will then use the "person" string to deter- - mine where to send the mail specification. - - The latter, network-oriented case permits simple, direct, - attachment-related address specification, such as: - - user@host.network - - Once the network is accessed, it is expected that a message - will go directly to the host and that the host will resolve - - - August 13, 1982 - 28 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - the user name, placing the message in the user's mailbox. - - 6.2.2. ABBREVIATED DOMAIN SPECIFICATION - - Since any number of levels is possible within the domain - hierarchy, specification of a fully qualified address can - become inconvenient. This standard permits abbreviated domain - specification, in a special case: - - For the address of the sender, call the left-most - sub-domain Level N. In a header address, if all of - the sub-domains above (i.e., to the right of) Level N - are the same as those of the sender, then they do not - have to appear in the specification. Otherwise, the - address must be fully qualified. - - This feature is subject to approval by local sub- - domains. Individual sub-domains may require their - member systems, which originate mail, to provide full - domain specification only. When permitted, abbrevia- - tions may be present only while the message stays - within the sub-domain of the sender. - - Use of this mechanism requires the sender's sub-domain - to reserve the names of all top-level domains, so that - full specifications can be distinguished from abbrevi- - ated specifications. - - For example, if a sender's address is: - - sender@registry-A.registry-1.organization-X - - and one recipient's address is: - - recipient@registry-B.registry-1.organization-X - - and another's is: - - recipient@registry-C.registry-2.organization-X - - then ".registry-1.organization-X" need not be specified in the - the message, but "registry-C.registry-2" DOES have to be - specified. That is, the first two addresses may be abbrevi- - ated, but the third address must be fully specified. - - When a message crosses a domain boundary, all addresses must - be specified in the full format, ending with the top-level - name-domain in the right-most field. It is the responsibility - of mail forwarding services to ensure that addresses conform - - - August 13, 1982 - 29 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - with this requirement. In the case of abbreviated addresses, - the relaying service must make the necessary expansions. It - should be noted that it often is difficult for such a service - to locate all occurrences of address abbreviations. For exam- - ple, it will not be possible to find such abbreviations within - the body of the message. The "Return-Path" field can aid - recipients in recovering from these errors. - - Note: When passing any portion of an addr-spec onto a process - which does not interpret data according to this stan- - dard (e.g., mail protocol servers). There must be NO - LWSP-chars preceding or following the at-sign or any - delimiting period ("."), such as shown in the above - examples, and only ONE SPACE between contiguous - <word>s. - - 6.2.3. DOMAIN TERMS - - A domain-ref must be THE official name of a registry, network, - or host. It is a symbolic reference, within a name sub- - domain. At times, it is necessary to bypass standard mechan- - isms for resolving such references, using more primitive - information, such as a network host address rather than its - associated host name. - - To permit such references, this standard provides the domain- - literal construct. Its contents must conform with the needs - of the sub-domain in which it is interpreted. - - Domain-literals which refer to domains within the ARPA Inter- - net specify 32-bit Internet addresses, in four 8-bit fields - noted in decimal, as described in Request for Comments #820, - "Assigned Numbers." For example: - - [10.0.3.19] - - Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It - is permitted only as a means of bypassing temporary - system limitations, such as name tables which are not - complete. - - The names of "top-level" domains, and the names of domains - under in the ARPA Internet, are registered with the Network - Information Center, SRI International, Menlo Park, California. - - 6.2.4. DOMAIN-DEPENDENT LOCAL STRING - - The local-part of an addr-spec in a mailbox specification - (i.e., the host's name for the mailbox) is understood to be - - - August 13, 1982 - 30 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - whatever the receiving mail protocol server allows. For exam- - ple, some systems do not understand mailbox references of the - form "P. D. Q. Bach", but others do. - - This specification treats periods (".") as lexical separators. - Hence, their presence in local-parts which are not quoted- - strings, is detected. However, such occurrences carry NO - semantics. That is, if a local-part has periods within it, an - address parser will divide the local-part into several tokens, - but the sequence of tokens will be treated as one uninter- - preted unit. The sequence will be re-assembled, when the - address is passed outside of the system such as to a mail pro- - tocol service. - - For example, the address: - - First.Last@Registry.Org - - is legal and does not require the local-part to be surrounded - with quotation-marks. (However, "First Last" DOES require - quoting.) The local-part of the address, when passed outside - of the mail system, within the Registry.Org domain, is - "First.Last", again without quotation marks. - - 6.2.5. BALANCING LOCAL-PART AND DOMAIN - - In some cases, the boundary between local-part and domain can - be flexible. The local-part may be a simple string, which is - used for the final determination of the recipient's mailbox. - All other levels of reference are, therefore, part of the - domain. - - For some systems, in the case of abbreviated reference to the - local and subordinate sub-domains, it may be possible to - specify only one reference within the domain part and place - the other, subordinate name-domain references within the - local-part. This would appear as: - - mailbox.sub1.sub2@this-domain - - Such a specification would be acceptable to address parsers - which conform to RFC #733, but do not support this newer - Internet standard. While contrary to the intent of this stan- - dard, the form is legal. - - Also, some sub-domains have a specification syntax which does - not conform to this standard. For example: - - sub-net.mailbox@sub-domain.domain - - - August 13, 1982 - 31 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - uses a different parsing sequence for local-part than for - domain. - - Note: As a rule, the domain specification should contain - fields which are encoded according to the syntax of - this standard and which contain generally-standardized - information. The local-part specification should con- - tain only that portion of the address which deviates - from the form or intention of the domain field. - - 6.2.6. MULTIPLE MAILBOXES - - An individual may have several mailboxes and wish to receive - mail at whatever mailbox is convenient for the sender to - access. This standard does not provide a means of specifying - "any member of" a list of mailboxes. - - A set of individuals may wish to receive mail as a single unit - (i.e., a distribution list). The <group> construct permits - specification of such a list. Recipient mailboxes are speci- - fied within the bracketed part (":" - ";"). A copy of the - transmitted message is to be sent to each mailbox listed. - This standard does not permit recursive specification of - groups within groups. - - While a list must be named, it is not required that the con- - tents of the list be included. In this case, the <address> - serves only as an indication of group distribution and would - appear in the form: - - name:; - - Some mail services may provide a group-list distribution - facility, accepting a single mailbox reference, expanding it - to the full distribution list, and relaying the mail to the - list's members. This standard provides no additional syntax - for indicating such a service. Using the <group> address - alternative, while listing one mailbox in it, can mean either - that the mailbox reference will be expanded to a list or that - there is a group with one member. - - 6.2.7. EXPLICIT PATH SPECIFICATION - - At times, a message originator may wish to indicate the - transmission path that a message should follow. This is - called source routing. The normal addressing scheme, used in - an addr-spec, is carefully separated from such information; - the <route> portion of a route-addr is provided for such occa- - sions. It specifies the sequence of hosts and/or transmission - - - August 13, 1982 - 32 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - services that are to be traversed. Both domain-refs and - domain-literals may be used. - - Note: The use of source routing is discouraged. Unless the - sender has special need of path restriction, the choice - of transmission route should be left to the mail tran- - sport service. - - 6.3. RESERVED ADDRESS - - It often is necessary to send mail to a site, without know- - ing any of its valid addresses. For example, there may be mail - system dysfunctions, or a user may wish to find out a person's - correct address, at that site. - - This standard specifies a single, reserved mailbox address - (local-part) which is to be valid at each site. Mail sent to - that address is to be routed to a person responsible for the - site's mail system or to a person with responsibility for general - site operation. The name of the reserved local-part address is: - - Postmaster - - so that "Postmaster@domain" is required to be valid. - - Note: This reserved local-part must be matched without sensi- - tivity to alphabetic case, so that "POSTMASTER", "postmas- - ter", and even "poStmASteR" is to be accepted. - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 33 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - 7. BIBLIOGRAPHY - - - ANSI. "USA Standard Code for Information Interchange," X3.4. - American National Standards Institute: New York (1968). Also - in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- - book", NIC 7104. - - ANSI. "Representations of Universal Time, Local Time Differen- - tials, and United States Time Zone References for Information - Interchange," X3.51-1975. American National Standards Insti- - tute: New York (1975). - - Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. - 1979). - - Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- - ford and Appleton Laboratory: Didcot, England. - - Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. - "Standardizing Network Mail Headers," ARPANET Request for - Comments No. 561, Network Information Center No. 18516; SRI - International: Menlo Park (September 1973). - - Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. - "Grapevine: An Exercise in Distributed Computing," Communica- - tions of the ACM 25, 4 (April 1982), 260-274. - - Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. - "Standard for the Format of ARPA Network Text Message," - ARPANET Request for Comments No. 733, Network Information - Center No. 41952. SRI International: Menlo Park (November - 1977). - - Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- - work Information Center No. 7104 (NTIS AD A003890). SRI - International: Menlo Park (April 1976). - - Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. - (1969). - - Levin, R. and Schroeder, M. "Transport of Electronic Messages - through a Network," TeleInformatics 79, pp. 29-33. North - Holland (1979). Also as Xerox Palo Alto Research Center - Technical Report CSL-79-4. - - Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," - ARPANET Request for Comments, No. 680, Network Information - Center No. 32116. SRI International: Menlo Park (1975). - - - August 13, 1982 - 34 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - NBS. "Specification of Message Format for Computer Based Message - Systems, Recommended Federal Information Processing Standard." - National Bureau of Standards: Gaithersburg, Maryland - (October 1981). - - NIC. Internet Protocol Transition Workbook. Network Information - Center, SRI-International, Menlo Park, California (March - 1982). - - Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized - Agent for Locating Named Objects in a Distributed Environ- - ment," OPD-T8103. Xerox Office Products Division: Palo Alto, - CA. (October 1981). - - Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, - No. 820. SRI International: Menlo Park (August 1982). - - Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request - for Comments, No. 821. SRI International: Menlo Park (August - 1982). - - Shoch, J.F. "Internetwork naming, addressing and routing," in - Proc. 17th IEEE Computer Society International Conference, pp. - 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. - - Su, Z. and Postel, J. "The Domain Naming Convention for Internet - User Applications," ARPANET Request for Comments, No. 819. - SRI International: Menlo Park (August 1982). - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 35 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - APPENDIX - - - A. EXAMPLES - - A.1. ADDRESSES - - A.1.1. Alfred Neuman <Neuman@BBN-TENEXA> - - A.1.2. Neuman@BBN-TENEXA - - These two "Alfred Neuman" examples have identical seman- - tics, as far as the operation of the local host's mail sending - (distribution) program (also sometimes called its "mailer") - and the remote host's mail protocol server are concerned. In - the first example, the "Alfred Neuman" is ignored by the - mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- - pient. The second example contains no superfluous informa- - tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- - pient. - - Note: When the message crosses name-domain boundaries, then - these specifications must be changed, so as to indicate - the remainder of the hierarchy, starting with the top - level. - - A.1.3. "George, Ted" <Shared@Group.Arpanet> - - This form might be used to indicate that a single mailbox - is shared by several users. The quoted string is ignored by - the originating host's mailer, because "Shared@Group.Arpanet" - completely specifies the destination mailbox. - - A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US - - The "(the Stilt)" is a comment, which is NOT included in - the destination mailbox address handed to the originating - system's mailer. The local-part of the address is the string - "Wilt.Chamberlain", with NO space between the first and second - words. - - A.1.5. Address Lists - - Gourmets: Pompous Person <WhoZiWhatZit@Cordon-Bleu>, - Childs@WGBH.Boston, Galloping Gourmet@ - ANT.Down-Under (Australian National Television), - Cheapie@Discount-Liquors;, - Cruisers: Port@Portugal, Jones@SEA;, - Another@Somewhere.SomeOrg - - - August 13, 1982 - 36 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - This group list example points out the use of comments and the - mixing of addresses and groups. - - A.2. ORIGINATOR ITEMS - - A.2.1. Author-sent - - George Jones logs into his host as "Jones". He sends - mail himself. - - From: Jones@Group.Org - - or - - From: George Jones <Jones@Group.Org> - - A.2.2. Secretary-sent - - George Jones logs in as Jones on his host. His secre- - tary, who logs in as Secy sends mail for him. Replies to the - mail should go to George. - - From: George Jones <Jones@Group> - Sender: Secy@Other-Group - - A.2.3. Secretary-sent, for user of shared directory - - George Jones' secretary sends mail for George. Replies - should go to George. - - From: George Jones<Shared@Group.Org> - Sender: Secy@Other-Group - - Note that there need not be a space between "Jones" and the - "<", but adding a space enhances readability (as is the case - in other examples. - - A.2.4. Committee activity, with one author - - George is a member of a committee. He wishes to have any - replies to his message go to all committee members. - - From: George Jones <Jones@Host.Net> - Sender: Jones@Host - Reply-To: The Committee: Jones@Host.Net, - Smith@Other.Org, - Doe@Somewhere-Else; - - Note that if George had not included himself in the - - - August 13, 1982 - 37 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - enumeration of The Committee, he would not have gotten an - implicit reply; the presence of the "Reply-to" field SUPER- - SEDES the sending of a reply to the person named in the "From" - field. - - A.2.5. Secretary acting as full agent of author - - George Jones asks his secretary (Secy@Host) to send a - message for him in his capacity as Group. He wants his secre- - tary to handle all replies. - - From: George Jones <Group@Host> - Sender: Secy@Host - Reply-To: Secy@Host - - A.2.6. Agent for user without online mailbox - - A friend of George's, Sarah, is visiting. George's - secretary sends some mail to a friend of Sarah in computer- - land. Replies should go to George, whose mailbox is Jones at - Registry. - - From: Sarah Friendly <Secy@Registry> - Sender: Secy-Name <Secy@Registry> - Reply-To: Jones@Registry. - - A.2.7. Agent for member of a committee - - George's secretary sends out a message which was authored - jointly by all the members of a committee. Note that the name - of the committee cannot be specified, since <group> names are - not permitted in the From field. - - From: Jones@Host, - Smith@Other-Host, - Doe@Somewhere-Else - Sender: Secy@SHost - - - - - - - - - - - - - - - August 13, 1982 - 38 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - A.3. COMPLETE HEADERS - - A.3.1. Minimum required - - Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT - From: Jones@Registry.Org or From: Jones@Registry.Org - Bcc: To: Smith@Registry.Org - - Note that the "Bcc" field may be empty, while the "To" field - is required to have at least one address. - - A.3.2. Using some of the additional fields - - Date: 26 Aug 76 1430 EDT - From: George Jones<Group@Host> - Sender: Secy@SHOST - To: "Al Neuman"@Mad-Host, - Sam.Irving@Other-Host - Message-ID: <some.string@SHOST> - - A.3.3. About as complex as you're going to get - - Date : 27 Aug 76 0932 PDT - From : Ken Davis <KDavis@This-Host.This-net> - Subject : Re: The Syntax in the RFC - Sender : KSecy@Other-Host - Reply-To : Sam.Irving@Reg.Organization - To : George Jones <Group@Some-Reg.An-Org>, - Al.Neuman@MAD.Publisher - cc : Important folk: - Tom Softwood <Balsa@Tree.Root>, - "Sam Irving"@Other-Host;, - Standard Distribution: - /main/davis/people/standard@Other-Host, - "<Jones>standard.dist.3"@Tops-20-Host>; - Comment : Sam is away on business. He asked me to handle - his mail for him. He'll be able to provide a - more accurate explanation when he returns - next week. - In-Reply-To: <some.string@DBM.Group>, George's message - X-Special-action: This is a sample of user-defined field- - names. There could also be a field-name - "Special-action", but its name might later be - preempted - Message-ID: <4231.629.XYzi-What@Other-Host> - - - - - - - August 13, 1982 - 39 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - B. SIMPLE FIELD PARSING - - Some mail-reading software systems may wish to perform only - minimal processing, ignoring the internal syntax of structured - field-bodies and treating them the same as unstructured-field- - bodies. Such software will need only to distinguish: - - o Header fields from the message body, - - o Beginnings of fields from lines which continue fields, - - o Field-names from field-contents. - - The abbreviated set of syntactic rules which follows will - suffice for this purpose. It describes a limited view of mes- - sages and is a subset of the syntactic rules provided in the main - part of this specification. One small exception is that the con- - tents of field-bodies consist only of text: - - B.1. SYNTAX - - - message = *field *(CRLF *text) - - field = field-name ":" [field-body] CRLF - - field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> - - field-body = *text [CRLF LWSP-char field-body] - - - B.2. SEMANTICS - - Headers occur before the message body and are terminated by - a null line (i.e., two contiguous CRLFs). - - A line which continues a header field begins with a SPACE or - HTAB character, while a line beginning a field starts with a - printable character which is not a colon. - - A field-name consists of one or more printable characters - (excluding colon, space, and control-characters). A field-name - MUST be contained on one line. Upper and lower case are not dis- - tinguished when comparing field-names. - - - - - - - - August 13, 1982 - 40 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C. DIFFERENCES FROM RFC #733 - - The following summarizes the differences between this stan- - dard and the one specified in Arpanet Request for Comments #733, - "Standard for the Format of ARPA Network Text Messages". The - differences are listed in the order of their occurrence in the - current specification. - - C.1. FIELD DEFINITIONS - - C.1.1. FIELD NAMES - - These now must be a sequence of printable characters. They - may not contain any LWSP-chars. - - C.2. LEXICAL TOKENS - - C.2.1. SPECIALS - - The characters period ("."), left-square bracket ("["), and - right-square bracket ("]") have been added. For presentation - purposes, and when passing a specification to a system that - does not conform to this standard, periods are to be contigu- - ous with their surrounding lexical tokens. No linear-white- - space is permitted between them. The presence of one LWSP- - char between other tokens is still directed. - - C.2.2. ATOM - - Atoms may not contain SPACE. - - C.2.3. SPECIAL TEXT - - ctext and qtext have had backslash ("\") added to the list of - prohibited characters. - - C.2.4. DOMAINS - - The lexical tokens <domain-literal> and <dtext> have been - added. - - C.3. MESSAGE SPECIFICATION - - C.3.1. TRACE - - The "Return-path:" and "Received:" fields have been specified. - - - - - - August 13, 1982 - 41 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C.3.2. FROM - - The "From" field must contain machine-usable addresses (addr- - spec). Multiple addresses may be specified, but named-lists - (groups) may not. - - C.3.3. RESENT - - The meta-construct of prefacing field names with the string - "Resent-" has been added, to indicate that a message has been - forwarded by an intermediate recipient. - - C.3.4. DESTINATION - - A message must contain at least one destination address field. - "To" and "CC" are required to contain at least one address. - - C.3.5. IN-REPLY-TO - - The field-body is no longer a comma-separated list, although a - sequence is still permitted. - - C.3.6. REFERENCE - - The field-body is no longer a comma-separated list, although a - sequence is still permitted. - - C.3.7. ENCRYPTED - - A field has been specified that permits senders to indicate - that the body of a message has been encrypted. - - C.3.8. EXTENSION-FIELD - - Extension fields are prohibited from beginning with the char- - acters "X-". - - C.4. DATE AND TIME SPECIFICATION - - C.4.1. SIMPLIFICATION - - Fewer optional forms are permitted and the list of three- - letter time zones has been shortened. - - C.5. ADDRESS SPECIFICATION - - - - - - - August 13, 1982 - 42 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - C.5.1. ADDRESS - - The use of quoted-string, and the ":"-atom-":" construct, have - been removed. An address now is either a single mailbox - reference or is a named list of addresses. The latter indi- - cates a group distribution. - - C.5.2. GROUPS - - Group lists are now required to to have a name. Group lists - may not be nested. - - C.5.3. MAILBOX - - A mailbox specification may indicate a person's name, as - before. Such a named list no longer may specify multiple - mailboxes and may not be nested. - - C.5.4. ROUTE ADDRESSING - - Addresses now are taken to be absolute, global specifications, - independent of transmission paths. The <route> construct has - been provided, to permit explicit specification of transmis- - sion path. RFC #733's use of multiple at-signs ("@") was - intended as a general syntax for indicating routing and/or - hierarchical addressing. The current standard separates these - specifications and only one at-sign is permitted. - - C.5.5. AT-SIGN - - The string " at " no longer is used as an address delimiter. - Only at-sign ("@") serves the function. - - C.5.6. DOMAINS - - Hierarchical, logical name-domains have been added. - - C.6. RESERVED ADDRESS - - The local-part "Postmaster" has been reserved, so that users can - be guaranteed at least one valid address at a site. - - - - - - - - - - - August 13, 1982 - 43 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - D. ALPHABETICAL LISTING OF SYNTAX RULES - - address = mailbox ; one addressee - / group ; named list - addr-spec = local-part "@" domain ; global address - ALPHA = <any ASCII alphabetic character> - ; (101-132, 65.- 90.) - ; (141-172, 97.-122.) - atom = 1*<any CHAR except specials, SPACE and CTLs> - authentic = "From" ":" mailbox ; Single author - / ( "Sender" ":" mailbox ; Actual submittor - "From" ":" 1#mailbox) ; Multiple authors - ; or not sender - CHAR = <any ASCII character> ; ( 0-177, 0.-127.) - comment = "(" *(ctext / quoted-pair / comment) ")" - CR = <ASCII CR, carriage return> ; ( 15, 13.) - CRLF = CR LF - ctext = <any CHAR excluding "(", ; => may be folded - ")", "\" & CR, & including - linear-white-space> - CTL = <any ASCII control ; ( 0- 37, 0.- 31.) - character and DEL> ; ( 177, 127.) - date = 1*2DIGIT month 2DIGIT ; day month year - ; e.g. 20 Jun 82 - dates = orig-date ; Original - [ resent-date ] ; Forwarded - date-time = [ day "," ] date time ; dd mm yy - ; hh:mm:ss zzz - day = "Mon" / "Tue" / "Wed" / "Thu" - / "Fri" / "Sat" / "Sun" - delimiters = specials / linear-white-space / comment - destination = "To" ":" 1#address ; Primary - / "Resent-To" ":" 1#address - / "cc" ":" 1#address ; Secondary - / "Resent-cc" ":" 1#address - / "bcc" ":" #address ; Blind carbon - / "Resent-bcc" ":" #address - DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.) - domain = sub-domain *("." sub-domain) - domain-literal = "[" *(dtext / quoted-pair) "]" - domain-ref = atom ; symbolic reference - dtext = <any CHAR excluding "[", ; => may be folded - "]", "\" & CR, & including - linear-white-space> - extension-field = - <Any field which is defined in a document - published as a formal extension to this - specification; none will have names beginning - with the string "X-"> - - - August 13, 1982 - 44 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - field = field-name ":" [ field-body ] CRLF - fields = dates ; Creation time, - source ; author id & one - 1*destination ; address required - *optional-field ; others optional - field-body = field-body-contents - [CRLF LWSP-char field-body] - field-body-contents = - <the ASCII characters making up the field-body, as - defined in the following sections, and consisting - of combinations of atom, quoted-string, and - specials tokens, or else consisting of texts> - field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":"> - group = phrase ":" [#mailbox] ";" - hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] - ; 00:00:00 - 23:59:59 - HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.) - LF = <ASCII LF, linefeed> ; ( 12, 10.) - linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE - ; CRLF => folding - local-part = word *("." word) ; uninterpreted - ; case-preserved - LWSP-char = SPACE / HTAB ; semantics = SPACE - mailbox = addr-spec ; simple address - / phrase route-addr ; name & addr-spec - message = fields *( CRLF *text ) ; Everything after - ; first null line - ; is message body - month = "Jan" / "Feb" / "Mar" / "Apr" - / "May" / "Jun" / "Jul" / "Aug" - / "Sep" / "Oct" / "Nov" / "Dec" - msg-id = "<" addr-spec ">" ; Unique message id - optional-field = - / "Message-ID" ":" msg-id - / "Resent-Message-ID" ":" msg-id - / "In-Reply-To" ":" *(phrase / msg-id) - / "References" ":" *(phrase / msg-id) - / "Keywords" ":" #phrase - / "Subject" ":" *text - / "Comments" ":" *text - / "Encrypted" ":" 1#2word - / extension-field ; To be defined - / user-defined-field ; May be pre-empted - orig-date = "Date" ":" date-time - originator = authentic ; authenticated addr - [ "Reply-To" ":" 1#address] ) - phrase = 1*word ; Sequence of words - - - - - August 13, 1982 - 45 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - qtext = <any CHAR excepting <">, ; => may be folded - "\" & CR, and including - linear-white-space> - quoted-pair = "\" CHAR ; may quote any char - quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or - ; quoted chars. - received = "Received" ":" ; one per relay - ["from" domain] ; sending host - ["by" domain] ; receiving host - ["via" atom] ; physical path - *("with" atom) ; link/mail protocol - ["id" msg-id] ; receiver msg id - ["for" addr-spec] ; initial form - ";" date-time ; time received - - resent = resent-authentic - [ "Resent-Reply-To" ":" 1#address] ) - resent-authentic = - = "Resent-From" ":" mailbox - / ( "Resent-Sender" ":" mailbox - "Resent-From" ":" 1#mailbox ) - resent-date = "Resent-Date" ":" date-time - return = "Return-path" ":" route-addr ; return address - route = 1#("@" domain) ":" ; path-relative - route-addr = "<" [route] addr-spec ">" - source = [ trace ] ; net traversals - originator ; original mail - [ resent ] ; forwarded - SPACE = <ASCII SP, space> ; ( 40, 32.) - specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- - / "," / ";" / ":" / "\" / <"> ; string, to use - / "." / "[" / "]" ; within a word. - sub-domain = domain-ref / domain-literal - text = <any CHAR, including bare ; => atoms, specials, - CR & bare LF, but NOT ; comments and - including CRLF> ; quoted-strings are - ; NOT recognized. - time = hour zone ; ANSI and Military - trace = return ; path to sender - 1*received ; receipt tags - user-defined-field = - <Any field which has not been defined - in this specification or published as an - extension to this specification; names for - such fields must be unique and may be - pre-empted by published extensions> - word = atom / quoted-string - - - - - August 13, 1982 - 46 - RFC #822 - - - - Standard for ARPA Internet Text Messages - - - zone = "UT" / "GMT" ; Universal Time - ; North American : UT - / "EST" / "EDT" ; Eastern: - 5/ - 4 - / "CST" / "CDT" ; Central: - 6/ - 5 - / "MST" / "MDT" ; Mountain: - 7/ - 6 - / "PST" / "PDT" ; Pacific: - 8/ - 7 - / 1ALPHA ; Military: Z = UT; - <"> = <ASCII quote mark> ; ( 42, 34.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - August 13, 1982 - 47 - RFC #822 - diff --git a/RFC/rfc937.txt b/RFC/rfc937.txt deleted file mode 100644 index ae154ea8..00000000 --- a/RFC/rfc937.txt +++ /dev/null @@ -1,1392 +0,0 @@ - - -Network Working Group M. Butler -Request for Comments: 937 J. Postel - D. Chase - J. Goldberger - J. K. Reynolds -Obsoletes: RFC 918 ISI - February 1985 - - - POST OFFICE PROTOCOL - VERSION 2 - - -Status of this Memo - - This RFC suggests a simple method for workstations to dynamically - access mail from a mailbox server. This RFC specifies a proposed - protocol for the ARPA-Internet community, and requests discussion and - suggestions for improvement. This memo is a revision of RFC 918. - Distribution of this memo is unlimited. - -Introduction - - The intent of the Post Office Protocol Version 2 (POP2) is to allow a - user's workstation to access mail from a mailbox server. It is - expected that mail will be posted from the workstation to the mailbox - server via the Simple Mail Transfer Protocol (SMTP). For further - information see RFC-821 [1] and RFC-822 [2]. - - This protocol assumes a reliable data stream such as provided by TCP - or any similar protocol. When TCP is used, the POP2 server listens - on port 109 [4]. - -System Model and Philosophy - - While we view the workstation as an Internet host in the sense that - it implements IP, we do not expect the workstation to contain the - user's mailbox. We expect the mailbox to be on a server machine. - - We believe it is important for the mailbox to be on an "always up" - machine and that a workstation may be frequently powered down, or - otherwise unavailable as an SMTP server. - - POP2 is designed for an environment of workstations and servers on a - low-delay, high-throughput, local networks (such as Ethernets). POP2 - may be useful in other environments as well, but if the environment - is substantially different, a different division of labor between the - client and server may be appropriate, and a different protocol - required. - - Suppose the user's real name is John Smith, the user's machine is - called FIDO, and that the mailbox server is called DOG-HOUSE. Then - - - -Butler, et. al. [Page 1] - - - -RFC 937 February 1985 -Post Office Protocol - - - we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA - (not JSmith@FIDO.ARPA). - - That is, the destination of the mail is the mailbox on the server - machine. The POP2 protocol and the workstation are merely a - mechanism for viewing the messages in the mailbox. - - The user is not tied to any particular workstation for accessing his - mail. The workstation does not appear as any part of the mailbox - address. - - This is a very simple protocol. This is not a user interface. We - expect that there is a program in the workstation that is friendly to - the user. This protocol is not "user friendly". One basic rule of - this protocol is "if anything goes wrong close the connection". - Another basic rule is to have few options. - - POP2 does not parse messages in any way. It does not analyze message - headers (Date:, From:, To:, Cc:, or Subject:). POP2 simply transmits - whole messages from a mailbox server to a client workstation. - -The Protocol - - The POP2 protocol is a sequence of commands and replies. The design - draws from many previous protocols of the ARPA-Internet community. - - The server must be listening for a connection. When a connection - is opened the server sends a greeting message and waits for - commands. When commands are received the server acts on them and - responds with replies. - - The client opens a connection, waits for the greeting, then sends - the HELO command with the user name and password arguments to - establish authorization to access mailboxes. The server returns - the number of messages in the default mailbox. - - The client may read the default mailbox associated with the user - name or may select another mailbox by using the FOLD command. The - server returns the number of messages in the mailbox selected. - - The client begins a message reading transaction with a READ - command. The read command may optionally indicate which message - number to read, the default is the current message (incremented - when a message is read and set to one when a new folder is - selected). The server returns the number of characters in the - message. - - - - -Butler, et. al. [Page 2] - - - -RFC 937 February 1985 -Post Office Protocol - - - The client asks for the content of the message to be sent with the - RETR command. The server sends the message data. - - When all the data has been received the client sends an - acknowledgment command. This is one of ACKS, ACKD, and NACK. - - ACKS means "I've received the message successfully and please - keep it in the mailbox". - - ACKD means "I've received the message successfully and please - delete it from the mailbox". - - NACK means "I did not receive the message and please keep it in - the mailbox". - - In the case of ACKS or ACKD the server increments the current - message indicator. In the case of NACK the current message - indicator stays the same. - - In all cases the server returns the number of characters in the - (now) current message. - - The client terminates the session with the QUIT command. The - server returns an ok. - - - - - - - - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 3] - - - -RFC 937 February 1985 -Post Office Protocol - - - The Normal Scenario - - Client Server - ------ ------ - Wait for Connection - Open Connection --> - <-- + POP2 Server Ready - Wait for Command - HELO Fred Secret --> - <-- #13 messages for you - Wait for Command - READ 13 --> - <-- =537 characters in that message - Wait for Command - RETR --> - <-- (send the message data) - Wait for Command - ACKS --> - <-- =0 no more messages - Wait for Command - QUIT --> - <-- + OK - Close connection --> <-- Close connection - Wait for Connection (go back to start) - -Conventions - - Arguments - - These arguments have system specific definitions. - - user - A login account name. - - password - The password for the login account. - - mailbox - A mailbox name (also called a mail folder). - - - - - - - - - - - - - - -Butler, et. al. [Page 4] - - - -RFC 937 February 1985 -Post Office Protocol - - - Default Mailboxes - - TOPS-20 - - MAIL.TXT.1 - from login directory - - UNIX - - both - /usr/spool/mail/user - and - /usr/user/Mail/inbox/* - - where "user" is the user value supplied in the HELO command. - - End of Line - - End of Line is Carriage Return (CR) followed by Line Feed (LF). - This sequence is indicated by "CRLF" in this document. This end - of line convention must be used for commands and replies. - - Message Length - - The reply to the READ command or an acknowledgment command (ACKS, - ACKD, NACK) is the length (a character count) of the next message - to be transmitted. This includes all the characters in the data - transmitted. CRLF counts as two characters. A length of zero - means the message does not exist or is empty. A request to - transmit a message of zero length will result in the server - closing the connection. The message is transmitted in the - standard internet format described in RFC-822 [2] and NVT-ASCII. - This may be different from the storage format and may make - computing the message length from the stored message non-trivial. - - Message Numbers - - The reply to the HELO and FOLD commands is a count of the number - of messages in a the selected mailbox. The READ command has a - message number as an optional argument. These numbers are - decimal, start at one, and computed with respect to the current - mailbox. That is, the first message in a mailbox is message - number 1. - - Numbers - - All numbers in this memo and protocol are decimal. - - - - -Butler, et. al. [Page 5] - - - -RFC 937 February 1985 -Post Office Protocol - - - Quoting - - In a few cases, there may be a need to have a special character in - an argument (user, password, or mailbox) that is not allowed by - the syntax. For example, a space in a password. To allow for - this, a quoting convention is defined. Unfortunately, such - quoting conventions "use up" another otherwise uninteresting - character. In this protocol the back slash "\" is used as the - quote character. To include a space in an argument the two - character sequence "back-slash, space" is transmitted. To include - a back-slash in an argument the two character sequence - "back-slash, back-slash" is transmitted. This quoting convention - is used in the command arguments only, it is not used in the mail - data transmitted in response to a RETR command. - - Reply Strings - - The first character is required to be as specified (i.e., - "+", "-", "=", "#"). The optional strings that follow can be - whatever the implementer thinks is appropriate. - -Definitions of Commands and Replies - - Summary of Commands and Replies - - Commands Replies - -------- ------- - HELO user password + OK - FOLD mailbox - Error - READ [n] #xxx - RETR =yyy - ACKS - ACKD - NACK - QUIT - - - - - - - - - - - - - - - -Butler, et. al. [Page 6] - - - -RFC 937 February 1985 -Post Office Protocol - - - Commands - - HELO user password - - The Hello command identifies the user to the server and carries - the password authenticating this user. This information is - used by the server to control access to the mailboxes. The - Hello command is the "HELO" keyword, followed by the user - argument, followed by the password argument, followed by CRLF. - - Possible responses: - - "#nnn" - - where nnn is the number of messages in the default - mailbox," - - "- error report" and Close the connection. - - FOLD mailbox - - The Folder command selects another mailbox or mail folder. The - server must check that the user is permitted read access to - this mailbox. If the mailbox is empty or does not exist, the - number of messages reported is zero. The Folder command is the - "FOLD" keyword, followed by the mailbox argument, followed by - CRLF. - - Possible responses: - - "#nnn" - - where nnn is the number of messages in this mailbox. - - READ [nnn] - - The Read command begins a message reading transaction. If the - Read command is given without an argument the current message - is implied (the current message indicator is incremented by - the ACKS or ACKD commands). If an argument is used with the - Read command it is the message number to be read, and this - command sets the current message indicator to that value. The - server returns the count of characters in the message to be - transmitted. If there is no message to be read, the count of - zero is returned. If the message was previously deleted with - the ACKD command, the count of zero is returned. The Read - command is followed by the RETR command, the READ command, the - FOLD command, or the QUIT command. Do not attempt to RETR a - - -Butler, et. al. [Page 7] - - - -RFC 937 February 1985 -Post Office Protocol - - - message of zero characters. The Read command is the "READ" - keyword, optionally followed by the message number argument, - followed by CRLF. - - Possible responses: - - "=ccc" - - where ccc is the number of characters in this message. - - RETR - - The Retrieve command confirms that the client is ready to - receive the mail data. It must be followed by an - acknowledgment command. The server will close the connection - if asked to transmit a message of zero characters (i.e., - transmit a non-existent message). The message is transmitted - according to the Internet mail format standard RFC-822 [2] in - NVT-ASCII. The Retrieve command is the "RETR" keyword, - followed by CRLF. - - Possible responses: - - the message data - - Close the connection - - ACKS - - The Acknowledge and Save command confirms that the client has - received and accepted the message. The ACKS command ends the - message reading transaction. The message is kept in the - mailbox. The current message indicator is incremented. The - server returns the count of characters in the now current - message to be transmitted. If there is no message to be read - or the message is marked deleted, the count of zero is - returned. The Acknowledge and Save command is the "ACKS" - keyword, followed by CRLF. - - Possible responses: - - "=ccc" - - where ccc is the number of characters in the next - message. - - - - - -Butler, et. al. [Page 8] - - - -RFC 937 February 1985 -Post Office Protocol - - - ACKD - - The Acknowledge and Delete command confirms that the client has - received and accepted the message. The ACKD command ends the - message reading transaction. If the user is authorized to have - write access to the mailbox, the message is deleted from the - mailbox. Actually, the message is only marked for deletion. - The actual change is made when the mailbox is released at the - end of the session or when the client selects another mailbox - with the FOLD command. The messages are not renumbered until - the mailbox is released. If the user does not have write - access to the mailbox no change is made to the mailbox. The - response is the same whether or not the message was actually - deleted. The current message indicator is incremented. The - server returns the count of characters in the now current - message to be transmitted. If there is no message to be read - or the message is marked deleted, the count of zero is - returned. The Acknowledge and Delete command is the "ACKD" - keyword, followed by CRLF. - - Possible responses: - - "=ccc" - - where ccc is the number of characters in the next - message. - - NACK - - The Negative Acknowledge command reports that the client did - not receive the message. The NACK command ends the message - reading transaction. The message is kept in the mailbox. The - current message indicator remains the same. The server returns - the count of characters in the current message. Since the - count to be returned is for the message just transmitted it the - message must exist and not be marked deleted, and the count - must be positive (non-zero). The Negative Acknowledge command - is the "NACK" keyword, followed by CRLF. - - Possible responses: - - "=ccc" - - where ccc is the number of characters in this message. - - - - - - -Butler, et. al. [Page 9] - - - -RFC 937 February 1985 -Post Office Protocol - - - QUIT - - The Quit command indicates the client is done with the session. - The server sends an OK response and then closes the connection. - The Quit command is the "QUIT" keyword, followed by CRLF. - - Possible responses: - - "+ OK" and Close the connection - - Replies - - Greeting - - The greeting is sent by the server as soon as the connection is - established. The greeting is a plus sign, followed by the - protocol name ("POP2"), followed by the server host name, - optionally followed by text, and ending with a CRLF. - - + - - The success or plus sign response indicates successful - completion of the operation specified in the command. The - success response is a plus sign, optionally followed by text, - and ending with a CRLF. - - - - - The failure or minus sign response indicates the failure of the - operation specified in the command. The failure response is a - minus sign, optionally followed by text, and ending with a - CRLF. - - = - - The length or equal sign response tells the length in - characters of the message referenced by the command. The - length response is a equal sign, followed by a number, - optionally followed by text, and ending with a CRLF. - - # - - The count or number sign response tells the number of messages - in a folder or mailbox referenced by the command. The count - response is a number sign, followed by a number, optionally - followed by text, and ending with a CRLF. - - - - -Butler, et. al. [Page 10] - - - -RFC 937 February 1985 -Post Office Protocol - - - Timeouts - - In any protocol of this type there have to be timeouts. Neither - side wants to get stuck waiting forever for the other side - (particularly is the other side has gone crazy or crashed). - - The client expects a reply to a command fairly quickly and so - should have a short timeout for this. This timeout is called T1. - - For some servers, it may take some processing to compute the - number of messages in a mailbox, or the length of a message, or - to reformat a stored message for transmission, so this time out - has to allow for such processing time. Also care must be taken - not to timeout waiting for the completion of a RETR reply while - a long message is in fact being transfered. - - The server expects the session to progress with some but not - excessive delay between commands and so should have a long timeout - waiting for the next command. This time out is T2. - - One model of use of this protocol is that any number of - different types of clients can be built with different ways of - interacting with the human user and the server, but still - expecting the client to open the connection to the server, - present a sequence of commands, and close the connection, - without waiting for intervention by the human user. With such - client implementations, it is reasonable for the server to have - a fairly small value for timeout T2. - - On the other hand, one could easily have the client be very - human user directed with the user making decisions between - commands. This would cause arbitrary delays between client - commands to the server, and require the value of timeout T2 to - be quite large. - -Implementation Discussion - - Comments on a Server on TOPS-20 - - On TOPS-20, a mailbox is a single file. New messages are appended - to the file. There is a separator line between messages. - - The tricky part of implementing a POP2 server on TOPS-20 is to - provide for deleting messages. This only has to be done for the - mailboxes (files) for which the user has write access. The - problem is to avoid both (1) preventing other users from accessing - or updating the mailbox for long periods, and (2) accidentally - deleting a message the user has not seen. - - -Butler, et. al. [Page 11] - - - -RFC 937 February 1985 -Post Office Protocol - - - One suggestion is as follows: - - When a mailbox is first selected, if the user has write access, - rename the mailbox file to some temporary name. Thus new - messages will be placed in a new instance of the mailbox file. - Conduct all POP2 operation on the temporary mailbox file - (including deleting messages). When the POP2 session is over - or another mailbox is selected, prepend any messages left - undeleted in the temporary file to the new instance of the - mailbox file. - - Sizes - - The maximum length of a command line is 512 characters (including - the command word and the CRLF). - - The maximum length of a reply line is 512 characters (including - the success indicator (+, -, =, #) and the CRLF). - - The maximum length of a text line is 1000 characters (including - CRLF). - - ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2 - Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix. - -Extensions Not Supported - - POP2 does not examine the internal data of messages. In particular, - the server does not parse message headers. - - The server doesn't have any state information (i.e., it doesn't know - from one session to the next what has happened). For example, the - server doesn't know which messages were received since the last time - the user used POP2, so it can't send just the "new" messages. - - - - - - - - - - - - - - - - -Butler, et. al. [Page 12] - - - -RFC 937 February 1985 -Post Office Protocol - - -Examples - - Example 1: - - Client Server - ------ ------ - Wait for connection - Open connection --> - <-- + POP2 USC-ISIF.ARPA Server - HELO POSTEL SECRET --> - <-- #2 messages in your mailbox - READ --> - <-- =537 characters in message 1 - RETR --> - <-- [data of message 1] - ACKD --> - <-- =234 characters in message 2 - RETR --> - <-- [data of message 2] - ACKD --> - <-- =0 no more messages - QUIT --> - <-- + OK, bye, bye - Close connection --> <-- Close connection - Go back to start - - - - - - - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 13] - - - -RFC 937 February 1985 -Post Office Protocol - - - Example 2: - - Client Server - ------ ------ - Wait for connection - Open connection --> - <-- + POP2 ISI-VAXA.ARPA server here - HELO smith secret --> - <-- #35 messages - FOLD /usr/spool/mail/smith --> - <-- #27 messages - READ 27 --> - <-- =10123 characters in that message - RETR --> - <-- [data of message 27] - ACKS --> - <-- =0 no more messages - QUIT --> - <-- + bye, call again sometime. - Close connection --> <-- Close connection - Go back to start - - Example 3: - - Client Server - ------ ------ - Wait for connection - Open connection --> - <-- + POP2 ISI-VAXA.ARPA server here - HELO Jones secret --> - <-- #0 messages - READ --> - <-- Close connection - Close connection --> - Go back to start - - - - - - - - - - - - - - - -Butler, et. al. [Page 14] - - - -RFC 937 February 1985 -Post Office Protocol - - -Formal Syntax - - <digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - - <letter> = A | B | C | ... | Z - a | b | c | ... | z - - <punct> = ! | " | # | $ | % | & | ' | ( | ) | * | - + | , | - | / | : | < | = | > | ? | @ | - [ | ] | ^ | _ | ` | { | | | } | ~ - - <quote> = \ - - <any> = any one of the 128 ASCII codes - - <CR> = carriage return, code 10 - - <LF> = line feed, code 13 - - <SP> = space, code 32 - - <CRLF> = <CR> <LF> - - <print> = <letter> | <digit> | <punct> | <quote> <any> - - <char> = <print> | <SP> - - <word> = <print> | <print> <word> - - <string> = <char> | <char> <string> - - <ld> = <letter> | <digit> - - <ldh> = <letter> | <digit> | - - - <ldhs> = <ldh> | <ldh> <ldhs> - - <name> = <letter> [ [ <ldhs> ] <ld> ] - - <host> = <name> | <name> . <host> - - <user> = <word> - - <password> = <word> - - <mailbox> = <string> - - <number> = <digit> | <digit> <number> - - -Butler, et. al. [Page 15] - - - -RFC 937 February 1985 -Post Office Protocol - - - <helo> = HELO <SP> <user> <SP> <password> <CRLF> - - <fold> = FOLD <SP> <mailbox> <CRLF> - - <read> = READ [<SP> <number>] <CRLF> - - <retr> = RETR <CRLF> - - <acks> = ACKS <CRLF> - - <ackd> = ACKD <CRLF> - - <nack> = NACK <CRLF> - - <quit> = QUIT <CRLF> - - <ok> = + [<SP> <string>] <CRLF> - - <err> = - [<SP> <string>] <CRLF> - - <count> = # <number> [<SP> <string>] <CRLF> - - <greet> = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF> - - <length> = = <number> [<SP> <string>] <CRLF> - - <command> = <helo> | <fold> | <read> | <retr> | - <acks> | <ackd> | <nack> | <quit> - - <reply> = <ok> | <err> | <count> | <length> | <greet> - - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 16] - - - -RFC 937 February 1985 -Post Office Protocol - - -Client State Diagram - - - | ^ + BYE - | Open | ----- - | Greet | Close - V ----- | - +-------+ QUIT +-------+ - | CALL |-------------->| EXIT | - +-------+ +-------+ - | ^ - | Greet | - | ----- | - | HELO | - +---->+ | | - #NNN ^ | | #NNN | - ---- | V V ---- | - FOLD | +-------+ QUIT | - +<---| NMBR |--------------------->+ - +-------+ ^ - ^ | | - | | #NNN | - | | ---- | - =CCC | | READ | - ---- | | | - FOLD | | =CCC | - | V ---- | - =CCC +--->+-------+ QUIT | - ---- ^ | SIZE |--------------------->+ - READ +<---+-------+ - ^ | - | | =CCC - data | | ---- - ---- | | RETR - ack | | - | V - +-------+ - | XFER | - +-------+ - - - - - - - - - - - -Butler, et. al. [Page 17] - - - -RFC 937 February 1985 -Post Office Protocol - - -Server State Diagram - - - +<----------------------+ Close - | | ----- - Listen | | Close - V | - +-------+ +-------+ - | LSTN | | DONE | - +-------+ +-------+ - | ^ - | Open | - | ----- | - | Greet | - | | - | QUIT | - V ----- | - +-------+ + BYE | - | AUTH |--------------------->+ - +-------+ ^ - | | - | HELO | - | ---- | - | #NNN | - | | - | QUIT | - V ----- | - FOLD +--->+-------+ + BYE | - ---- ^ | MBOX |--------------------->+ - #NNN +<---+-------+ ^ - ^ | | - | | READ | - FOLD | | ---- | - ---- | | =CCC | - #NNN | | QUIT | - | V ----- | - READ +--->+-------+ + BYE | - ---- ^ | ITEM |--------------------->+ - =CCC +<---+-------+ - ^ | - | | RETR - ack | | ---- - ---- | | data - =CCC | | - | V - +-------+ - | NEXT | - +-------+ - - -Butler, et. al. [Page 18] - - - -RFC 937 February 1985 -Post Office Protocol - - -Combined Flow Diagram - - - +----+ - |CALL|<------------------------------------------------------------+ - |LSTN| ^ - +----+ | - | Greet | - | | - | +----------------------------------------------------->+ | - | ^ QUIT | | - V | V | - +----+ +----+ +----+ | - |CALL| HELO |NMBR| |EXIT| | - |AUTH|------->|AUTH| |AUTH| | - +----+ +----+ +----+ | - | #NNN + Bye | | - | | | - | +------------------------------------>+ | | - | ^ QUIT | | | - V | V | | - +--->+----+ +----+ +----+ | | - FOLD ^ |NMBR| READ |SIZE| |EXIT| | | - ---- | |MBOX|------->|MBOX| |MBOX| | | - #NNN +<---+----+ +----+ +----+ | | - ^ | =CCC + Bye | | | - | | | | | - FOLD +<--------+ | +------------------->+ | | | - ---- ^ | ^ QUIT | | | | - #NNN | V | V | | | - +--->+-----+ +----+ +----+ | | | - READ ^ |SIZE | RETR |XFER| |EXIT| | | | - ---- | | ITEM|------->|ITEM| |ITEM| | | | - =CCC +<---+-----+ +----+ +----+ | | | - ^ | data | | | | - | | | | | | - =CCC | V + Bye | | | | - +----+ +----+ | | | | - |SIZE| Ack |XFER| | | | | - |NEXT|<-------|NEXT| | | | | - +----+ +----+ | | | | - | | | | - | | | | - V V V | - +-------+ | - | EXIT |-->+ - | DONE | - +-------+ - - -Butler, et. al. [Page 19] - - - -RFC 937 February 1985 -Post Office Protocol - - -Client Decision Table - - - | STATE | - -------+----------------------------------| - INPUT | CALL | NMBR | SIZE | XFER | EXIT | - -------+----------------------------------| - Greet | 2 | 1 | 1 | 1 | 6 | - -------+----------------------------------| - #NNN | 1 | 3 | 1 | 1 | 6 | - -------+----------------------------------| - =CCC | 1 | 1 | 4 | 1 | 6 | - -------+----------------------------------| - data | 1 | 1 | 1 | 5 | 6 | - -------+----------------------------------| - + Bye | 1 | 1 | 1 | 1 | 6 | - -------+----------------------------------| - Close | 1 | 1 | 1 | 1 | 6 | - -------+----------------------------------| - other | 1 | 1 | 1 | 1 | 6 | - -------+----------------------------------| - Timeout| 1 | 1 | 1 | 1 | 6 | - -------+----------------------------------| - - - - - - - - - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 20] - - - -RFC 937 February 1985 -Post Office Protocol - - - Actions: - - 1. This is garbage. Send "QUIT", and go to EXIT state. - - 2. (a) If the greeting is right then send "HELO" - and go to NMBR state, - (b) Else send "QUIT" and go to EXIT state. - - 3. (a) If user wants this folder and NNN > 0 - then send "READ" and go to SIZE state, - (b) If user wants a this folder and NNN = 0 - then send "QUIT" and go to EXIT state, - (c) If user wants a different folder - then send "FOLD" and go to NMBR state. - - 4. (a) If user wants this message and CCC > 0 - then send "RETR" and go to XFER state, - (b) If user wants a this message and CCC = 0 - then send "QUIT" and go to EXIT state, - (c) If user wants a different message - then send "READ" and go to SIZE state. - - 5. (a) If user wants this message kept - then send "ACKS" and go to SIZE state, - (b) If user wants a this message deleted - then send "ACKD" and go to SIZE state, - (c) If user wants a this message again - then send "NACK" and go to SIZE state. - - 6. Close the connection. - - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 21] - - - -RFC 937 February 1985 -Post Office Protocol - - -Server Decision Table - - - | STATE - -------+----------------------------------------- - INPUT | LSTN | AUTH | MBOX | ITEM | NEXT | DONE | - -------+-----------------------------------------| - Open | 2 | 1 | 1 | 1 | 1 | 1 | - -------+-----------------------------------------| - HELO | 1 | 3 | 1 | 1 | 1 | 1 | - -------+-----------------------------------------| - FOLD | 1 | 1 | 5 | 5 | 1 | 1 | - -------+-----------------------------------------| - READ | 1 | 1 | 6 | 6 | 1 | 1 | - -------+-----------------------------------------| - RETR | 1 | 1 | 1 | 7 | 1 | 1 | - -------+-----------------------------------------| - ACKS | 1 | 1 | 1 | 1 | 8 | 1 | - -------+-----------------------------------------| - ACKD | 1 | 1 | 1 | 1 | 8 | 1 | - -------+-----------------------------------------| - NACK | 1 | 1 | 1 | 1 | 8 | 1 | - -------+-----------------------------------------| - QUIT | 1 | 4 | 4 | 4 | 1 | 1 | - -------+-----------------------------------------| - Close | 1 | 1 | 1 | 1 | 1 | 9 | - -------+-----------------------------------------| - other | 1 | 1 | 1 | 1 | 1 | 1 | - -------+-----------------------------------------| - Timeout| | 1 | 1 | 1 | 1 | 1 | - -------+-----------------------------------------| - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 22] - - - -RFC 937 February 1985 -Post Office Protocol - - - Actions: - - 1. This is garbage. Send "- error", and Close the connection. - - 2. Send the greeting. Go to AUTH state. - - 3. (a) If authorized user then send "#NNN" and go tp MBOX state, - (b) Else send "- error" and Close the connection. - - 4. Send "+ Bye" and go to DONE state. - - 5. Send "+NNN" and go to MBOX state. - - 6. Send "=CCC" and go to ITEM state. - - 7. If message exists then send the data and got to NEXT state, - Else Close the connection. - - 8. Do what ACKS/ACKD/NACK require and go to ITEM state. - - 9. Close the connection. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 23] - - - -RFC 937 February 1985 -Post Office Protocol - - -Acknowledgment - - We would like to acknowledge the helpful comments that we received on - the first version of POP described in RFC 918, and the draft of POP2 - distributed to interested parties. - -References - - [1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, - USC/Information Sciences Institute, August 1982. - - [2] Crocker, D., "Standard for the Format of ARPA-Internet Text - Messages", RFC 822, University of Delaware, August 1982. - - [3] Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information - Sciences Institute, October 1984. - - [4] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923, - USC/Information Sciences Institute, October 1984. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Butler, et. al. [Page 24] - diff --git a/RFC/rfc977.txt b/RFC/rfc977.txt deleted file mode 100644 index 0f965c48..00000000 --- a/RFC/rfc977.txt +++ /dev/null @@ -1,1539 +0,0 @@ -
-
-Network Working Group Brian Kantor (U.C. San Diego)
-Request for Comments: 977 Phil Lapsley (U.C. Berkeley)
- February 1986
-
- Network News Transfer Protocol
-
- A Proposed Standard for the Stream-Based
- Transmission of News
-
-Status of This Memo
-
- NNTP specifies a protocol for the distribution, inquiry, retrieval,
- and posting of news articles using a reliable stream-based
- transmission of news among the ARPA-Internet community. NNTP is
- designed so that news articles are stored in a central database
- allowing a subscriber to select only those items he wishes to read.
- Indexing, cross-referencing, and expiration of aged messages are also
- provided. This RFC suggests a proposed protocol for the ARPA-Internet
- community, and requests discussion and suggestions for improvements.
- Distribution of this memo is unlimited.
-
-1. Introduction
-
- For many years, the ARPA-Internet community has supported the
- distribution of bulletins, information, and data in a timely fashion
- to thousands of participants. We collectively refer to such items of
- information as "news". Such news provides for the rapid
- dissemination of items of interest such as software bug fixes, new
- product reviews, technical tips, and programming pointers, as well as
- rapid-fire discussions of matters of concern to the working computer
- professional. News is very popular among its readers.
-
- There are popularly two methods of distributing such news: the
- Internet method of direct mailing, and the USENET news system.
-
-1.1. Internet Mailing Lists
-
- The Internet community distributes news by the use of mailing lists.
- These are lists of subscriber's mailbox addresses and remailing
- sublists of all intended recipients. These mailing lists operate by
- remailing a copy of the information to be distributed to each
- subscriber on the mailing list. Such remailing is inefficient when a
- mailing list grows beyond a dozen or so people, since sending a
- separate copy to each of the subscribers occupies large quantities of
- network bandwidth, CPU resources, and significant amounts of disk
- storage at the destination host. There is also a significant problem
- in maintenance of the list itself: as subscribers move from one job
- to another; as new subscribers join and old ones leave; and as hosts
- come in and out of service.
-
-
-
-
-Kantor & Lapsley [Page 1]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-1.2. The USENET News System
-
- Clearly, a worthwhile reduction of the amount of these resources used
- can be achieved if articles are stored in a central database on the
- receiving host instead of in each subscriber's mailbox. The USENET
- news system provides a method of doing just this. There is a central
- repository of the news articles in one place (customarily a spool
- directory of some sort), and a set of programs that allow a
- subscriber to select those items he wishes to read. Indexing,
- cross-referencing, and expiration of aged messages are also provided.
-
-1.3. Central Storage of News
-
- For clusters of hosts connected together by fast local area networks
- (such as Ethernet), it makes even more sense to consolidate news
- distribution onto one (or a very few) hosts, and to allow access to
- these news articles using a server and client model. Subscribers may
- then request only the articles they wish to see, without having to
- wastefully duplicate the storage of a copy of each item on each host.
-
-1.4. A Central News Server
-
- A way to achieve these economies is to have a central computer system
- that can provide news service to the other systems on the local area
- network. Such a server would manage the collection of news articles
- and index files, with each person who desires to read news bulletins
- doing so over the LAN. For a large cluster of computer systems, the
- savings in total disk space is clearly worthwhile. Also, this allows
- workstations with limited disk storage space to participate in the
- news without incoming items consuming oppressive amounts of the
- workstation's disk storage.
-
- We have heard rumors of somewhat successful attempts to provide
- centralized news service using IBIS and other shared or distributed
- file systems. While it is possible that such a distributed file
- system implementation might work well with a group of similar
- computers running nearly identical operating systems, such a scheme
- is not general enough to offer service to a wide range of client
- systems, especially when many diverse operating systems may be in use
- among a group of clients. There are few (if any) shared or networked
- file systems that can offer the generality of service that stream
- connections using Internet TCP provide, particularly when a wide
- range of host hardware and operating systems are considered.
-
- NNTP specifies a protocol for the distribution, inquiry, retrieval,
- and posting of news articles using a reliable stream (such as TCP)
- server-client model. NNTP is designed so that news articles need only
-
-
-Kantor & Lapsley [Page 2]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- be stored on one (presumably central) host, and subscribers on other
- hosts attached to the LAN may read news articles using stream
- connections to the news host.
-
- NNTP is modelled upon the news article specifications in RFC 850,
- which describes the USENET news system. However, NNTP makes few
- demands upon the structure, content, or storage of news articles, and
- thus we believe it easily can be adapted to other non-USENET news
- systems.
-
- Typically, the NNTP server runs as a background process on one host,
- and would accept connections from other hosts on the LAN. This works
- well when there are a number of small computer systems (such as
- workstations, with only one or at most a few users each), and a large
- central server.
-
-1.5. Intermediate News Servers
-
- For clusters of machines with many users (as might be the case in a
- university or large industrial environment), an intermediate server
- might be used. This intermediate or "slave" server runs on each
- computer system, and is responsible for mediating news reading
- requests and performing local caching of recently-retrieved news
- articles.
-
- Typically, a client attempting to obtain news service would first
- attempt to connect to the news service port on the local machine. If
- this attempt were unsuccessful, indicating a failed server, an
- installation might choose to either deny news access, or to permit
- connection to the central "master" news server.
-
- For workstations or other small systems, direct connection to the
- master server would probably be the normal manner of operation.
-
- This specification does not cover the operation of slave NNTP
- servers. We merely suggest that slave servers are a logical addition
- to NNTP server usage which would enhance operation on large local
- area networks.
-
-1.6. News Distribution
-
- NNTP has commands which provide a straightforward method of
- exchanging articles between cooperating hosts. Hosts which are well
- connected on a local area or other fast network and who wish to
- actually obtain copies of news articles for local storage might well
- find NNTP to be a more efficient way to distribute news than more
- traditional transfer methods (such as UUCP).
-
-
-Kantor & Lapsley [Page 3]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- In the traditional method of distributing news articles, news is
- propagated from host to host by flooding - that is, each host will
- send all its new news articles on to each host that it feeds. These
- hosts will then in turn send these new articles on to other hosts
- that they feed. Clearly, sending articles that a host already has
- obtained a copy of from another feed (many hosts that receive news
- are redundantly fed) again is a waste of time and communications
- resources, but for transport mechanisms that are single-transaction
- based rather than interactive (such as UUCP in the UNIX-world <1>),
- distribution time is diminished by sending all articles and having
- the receiving host simply discard the duplicates. This is an
- especially true when communications sessions are limited to once a
- day.
-
- Using NNTP, hosts exchanging news articles have an interactive
- mechanism for deciding which articles are to be transmitted. A host
- desiring new news, or which has new news to send, will typically
- contact one or more of its neighbors using NNTP. First it will
- inquire if any new news groups have been created on the serving host
- by means of the NEWGROUPS command. If so, and those are appropriate
- or desired (as established by local site-dependent rules), those new
- newsgroups can be created.
-
- The client host will then inquire as to which new articles have
- arrived in all or some of the newsgroups that it desires to receive,
- using the NEWNEWS command. It will receive a list of new articles
- from the server, and can request transmission of those articles that
- it desires and does not already have.
-
- Finally, the client can advise the server of those new articles which
- the client has recently received. The server will indicate those
- articles that it has already obtained copies of, and which articles
- should be sent to add to its collection.
-
- In this manner, only those articles which are not duplicates and
- which are desired are transferred.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 4]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-2. The NNTP Specification
-
-2.1. Overview
-
- The news server specified by this document uses a stream connection
- (such as TCP) and SMTP-like commands and responses. It is designed
- to accept connections from hosts, and to provide a simple interface
- to the news database.
-
- This server is only an interface between programs and the news
- databases. It does not perform any user interaction or presentation-
- level functions. These "user-friendly" functions are better left to
- the client programs, which have a better understanding of the
- environment in which they are operating.
-
- When used via Internet TCP, the contact port assigned for this
- service is 119.
-
-2.2. Character Codes
-
- Commands and replies are composed of characters from the ASCII
- character set. When the transport service provides an 8-bit byte
- (octet) transmission channel, each 7-bit character is transmitted
- right justified in an octet with the high order bit cleared to zero.
-
-2.3. Commands
-
- Commands consist of a command word, which in some cases may be
- followed by a parameter. Commands with parameters must separate the
- parameters from each other and from the command by one or more space
- or tab characters. Command lines must be complete with all required
- parameters, and may not contain more than one command.
-
- Commands and command parameters are not case sensitive. That is, a
- command or parameter word may be upper case, lower case, or any
- mixture of upper and lower case.
-
- Each command line must be terminated by a CR-LF (Carriage Return -
- Line Feed) pair.
-
- Command lines shall not exceed 512 characters in length, counting all
- characters including spaces, separators, punctuation, and the
- trailing CR-LF (thus there are 510 characters maximum allowed for the
- command and its parameters). There is no provision for continuation
- command lines.
-
-
-
-
-Kantor & Lapsley [Page 5]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-2.4. Responses
-
- Responses are of two kinds, textual and status.
-
-2.4.1. Text Responses
-
- Text is sent only after a numeric status response line has been sent
- that indicates that text will follow. Text is sent as a series of
- successive lines of textual matter, each terminated with CR-LF pair.
- A single line containing only a period (.) is sent to indicate the
- end of the text (i.e., the server will send a CR-LF pair at the end
- of the last line of text, a period, and another CR-LF pair).
-
- If the text contained a period as the first character of the text
- line in the original, that first period is doubled. Therefore, the
- client must examine the first character of each line received, and
- for those beginning with a period, determine either that this is the
- end of the text or whether to collapse the doubled period to a single
- one.
-
- The intention is that text messages will usually be displayed on the
- user's terminal whereas command/status responses will be interpreted
- by the client program before any possible display is done.
-
-2.4.2. Status Responses
-
- These are status reports from the server and indicate the response to
- the last command received from the client.
-
- Status response lines begin with a 3 digit numeric code which is
- sufficient to distinguish all responses. Some of these may herald
- the subsequent transmission of text.
-
- The first digit of the response broadly indicates the success,
- failure, or progress of the previous command.
-
- 1xx - Informative message
- 2xx - Command ok
- 3xx - Command ok so far, send the rest of it.
- 4xx - Command was correct, but couldn't be performed for
- some reason.
- 5xx - Command unimplemented, or incorrect, or a serious
- program error occurred.
-
-
-
-
-
-
-Kantor & Lapsley [Page 6]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- The next digit in the code indicates the function response category.
-
- x0x - Connection, setup, and miscellaneous messages
- x1x - Newsgroup selection
- x2x - Article selection
- x3x - Distribution functions
- x4x - Posting
- x8x - Nonstandard (private implementation) extensions
- x9x - Debugging output
-
- The exact response codes that should be expected from each command
- are detailed in the description of that command. In addition, below
- is listed a general set of response codes that may be received at any
- time.
-
- Certain status responses contain parameters such as numbers and
- names. The number and type of such parameters is fixed for each
- response code to simplify interpretation of the response.
-
- Parameters are separated from the numeric response code and from each
- other by a single space. All numeric parameters are decimal, and may
- have leading zeros. All string parameters begin after the separating
- space, and end before the following separating space or the CR-LF
- pair at the end of the line. (String parameters may not, therefore,
- contain spaces.) All text, if any, in the response which is not a
- parameter of the response must follow and be separated from the last
- parameter by a space. Also, note that the text following a response
- number may vary in different implementations of the server. The
- 3-digit numeric code should be used to determine what response was
- sent.
-
- Response codes not specified in this standard may be used for any
- installation-specific additional commands also not specified. These
- should be chosen to fit the pattern of x8x specified above. (Note
- that debugging is provided for explicitly in the x9x response codes.)
- The use of unspecified response codes for standard commands is
- prohibited.
-
- We have provided a response pattern x9x for debugging. Since much
- debugging output may be classed as "informative messages", we would
- expect, therefore, that responses 190 through 199 would be used for
- various debugging outputs. There is no requirement in this
- specification for debugging output, but if such is provided over the
- connected stream, it must use these response codes. If appropriate
- to a specific implementation, other x9x codes may be used for
- debugging. (An example might be to use e.g., 290 to acknowledge a
- remote debugging request.)
-
-
-Kantor & Lapsley [Page 7]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-2.4.3. General Responses
-
- The following is a list of general response codes that may be sent by
- the NNTP server. These are not specific to any one command, but may
- be returned as the result of a connection, a failure, or some unusual
- condition.
-
- In general, 1xx codes may be ignored or displayed as desired; code
- 200 or 201 is sent upon initial connection to the NNTP server
- depending upon posting permission; code 400 will be sent when the
- NNTP server discontinues service (by operator request, for example);
- and 5xx codes indicate that the command could not be performed for
- some unusual reason.
-
- 100 help text
- 190
- through
- 199 debug output
-
- 200 server ready - posting allowed
- 201 server ready - no posting allowed
-
- 400 service discontinued
-
- 500 command not recognized
- 501 command syntax error
- 502 access restriction or permission denied
- 503 program fault - command not performed
-
-3. Command and Response Details
-
- On the following pages are descriptions of each command recognized by
- the NNTP server and the responses which will be returned by those
- commands.
-
- Each command is shown in upper case for clarity, although case is
- ignored in the interpretation of commands by the NNTP server. Any
- parameters are shown in lower case. A parameter shown in [square
- brackets] is optional. For example, [GMT] indicates that the
- triglyph GMT may present or omitted.
-
- Every command described in this section must be implemented by all
- NNTP servers.
-
-
-
-
-
-
-Kantor & Lapsley [Page 8]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- There is no prohibition against additional commands being added;
- however, it is recommended that any such unspecified command begin
- with the letter "X" to avoid conflict with later revisions of this
- specification.
-
- Implementors are reminded that such additional commands may not
- redefine specified status response codes. Using additional
- unspecified responses for standard commands is also prohibited.
-
-3.1. The ARTICLE, BODY, HEAD, and STAT commands
-
- There are two forms to the ARTICLE command (and the related BODY,
- HEAD, and STAT commands), each using a different method of specifying
- which article is to be retrieved. When the ARTICLE command is
- followed by a message-id in angle brackets ("<" and ">"), the first
- form of the command is used; when a numeric parameter or no parameter
- is supplied, the second form is invoked.
-
- The text of the article is returned as a textual response, as
- described earlier in this document.
-
- The HEAD and BODY commands are identical to the ARTICLE command
- except that they respectively return only the header lines or text
- body of the article.
-
- The STAT command is similar to the ARTICLE command except that no
- text is returned. When selecting by message number within a group,
- the STAT command serves to set the current article pointer without
- sending text. The returned acknowledgement response will contain the
- message-id, which may be of some value. Using the STAT command to
- select by message-id is valid but of questionable value, since a
- selection by message-id does NOT alter the "current article pointer".
-
-3.1.1. ARTICLE (selection by message-id)
-
- ARTICLE <message-id>
-
- Display the header, a blank line, then the body (text) of the
- specified article. Message-id is the message id of an article as
- shown in that article's header. It is anticipated that the client
- will obtain the message-id from a list provided by the NEWNEWS
- command, from references contained within another article, or from
- the message-id provided in the response to some other commands.
-
- Please note that the internally-maintained "current article pointer"
- is NOT ALTERED by this command. This is both to facilitate the
- presentation of articles that may be referenced within an article
-
-
-Kantor & Lapsley [Page 9]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- being read, and because of the semantic difficulties of determining
- the proper sequence and membership of an article which may have been
- posted to more than one newsgroup.
-
-3.1.2. ARTICLE (selection by number)
-
- ARTICLE [nnn]
-
- Displays the header, a blank line, then the body (text) of the
- current or specified article. The optional parameter nnn is the
-
- numeric id of an article in the current newsgroup and must be chosen
- from the range of articles provided when the newsgroup was selected.
- If it is omitted, the current article is assumed.
-
- The internally-maintained "current article pointer" is set by this
- command if a valid article number is specified.
-
- [the following applies to both forms of the article command.] A
- response indicating the current article number, a message-id string,
- and that text is to follow will be returned.
-
- The message-id string returned is an identification string contained
- within angle brackets ("<" and ">"), which is derived from the header
- of the article itself. The Message-ID header line (required by
- RFC850) from the article must be used to supply this information. If
- the message-id header line is missing from the article, a single
- digit "0" (zero) should be supplied within the angle brackets.
-
- Since the message-id field is unique with each article, it may be
- used by a news reading program to skip duplicate displays of articles
- that have been posted more than once, or to more than one newsgroup.
-
-3.1.3. Responses
-
- 220 n <a> article retrieved - head and body follow
- (n = article number, <a> = message-id)
- 221 n <a> article retrieved - head follows
- 222 n <a> article retrieved - body follows
- 223 n <a> article retrieved - request text separately
- 412 no newsgroup has been selected
- 420 no current article has been selected
- 423 no such article number in this group
- 430 no such article found
-
-
-
-
-
-Kantor & Lapsley [Page 10]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.2. The GROUP command
-
-3.2.1. GROUP
-
- GROUP ggg
-
- The required parameter ggg is the name of the newsgroup to be
- selected (e.g. "net.news"). A list of valid newsgroups may be
- obtained from the LIST command.
-
- The successful selection response will return the article numbers of
- the first and last articles in the group, and an estimate of the
- number of articles on file in the group. It is not necessary that
- the estimate be correct, although that is helpful; it must only be
- equal to or larger than the actual number of articles on file. (Some
- implementations will actually count the number of articles on file.
- Others will just subtract first article number from last to get an
- estimate.)
-
- When a valid group is selected by means of this command, the
- internally maintained "current article pointer" is set to the first
- article in the group. If an invalid group is specified, the
- previously selected group and article remain selected. If an empty
- newsgroup is selected, the "current article pointer" is in an
- indeterminate state and should not be used.
-
- Note that the name of the newsgroup is not case-dependent. It must
- otherwise match a newsgroup obtained from the LIST command or an
- error will result.
-
-3.2.2. Responses
-
- 211 n f l s group selected
- (n = estimated number of articles in group,
- f = first article number in the group,
- l = last article number in the group,
- s = name of the group.)
- 411 no such news group
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 11]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.3. The HELP command
-
-3.3.1. HELP
-
- HELP
-
- Provides a short summary of commands that are understood by this
- implementation of the server. The help text will be presented as a
- textual response, terminated by a single period on a line by itself.
-
- 3.3.2. Responses
-
- 100 help text follows
-
-3.4. The IHAVE command
-
-3.4.1. IHAVE
-
- IHAVE <messageid>
-
- The IHAVE command informs the server that the client has an article
- whose id is <messageid>. If the server desires a copy of that
- article, it will return a response instructing the client to send the
- entire article. If the server does not want the article (if, for
- example, the server already has a copy of it), a response indicating
- that the article is not wanted will be returned.
-
- If transmission of the article is requested, the client should send
- the entire article, including header and body, in the manner
- specified for text transmission from the server. A response code
- indicating success or failure of the transferral of the article will
- be returned.
-
- This function differs from the POST command in that it is intended
- for use in transferring already-posted articles between hosts.
- Normally it will not be used when the client is a personal
- newsreading program. In particular, this function will invoke the
- server's news posting program with the appropriate settings (flags,
- options, etc) to indicate that the forthcoming article is being
- forwarded from another host.
-
- The server may, however, elect not to post or forward the article if
- after further examination of the article it deems it inappropriate to
- do so. The 436 or 437 error codes may be returned as appropriate to
- the situation.
-
- Reasons for such subsequent rejection of an article may include such
-
-
-Kantor & Lapsley [Page 12]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- problems as inappropriate newsgroups or distributions, disk space
- limitations, article lengths, garbled headers, and the like. These
- are typically restrictions enforced by the server host's news
- software and not necessarily the NNTP server itself.
-
-3.4.2. Responses
-
- 235 article transferred ok
- 335 send article to be transferred. End with <CR-LF>.<CR-LF>
- 435 article not wanted - do not send it
- 436 transfer failed - try again later
- 437 article rejected - do not try again
-
- An implementation note:
-
- Because some host news posting software may not be able to decide
- immediately that an article is inappropriate for posting or
- forwarding, it is acceptable to acknowledge the successful transfer
- of the article and to later silently discard it. Thus it is
- permitted to return the 235 acknowledgement code and later discard
- the received article. This is not a fully satisfactory solution to
- the problem. Perhaps some implementations will wish to send mail to
- the author of the article in certain of these cases.
-
-3.5. The LAST command
-
-3.5.1. LAST
-
- LAST
-
- The internally maintained "current article pointer" is set to the
- previous article in the current newsgroup. If already positioned at
- the first article of the newsgroup, an error message is returned and
- the current article remains selected.
-
- The internally-maintained "current article pointer" is set by this
- command.
-
- A response indicating the current article number, and a message-id
- string will be returned. No text is sent in response to this
- command.
-
-3.5.2. Responses
-
- 223 n a article retrieved - request text separately
- (n = article number, a = unique article id)
-
-
-
-Kantor & Lapsley [Page 13]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- 412 no newsgroup selected
- 420 no current article has been selected
- 422 no previous article in this group
-
-3.6. The LIST command
-
-3.6.1. LIST
-
- LIST
-
- Returns a list of valid newsgroups and associated information. Each
- newsgroup is sent as a line of text in the following format:
-
- group last first p
-
- where <group> is the name of the newsgroup, <last> is the number of
- the last known article currently in that newsgroup, <first> is the
- number of the first article currently in the newsgroup, and <p> is
- either 'y' or 'n' indicating whether posting to this newsgroup is
- allowed ('y') or prohibited ('n').
-
- The <first> and <last> fields will always be numeric. They may have
- leading zeros. If the <last> field evaluates to less than the
- <first> field, there are no articles currently on file in the
- newsgroup.
-
- Note that posting may still be prohibited to a client even though the
- LIST command indicates that posting is permitted to a particular
- newsgroup. See the POST command for an explanation of client
- prohibitions. The posting flag exists for each newsgroup because
- some newsgroups are moderated or are digests, and therefore cannot be
- posted to; that is, articles posted to them must be mailed to a
- moderator who will post them for the submitter. This is independent
- of the posting permission granted to a client by the NNTP server.
-
- Please note that an empty list (i.e., the text body returned by this
- command consists only of the terminating period) is a possible valid
- response, and indicates that there are currently no valid newsgroups.
-
-3.6.2. Responses
-
- 215 list of newsgroups follows
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 14]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.7. The NEWGROUPS command
-
-3.7.1. NEWGROUPS
-
- NEWGROUPS date time [GMT] [<distributions>]
-
- A list of newsgroups created since <date and time> will be listed in
- the same format as the LIST command.
-
- The date is sent as 6 digits in the format YYMMDD, where YY is the
- last two digits of the year, MM is the two digits of the month (with
- leading zero, if appropriate), and DD is the day of the month (with
- leading zero, if appropriate). The closest century is assumed as
- part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is
- 1999, 00 is 2000).
-
- Time must also be specified. It must be as 6 digits HHMMSS with HH
- being hours on the 24-hour clock, MM minutes 00-59, and SS seconds
- 00-59. The time is assumed to be in the server's timezone unless the
- token "GMT" appears, in which case both time and date are evaluated
- at the 0 meridian.
-
- The optional parameter "distributions" is a list of distribution
- groups, enclosed in angle brackets. If specified, the distribution
- portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be
- examined for a match with the distribution categories listed, and
- only those new newsgroups which match will be listed. If more than
- one distribution group is to be listed, they must be separated by
- commas within the angle brackets.
-
- Please note that an empty list (i.e., the text body returned by this
- command consists only of the terminating period) is a possible valid
- response, and indicates that there are currently no new newsgroups.
-
-3.7.2. Responses
-
- 231 list of new newsgroups follows
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 15]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.8. The NEWNEWS command
-
-3.8.1. NEWNEWS
-
- NEWNEWS newsgroups date time [GMT] [<distribution>]
-
- A list of message-ids of articles posted or received to the specified
- newsgroup since "date" will be listed. The format of the listing will
- be one message-id per line, as though text were being sent. A single
- line consisting solely of one period followed by CR-LF will terminate
- the list.
-
- Date and time are in the same format as the NEWGROUPS command.
-
- A newsgroup name containing a "*" (an asterisk) may be specified to
- broaden the article search to some or all newsgroups. The asterisk
- will be extended to match any part of a newsgroup name (e.g.,
- net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus
- if only an asterisk is given as the newsgroup name, all newsgroups
- will be searched for new news.
-
- (Please note that the asterisk "*" expansion is a general
- replacement; in particular, the specification of e.g., net.*.unix
- should be correctly expanded to embrace names such as net.wombat.unix
- and net.whocares.unix.)
-
- Conversely, if no asterisk appears in a given newsgroup name, only
- the specified newsgroup will be searched for new articles. Newsgroup
- names must be chosen from those returned in the listing of available
- groups. Multiple newsgroup names (including a "*") may be specified
- in this command, separated by a comma. No comma shall appear after
- the last newsgroup in the list. [Implementors are cautioned to keep
- the 512 character command length limit in mind.]
-
- The exclamation point ("!") may be used to negate a match. This can
- be used to selectively omit certain newsgroups from an otherwise
- larger list. For example, a newsgroups specification of
- "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and
- all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be
- matched. If used, the exclamation point must appear as the first
- character of the given newsgroup name or pattern.
-
- The optional parameter "distributions" is a list of distribution
- groups, enclosed in angle brackets. If specified, the distribution
- portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will
- be examined for a match with the distribution categories listed, and
- only those articles which have at least one newsgroup belonging to
-
-
-Kantor & Lapsley [Page 16]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- the list of distributions will be listed. If more than one
- distribution group is to be supplied, they must be separated by
- commas within the angle brackets.
-
- The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute
- news is discussed in an earlier part of this document.
-
- Please note that an empty list (i.e., the text body returned by this
- command consists only of the terminating period) is a possible valid
- response, and indicates that there is currently no new news.
-
-3.8.2. Responses
-
- 230 list of new articles by message-id follows
-
-3.9. The NEXT command
-
-3.9.1. NEXT
-
- NEXT
-
- The internally maintained "current article pointer" is advanced to
- the next article in the current newsgroup. If no more articles
- remain in the current group, an error message is returned and the
- current article remains selected.
-
- The internally-maintained "current article pointer" is set by this
- command.
-
- A response indicating the current article number, and the message-id
- string will be returned. No text is sent in response to this
- command.
-
-3.9.2. Responses
-
- 223 n a article retrieved - request text separately
- (n = article number, a = unique article id)
- 412 no newsgroup selected
- 420 no current article has been selected
- 421 no next article in this group
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 17]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-3.10. The POST command
-
-3.10.1. POST
-
- POST
-
- If posting is allowed, response code 340 is returned to indicate that
- the article to be posted should be sent. Response code 440 indicates
- that posting is prohibited for some installation-dependent reason.
-
- If posting is permitted, the article should be presented in the
- format specified by RFC850, and should include all required header
- lines. After the article's header and body have been completely sent
- by the client to the server, a further response code will be returned
- to indicate success or failure of the posting attempt.
-
- The text forming the header and body of the message to be posted
- should be sent by the client using the conventions for text received
- from the news server: A single period (".") on a line indicates the
- end of the text, with lines starting with a period in the original
- text having that period doubled during transmission.
-
- No attempt shall be made by the server to filter characters, fold or
- limit lines, or otherwise process incoming text. It is our intent
- that the server just pass the incoming message to be posted to the
- server installation's news posting software, which is separate from
- this specification. See RFC850 for more details.
-
- Since most installations will want the client news program to allow
- the user to prepare his message using some sort of text editor, and
- transmit it to the server for posting only after it is composed, the
- client program should take note of the herald message that greeted it
- when the connection was first established. This message indicates
- whether postings from that client are permitted or not, and can be
- used to caution the user that his access is read-only if that is the
- case. This will prevent the user from wasting a good deal of time
- composing a message only to find posting of the message was denied.
- The method and determination of which clients and hosts may post is
- installation dependent and is not covered by this specification.
-
-3.10.2. Responses
-
- 240 article posted ok
- 340 send article to be posted. End with <CR-LF>.<CR-LF>
- 440 posting not allowed
- 441 posting failed
-
-
-
-Kantor & Lapsley [Page 18]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- (for reference, one of the following codes will be sent upon initial
- connection; the client program should determine whether posting is
- generally permitted from these:) 200 server ready - posting allowed
- 201 server ready - no posting allowed
-
-3.11. The QUIT command
-
-3.11.1. QUIT
-
- QUIT
-
- The server process acknowledges the QUIT command and then closes the
- connection to the client. This is the preferred method for a client
- to indicate that it has finished all its transactions with the NNTP
- server.
-
- If a client simply disconnects (or the connection times out, or some
- other fault occurs), the server should gracefully cease its attempts
- to service the client.
-
-3.11.2. Responses
-
- 205 closing connection - goodbye!
-
-3.12. The SLAVE command
-
-3.12.1. SLAVE
-
- SLAVE
-
- Indicates to the server that this client connection is to a slave
- server, rather than a user.
-
- This command is intended for use in separating connections to single
- users from those to subsidiary ("slave") servers. It may be used to
- indicate that priority should therefore be given to requests from
- this client, as it is presumably serving more than one person. It
- might also be used to determine which connections to close when
- system load levels are exceeded, perhaps giving preference to slave
- servers. The actual use this command is put to is entirely
- implementation dependent, and may vary from one host to another. In
- NNTP servers which do not give priority to slave servers, this
- command must nonetheless be recognized and acknowledged.
-
-3.12.2. Responses
-
- 202 slave status noted
-
-
-Kantor & Lapsley [Page 19]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-4. Sample Conversations
-
- These are samples of the conversations that might be expected with
- the news server in hypothetical sessions. The notation C: indicates
- commands sent to the news server from the client program; S: indicate
- responses received from the server by the client.
-
-4.1. Example 1 - relative access with NEXT
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 200 wombatvax news server ready - posting ok
-
- (client asks for a current newsgroup list)
- C: LIST
- S: 215 list of newsgroups follows
- S: net.wombats 00543 00501 y
- S: net.unix-wizards 10125 10011 y
- (more information here)
- S: net.idiots 00100 00001 n
- S: .
-
- (client selects a newsgroup)
- C: GROUP net.unix-wizards
- S: 211 104 10011 10125 net.unix-wizards group selected
- (there are 104 articles on file, from 10011 to 10125)
-
- (client selects an article to read)
- C: STAT 10110
- S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
- only (article 10110 selected, its message-id is
- <23445@sdcsvax.ARPA>)
-
- (client examines the header)
- C: HEAD
- S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head
- follows (text of the header appears here)
- S: .
-
- (client wants to see the text body of the article)
- C: BODY
- S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body
- follows (body text here)
- S: .
-
- (client selects next article in group)
-
-
-Kantor & Lapsley [Page 20]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- C: NEXT
- S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics
- only (article 10113 was next in group)
-
- (client finishes session)
- C: QUIT
- S: 205 goodbye.
-
-4.2. Example 2 - absolute article access with ARTICLE
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 201 UCB-VAX netnews server ready -- no posting allowed
-
- C: GROUP msgs
- S: 211 103 402 504 msgs Your new group is msgs
- (there are 103 articles, from 402 to 504)
-
- C: ARTICLE 401
- S: 423 No such article in this newsgroup
-
- C: ARTICLE 402
- S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
- S: (article header and body follow)
- S: .
-
- C: HEAD 403
- S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows
- S: (article header follows)
- S: .
-
- C: QUIT
- S: 205 UCB-VAX news server closing connection. Goodbye.
-
-4.3. Example 3 - NEWGROUPS command
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 200 Imaginary Institute News Server ready (posting ok)
-
- (client asks for new newsgroups since April 3, 1985)
- C: NEWGROUPS 850403 020000
-
- S: 231 New newsgroups since 03/04/85 02:00:00 follow
-
-
-
-Kantor & Lapsley [Page 21]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- S: net.music.gdead
- S: net.games.sources
- S: .
-
- C: GROUP net.music.gdead
- S: 211 0 1 1 net.music.gdead Newsgroup selected
- (there are no articles in that newsgroup, and
- the first and last article numbers should be ignored)
-
- C: QUIT
- S: 205 Imaginary Institute news server ceasing service. Bye!
-
-4.4. Example 4 - posting a news article
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 200 BANZAIVAX news server ready, posting allowed.
-
- C: POST
- S: 340 Continue posting; Period on a line by itself to end
- C: (transmits news article in RFC850 format)
- C: .
- S: 240 Article posted successfully.
-
- C: QUIT
- S: 205 BANZAIVAX closing connection. Goodbye.
-
-4.5. Example 5 - interruption due to operator request
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 201 genericvax news server ready, no posting allowed.
-
- (assume normal conversation for some time, and
- that a newsgroup has been selected)
-
- C: NEXT
- S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
-
- C: HEAD
- C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
-
- S: (sends head of article, but halfway through is
- interrupted by an operator request. The following
- then occurs, without client intervention.)
-
-
-Kantor & Lapsley [Page 22]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- S: (ends current line with a CR-LF pair)
- S: .
- S: 400 Connection closed by operator. Goodbye.
- S: (closes connection)
-
-4.6. Example 6 - Using the news server to distribute news between
- systems.
-
- S: (listens at TCP port 119)
-
- C: (requests connection on TCP port 119)
- S: 201 Foobar NNTP server ready (no posting)
-
- (client asks for new newsgroups since 2 am, May 15, 1985)
- C: NEWGROUPS 850515 020000
- S: 235 New newsgroups since 850515 follow
- S: net.fluff
- S: net.lint
- S: .
-
- (client asks for new news articles since 2 am, May 15, 1985)
- C: NEWNEWS * 850515 020000
- S: 230 New news since 850515 020000 follows
- S: <1772@foo.UUCP>
- S: <87623@baz.UUCP>
- S: <17872@GOLD.CSNET>
- S: .
-
- (client asks for article <1772@foo.UUCP>)
- C: ARTICLE <1772@foo.UUCP>
- S: 220 <1772@foo.UUCP> All of article follows
- S: (sends entire message)
- S: .
-
- (client asks for article <87623@baz.UUCP>
- C: ARTICLE <87623@baz.UUCP>
- S: 220 <87623@baz.UUCP> All of article follows
- S: (sends entire message)
- S: .
-
- (client asks for article <17872@GOLD.CSNET>
- C: ARTICLE <17872@GOLD.CSNET>
- S: 220 <17872@GOLD.CSNET> All of article follows
- S: (sends entire message)
- S: .
-
-
-
-
-Kantor & Lapsley [Page 23]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- (client offers an article it has received recently)
- C: IHAVE <4105@ucbvax.ARPA>
- S: 435 Already seen that one, where you been?
-
- (client offers another article)
- C: IHAVE <4106@ucbvax.ARPA>
- S: 335 News to me! <CRLF.CRLF> to end.
- C: (sends article)
- C: .
- S: 235 Article transferred successfully. Thanks.
-
- (or)
-
- S: 436 Transfer failed.
-
- (client is all through with the session)
- C: QUIT
- S: 205 Foobar NNTP server bids you farewell.
-
-4.7. Summary of commands and responses.
-
- The following are the commands recognized and responses returned by
- the NNTP server.
-
-4.7.1. Commands
-
- ARTICLE
- BODY
- GROUP
- HEAD
- HELP
- IHAVE
- LAST
- LIST
- NEWGROUPS
- NEWNEWS
- NEXT
- POST
- QUIT
- SLAVE
- STAT
-
-4.7.2. Responses
-
- 100 help text follows
- 199 debug output
-
-
-
-Kantor & Lapsley [Page 24]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- 200 server ready - posting allowed
- 201 server ready - no posting allowed
- 202 slave status noted
- 205 closing connection - goodbye!
- 211 n f l s group selected
- 215 list of newsgroups follows
- 220 n <a> article retrieved - head and body follow 221 n <a> article
- retrieved - head follows
- 222 n <a> article retrieved - body follows
- 223 n <a> article retrieved - request text separately 230 list of new
- articles by message-id follows
- 231 list of new newsgroups follows
- 235 article transferred ok
- 240 article posted ok
-
- 335 send article to be transferred. End with <CR-LF>.<CR-LF>
- 340 send article to be posted. End with <CR-LF>.<CR-LF>
-
- 400 service discontinued
- 411 no such news group
- 412 no newsgroup has been selected
- 420 no current article has been selected
- 421 no next article in this group
- 422 no previous article in this group
- 423 no such article number in this group
- 430 no such article found
- 435 article not wanted - do not send it
- 436 transfer failed - try again later
- 437 article rejected - do not try again.
- 440 posting not allowed
- 441 posting failed
-
- 500 command not recognized
- 501 command syntax error
- 502 access restriction or permission denied
- 503 program fault - command not performed
-
-4.8. A Brief Word about the USENET News System
-
- In the UNIX world, which traditionally has been linked by 1200 baud
- dial-up telephone lines, the USENET News system has evolved to handle
- central storage, indexing, retrieval, and distribution of news. With
- the exception of its underlying transport mechanism (UUCP), USENET
- News is an efficient means of providing news and bulletin service to
- subscribers on UNIX and other hosts worldwide. The USENET News
-
-
-
-
-Kantor & Lapsley [Page 25]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
- system is discussed in detail in RFC 850. It runs on most versions
- of UNIX and on many other operating systems, and is customarily
- distributed without charge.
-
- USENET uses a spooling area on the UNIX host to store news articles,
- one per file. Each article consists of a series of heading text,
- which contain the sender's identification and organizational
- affiliation, timestamps, electronic mail reply paths, subject,
- newsgroup (subject category), and the like. A complete news article
- is reproduced in its entirety below. Please consult RFC 850 for more
- details.
-
- Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
- sdcsvax.UUCP
- Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
- Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
- !honman
- From: honman@unitek.uucp (Man Wong)
- Newsgroups: net.unix-wizards
- Subject: foreground -> background ?
- Message-ID: <167@unitek.uucp>
- Date: 25 Sep 85 23:51:52 GMT
- Date-Received: 29 Sep 85 09:54:48 GMT
- Reply-To: honman@unitek.UUCP (Hon-Man Wong)
- Distribution: net.all
- Organization: Unitek Technologies Corporation
- Lines: 12
-
- I have a process (C program) which generates a child and waits for
- it to return. What I would like to do is to be able to run the
- child process interactively for a while before kicking itself into
- the background so I can return to the parent process (while the
- child process is RUNNING in the background). Can it be done? And
- if it can, how?
-
- Please reply by E-mail. Thanks in advance.
-
- Hon-Man Wong
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 26]
-
-
-
-RFC 977 February 1986
-Network News Transfer Protocol
-
-
-5. References
-
- [1] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", RFC-822, Department of Electrical Engineering,
- University of Delaware, August, 1982.
-
- [2] Horton, M., "Standard for Interchange of USENET Messages",
- RFC-850, USENET Project, June, 1983.
-
- [3] Postel, J., "Transmission Control Protocol- DARPA Internet
- Program Protocol Specification", RFC-793, USC/Information
- Sciences Institute, September, 1981.
-
- [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,
- USC/Information Sciences Institute, August, 1982.
-
-6. Acknowledgements
-
- The authors wish to express their heartfelt thanks to those many
- people who contributed to this specification, and especially to Erik
- Fair and Chuq von Rospach, without whose inspiration this whole thing
- would not have been necessary.
-
-7. Notes
-
- <1> UNIX is a trademark of Bell Laboratories.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kantor & Lapsley [Page 27]
-
|