+++ /dev/null
-\r
-Network Working Group J Klensin\r
-Internet Draft R Catoe\r
-Document: draft-klensin-cram-03.txt P Krumviede \r
- MCI\r
- September 1996\r
-\r
-\r
-\r
-\r
- IMAP/POP AUTHorize Extension for Simple Challenge/Response\r
-\r
-Status of this Memo\r
-\r
- This document is an Internet Draft. Internet Drafts are working\r
- documents of the Internet Engineering Task Force (IETF), its Areas,\r
- and its Working Groups. Note that other groups may also distribute\r
- working documents as Internet Drafts.\r
-\r
- Internet Drafts are draft documents valid for a maximum of six\r
- months. Internet Drafts may be updated, replaced, or obsoleted by\r
- other documents at any time. It is not appropriate to use Internet\r
- Drafts as reference material or to cite them other than as a\r
- ``working draft'' or ``work in progress``.\r
-\r
- To learn the current status of any Internet-Draft, please check the\r
- 1id-abstracts.txt listing contained in the Internet-Drafts Shadow\r
- Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or\r
- munnari.oz.au.\r
-\r
- A revised version of this draft document will be submitted to the\r
- IESG for processing as a Proposed Standard for the Internet\r
- Community, updating RFC 1731. Discussion and suggestions for\r
- improvement are requested. This document reflects editorial\r
- comments received during the last call period; the protocol is\r
- unchanged from the previous version. This draft will expire\r
- before February 22, 1997. Distribution of this draft is\r
- unlimited. \r
-\r
-\r
-Abstract\r
-\r
- While IMAP4 supports a number of strong authentication mechanisms\r
- as described in RFC 1731, it lacks any mechanism that neither passes\r
- cleartext, reusable passwords across the network nor requires either a\r
- significant security infrastructure or that the mail server update a\r
- mail-system-wide user authentication file on each mail access. This\r
- specification provides a simple challenge-response authentication\r
- protocol that is suitable for use with IMAP4. Since it utilizes\r
- Keyed-MD5 digests and does not require that the secret be stored in the\r
- clear on the server, it may also constitute an improvement on APOP for\r
- POP3 use as specified in RFC 1734.\r
-\r
-1. Introduction\r
-\r
- Existing Proposed Standards specify an AUTHENTICATE mechanism for\r
- the IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for \r
- the POP3 protocol [POP3-AUTH]. The AUTHENTICATE mechanism is intended\r
- to be extensible; the four methods specified in [IMAP-AUTH] are all\r
- fairly powerful and require some security infrastructure to support.\r
- The base POP3 specification [POP3] also contains a lightweight\r
- challenge-response mechanism called APOP. APOP is associated with\r
- most of the risks associated with such protocols: in particular, it\r
- requires that both the client and server machines have access to the\r
- shared secret in cleartext form. CRAM offers a method for avoiding\r
- such cleartext storage while retaining the algorithmic simplicity\r
- of APOP in using only MD5, though in a "keyed" method.\r
-\r
- At present, IMAP [IMAP] lacks any facility corresponding to APOP.\r
- The only alternative to the strong mechanisms identified in\r
- [IMAP-AUTH] is a presumably cleartext username and password,\r
- supported through the LOGIN command in [IMAP]. This document\r
- describes a simple challenge-response mechanism, similar to APOP and\r
- PPP CHAP [PPP], that can be used with IMAP (and, in principle, with\r
- POP3).\r
-\r
- This mechanism also has the advantage over some possible\r
- alternatives of not requiring that the server maintain information\r
- about email "logins" on a per-login basis. While mechanisms that\r
- do require such per-login history records may offer enhanced\r
- security, protocols such as IMAP, which may have several\r
- connections between a given client and server open more or less\r
- simultaneous, may make their implementation particularly\r
- challenging. \r
-\r
-\r
-2. Challenge-Response Authentication Mechanism (CRAM)\r
-\r
- The authentication type associated with CRAM is "CRAM-MD5".\r
-\r
- The data encoded in the first ready response contains an\r
- presumptively arbitrary string of random digits, a timestamp,\r
- and the fully-qualified primary host name of the server. The\r
- syntax of the unencoded form must correspond to that of an\r
- RFC 822 'msg-id' [RFC822] as described in [POP3].\r
-\r
- The client makes note of the data and then responds with a string\r
- consisting of the user name, a space, and a 'digest'. The latter is\r
- computed by applying the keyed MD5 algorithm from [KEYED-MD5]\r
- where the key is a shared secret and the digested text is\r
- the timestamp (including angle-brackets). \r
-\r
- This shared secret is a string known only to the client and server.\r
- The `digest' parameter itself is a 16-octet value which is\r
- sent in hexadecimal format, using lower-case ASCII characters. \r
-\r
- When the server receives this client response, it verifies the digest\r
- provided. If the digest is correct, the server should consider the\r
- client authenticated and respond appropriately.\r
-\r
- Keyed MD5 is chosen for this application because of the greater\r
- security imparted to authentication of short messages. In addition,\r
- the use of the techniques described in [KEYED-MD5] for\r
- precomputation of intermediate results make it possible to avoid \r
- explicit cleartext storage of the shared secret on the server system\r
- by instead storing the intermediate results which are known as\r
- "contexts". \r
- \r
- CRAM does not support a protection mechanism.\r
-\r
-\r
- Example:\r
-\r
- The examples in this document show the use of the CRAM mechanism with\r
- the IMAP4 AUTHENTICATE command [IMAP-AUTH]. The base64 encoding of\r
- the challenges and responses is part of the IMAP4 AUTHENTICATE\r
- command, not part of the CRAM specification itself.\r
-\r
- S: * OK IMAP4 Server\r
- C: A0001 AUTHENTICATE CRAM-MD5\r
- S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+\r
- C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw\r
- S: A0001 OK CRAM authentication successful\r
-\r
- In this example, the shared secret is the string 'tanstaaftanstaaf'.\r
- Hence, the Keyed MD5 digest is produced by calculating\r
-\r
- MD5((tanstaaftanstaaf XOR opad),\r
- MD5((tanstaaftanstaaf XOR ipad),\r
- <1896.697170952@postoffice.reston.mci.net>))\r
-\r
- where ipad and opad are as defined in the keyed-MD5 draft\r
- [KEYED-MD5] and the string shown in the challenge is the base64\r
- encoding of <1896.697170952@postoffice.reston.mci.net>. The\r
- shared secret is null-padded to a length of 64 bytes. If the\r
- shared secret is longer than 64 bytes, the MD5 digest of the\r
- shared secret is used as a 16 byte input to the keyed MD5\r
- calculation.\r
-\r
- This produces a digest value (in hexadecimal) of\r
-\r
-\r
- b913a602c7eda7a495b4e6e7334d3890\r
-\r
- The user name is then prepended to it, forming\r
-\r
- tim b913a602c7eda7a495b4e6e7334d3890\r
-\r
- Which is then base64 encoded to meet the requirements of the IMAP4\r
- AUTHENTICATE command (or the similar POP3 AUTH command), yielding\r
-\r
- dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw\r
-\r
-\r
-\r
-3. References\r
-\r
- [CHAP] Lloyd, B. and W. Simpson, "PPP Authentication Protocols",\r
- RFC 1334, October 1992.\r
-\r
- [IMAP] Crispin, M. "Internet Message Access Protocol - Version 4",\r
- RFC 1730, University of Washington, December, 1994.\r
-\r
- [IMAP-AUTH] Myers, J. "IMAP4 Authentication Mechanisms", \r
- RFC 1731, Carnegie Mellon, December, 1994\r
-\r
- [KEYED-MD5] Krawczyk, H "HMAC-MD5: Keyed-MD5 for Message\r
- Authentication" work in progess (draft-ietf-ipsec-hmac-md5-00.txt),\r
- IBM, March 1996. \r
-\r
- [MD5] Rivest, R. "The MD5 Message Digest Algorithm",\r
- RFC 1321, MIT Laboratory for Computer Science, April, 1992. \r
- \r
- [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3 ",\r
- RFC 1939 (STD 53), Carnegie Mellon, May 1996.\r
-\r
- [POP3-AUTH] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie\r
- Mellon, December, 1994.\r
-\r
-\r
-4. Security Considerations\r
-\r
- It is conjectured that use of the CRAM authentication mechanism\r
- provides origin identification and replay protection for a session.\r
- Accordingly, a server that implements both a cleartext password\r
- command and this authentication type should not allow both methods of\r
- access for a given user.\r
-\r
- While the saving, on the server, of "contexts" (see section 2) is\r
- marginally better than saving the shared secrets in cleartext as is\r
- required by CHAP [CHAP] and APOP [POP3], it is not sufficient to\r
- protect the secrets if the server itself is compromised.\r
- Consequently, servers that store the secrets or contexts must both\r
- be protected to a level appropriate to the potential information\r
- value in user mailboxes and identities.\r
-\r
- As the length of the shared secret increases, so does the difficulty\r
- of deriving it.\r
-\r
- While there are now suggestions in the literature that the use of\r
- MD5 and keyed MD5 in authentication procedures probably has a\r
- limited effective lifetime, the technique is now widely deployed and\r
- widely understood. It is believed that this general understanding\r
- may assist with the rapid replacement, by CRAM-MD5, of the current\r
- uses of permanent cleartext passwords in IMAP. This document has\r
- been deliberately written to permit easy upgrading to use SHA (or\r
- whatever alternatives emerge) when they are considered to be widely\r
- available and adequately safe.\r
-\r
- Even with the use of CRAM, users are still vulnerable to active\r
- attacks. An example of an increasingly common active attack is 'TCP\r
- Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].\r
-\r
- See section 1 above for additional discussion.\r
-\r
-\r
-5. Acknowledgements\r
-\r
- This memo borrows ideas and some text liberally from [POP3] and\r
- [RFC-1731] and thanks are due the authors of those documents. Ran\r
- Atkinson made a number of valuable technical and editorial\r
- contributions to the current draft.\r
-\r
-\r
-6. Authors' Addresses\r
-\r
- John C. Klensin\r
- MCI Telecommunications\r
- 800 Boylston St, 7th floor\r
- Boston, MA 02199\r
- USA\r
- Email: klensin@mci.net\r
- Tel: +1 617 960 1011\r
-\r
- Randy Catoe\r
- MCI Telecommunications\r
- 2100 Reston Parkway\r
- Reston, VA 22091\r
- USA\r
- Email: randy@mci.net\r
- Tel: +1 703 715 7366\r
-\r
- Paul Krumviede\r
- MCI Telecommunications\r
- 2100 Reston Parkway\r
- Reston, VA 22091\r
- USA\r
- Email: paul@mci.net\r
- Tel: +1 703 715 7251\r
-\r
-\r
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
+++ /dev/null
-
- 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
------- ----------- ------------------- ------- -------------------------------
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
-
-
-
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
\ No newline at end of file
+++ /dev/null
-\r
-\r
-\r
-\r
-\r
-\r
-Network Working Group N. Borenstein\r
-Request for Comments: 1521 Bellcore\r
-Obsoletes: 1341 N. Freed\r
-Category: Standards Track Innosoft\r
- September 1993\r
-\r
-\r
- MIME (Multipurpose Internet Mail Extensions) Part One:\r
- Mechanisms for Specifying and Describing\r
- the Format of Internet Message Bodies\r
-\r
-Status of this Memo\r
-\r
- This RFC specifies an Internet standards track protocol for the\r
- Internet community, and requests discussion and suggestions for\r
- improvements. Please refer to the current edition of the "Internet\r
- Official Protocol Standards" for the standardization state and status\r
- of this protocol. Distribution of this memo is unlimited.\r
-\r
-Abstract\r
-\r
- STD 11, RFC 822 defines a message representation protocol which\r
- specifies considerable detail about message headers, but which leaves\r
- the message content, or message body, as flat ASCII text. This\r
- document redefines the format of message bodies to allow multi-part\r
- textual and non-textual message bodies to be represented and\r
- exchanged without loss of information. This is based on earlier work\r
- documented in RFC 934 and STD 11, RFC 1049, but extends and revises\r
- that work. Because RFC 822 said so little about message bodies, this\r
- document is largely orthogonal to (rather than a revision of) RFC\r
- 822.\r
-\r
- In particular, this document is designed to provide facilities to\r
- include multiple objects in a single message, to represent body text\r
- in character sets other than US-ASCII, to represent formatted multi-\r
- font text messages, to represent non-textual material such as images\r
- and audio fragments, and generally to facilitate later extensions\r
- defining new types of Internet mail for use by cooperating mail\r
- agents.\r
-\r
- This document does NOT extend Internet mail header fields to permit\r
- anything other than US-ASCII text data. Such extensions are the\r
- subject of a companion document [RFC-1522].\r
-\r
- This document is a revision of RFC 1341. Significant differences\r
- from RFC 1341 are summarized in Appendix H.\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 1]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Table of Contents\r
-\r
- 1. Introduction....................................... 3\r
- 2. Notations, Conventions, and Generic BNF Grammar.... 6\r
- 3. The MIME-Version Header Field...................... 7\r
- 4. The Content-Type Header Field...................... 9\r
- 5. The Content-Transfer-Encoding Header Field......... 13\r
- 5.1. Quoted-Printable Content-Transfer-Encoding......... 18\r
- 5.2. Base64 Content-Transfer-Encoding................... 21\r
- 6. Additional Content-Header Fields................... 23\r
- 6.1. Optional Content-ID Header Field................... 23\r
- 6.2. Optional Content-Description Header Field.......... 24\r
- 7. The Predefined Content-Type Values................. 24\r
- 7.1. The Text Content-Type.............................. 24\r
- 7.1.1. The charset parameter.............................. 25\r
- 7.1.2. The Text/plain subtype............................. 28\r
- 7.2. The Multipart Content-Type......................... 28\r
- 7.2.1. Multipart: The common syntax...................... 29\r
- 7.2.2. The Multipart/mixed (primary) subtype.............. 34\r
- 7.2.3. The Multipart/alternative subtype.................. 34\r
- 7.2.4. The Multipart/digest subtype....................... 36\r
- 7.2.5. The Multipart/parallel subtype..................... 37\r
- 7.2.6. Other Multipart subtypes........................... 37\r
- 7.3. The Message Content-Type........................... 38\r
- 7.3.1. The Message/rfc822 (primary) subtype............... 38\r
- 7.3.2. The Message/Partial subtype........................ 39\r
- 7.3.3. The Message/External-Body subtype.................. 42\r
- 7.3.3.1. The "ftp" and "tftp" access-types............... 44\r
- 7.3.3.2. The "anon-ftp" access-type...................... 45\r
- 7.3.3.3. The "local-file" and "afs" access-types......... 45\r
- 7.3.3.4. The "mail-server" access-type................... 45\r
- 7.3.3.5. Examples and Further Explanations............... 46\r
- 7.4. The Application Content-Type....................... 49\r
- 7.4.1. The Application/Octet-Stream (primary) subtype..... 50\r
- 7.4.2. The Application/PostScript subtype................. 50\r
- 7.4.3. Other Application subtypes......................... 53\r
- 7.5. The Image Content-Type............................. 53\r
- 7.6. The Audio Content-Type............................. 54\r
- 7.7. The Video Content-Type............................. 54\r
- 7.8. Experimental Content-Type Values................... 54\r
- 8. Summary............................................ 56\r
- 9. Security Considerations............................ 56\r
- 10. Authors' Addresses................................. 57\r
- 11. Acknowledgements................................... 58\r
- Appendix A -- Minimal MIME-Conformance.................... 60\r
- Appendix B -- General Guidelines For Sending Email Data... 63\r
- Appendix C -- A Complex Multipart Example................. 66\r
- Appendix D -- Collected Grammar........................... 68\r
-\r
-\r
-\r
-Borenstein & Freed [Page 2]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Appendix E -- IANA Registration Procedures................ 72\r
- E.1 Registration of New Content-type/subtype Values...... 72\r
- E.2 Registration of New Access-type Values\r
- for Message/external-body............................ 73\r
- Appendix F -- Summary of the Seven Content-types.......... 74\r
- Appendix G -- Canonical Encoding Model.................... 76\r
- Appendix H -- Changes from RFC 1341....................... 78\r
- References................................................ 80\r
-\r
-1. Introduction\r
-\r
- Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined\r
- the standard format of textual mail messages on the Internet. Its\r
- success has been such that the RFC 822 format has been adopted,\r
- wholly or partially, well beyond the confines of the Internet and the\r
- Internet SMTP transport defined by STD 10, RFC 821 [RFC-821]. As the\r
- format has seen wider use, a number of limitations have proven\r
- increasingly restrictive for the user community.\r
-\r
- RFC 822 was intended to specify a format for text messages. As such,\r
- non-text messages, such as multimedia messages that might include\r
- audio or images, are simply not mentioned. Even in the case of text,\r
- however, RFC 822 is inadequate for the needs of mail users whose\r
- languages require the use of character sets richer than US ASCII\r
- [US-ASCII]. Since RFC 822 does not specify mechanisms for mail\r
- containing audio, video, Asian language text, or even text in most\r
- European languages, additional specifications are needed.\r
-\r
- One of the notable limitations of RFC 821/822 based mail systems is\r
- the fact that they limit the contents of electronic mail messages to\r
- relatively short lines of seven-bit ASCII. This forces users to\r
- convert any non-textual data that they may wish to send into seven-\r
- bit bytes representable as printable ASCII characters before invoking\r
- a local mail UA (User Agent, a program with which human users send\r
- and receive mail). Examples of such encodings currently used in the\r
- Internet include pure hexadecimal, uuencode, the 3-in-4 base 64\r
- scheme specified in RFC 1421, the Andrew Toolkit Representation\r
- [ATK], and many others.\r
-\r
- The limitations of RFC 822 mail become even more apparent as gateways\r
- are designed to allow for the exchange of mail messages between RFC\r
- 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the\r
- inclusion of non-textual body parts within electronic mail messages.\r
- The current standards for the mapping of X.400 messages to RFC 822\r
- messages specify either that X.400 non-textual body parts must be\r
- converted to (not encoded in) an ASCII format, or that they must be\r
- discarded, notifying the RFC 822 user that discarding has occurred.\r
- This is clearly undesirable, as information that a user may wish to\r
-\r
-\r
-\r
-Borenstein & Freed [Page 3]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- receive is lost. Even though a user's UA may not have the capability\r
- of dealing with the non-textual body part, the user might have some\r
- mechanism external to the UA that can extract useful information from\r
- the body part. Moreover, it does not allow for the fact that the\r
- message may eventually be gatewayed back into an X.400 message\r
- handling system (i.e., the X.400 message is "tunneled" through\r
- Internet mail), where the non-textual information would definitely\r
- become useful again.\r
-\r
- This document describes several mechanisms that combine to solve most\r
- of these problems without introducing any serious incompatibilities\r
- with the existing world of RFC 822 mail. In particular, it\r
- describes:\r
-\r
- 1. A MIME-Version header field, which uses a version number to\r
- declare a message to be conformant with this specification and\r
- allows mail processing agents to distinguish between such\r
- messages and those generated by older or non-conformant software,\r
- which is presumed to lack such a field.\r
-\r
- 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],\r
- which can be used to specify the type and subtype of data in the\r
- body of a message and to fully specify the native representation\r
- (encoding) of such data.\r
-\r
- 2.a. A "text" Content-Type value, which can be used to represent\r
- textual information in a number of character sets and\r
- formatted text description languages in a standardized\r
- manner.\r
-\r
- 2.b. A "multipart" Content-Type value, which can be used to\r
- combine several body parts, possibly of differing types of\r
- data, into a single message.\r
-\r
- 2.c. An "application" Content-Type value, which can be used to\r
- transmit application data or binary data, and hence, among\r
- other uses, to implement an electronic mail file transfer\r
- service.\r
-\r
- 2.d. A "message" Content-Type value, for encapsulating another\r
- mail message.\r
-\r
- 2.e An "image" Content-Type value, for transmitting still image\r
- (picture) data.\r
-\r
- 2.f. An "audio" Content-Type value, for transmitting audio or\r
- voice data.\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 4]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- 2.g. A "video" Content-Type value, for transmitting video or\r
- moving image data, possibly with audio as part of the\r
- composite video data format.\r
-\r
- 3. A Content-Transfer-Encoding header field, which can be used to\r
- specify an auxiliary encoding that was applied to the data in\r
- order to allow it to pass through mail transport mechanisms which\r
- may have data or character set limitations.\r
-\r
- 4. Two additional header fields that can be used to further describe\r
- the data in a message body, the Content-ID and Content-\r
- Description header fields.\r
-\r
- MIME has been carefully designed as an extensible mechanism, and it\r
- is expected that the set of content-type/subtype pairs and their\r
- associated parameters will grow significantly with time. Several\r
- other MIME fields, notably including character set names, are likely\r
- to have new values defined over time. In order to ensure that the\r
- set of such values is developed in an orderly, well-specified, and\r
- public manner, MIME defines a registration process which uses the\r
- Internet Assigned Numbers Authority (IANA) as a central registry for\r
- such values. Appendix E provides details about how IANA registration\r
- is accomplished.\r
-\r
- Finally, to specify and promote interoperability, Appendix A of this\r
- document provides a basic applicability statement for a subset of the\r
- above mechanisms that defines a minimal level of "conformance" with\r
- this document.\r
-\r
- HISTORICAL NOTE: Several of the mechanisms described in this\r
- document may seem somewhat strange or even baroque at first\r
- reading. It is important to note that compatibility with existing\r
- standards AND robustness across existing practice were two of the\r
- highest priorities of the working group that developed this\r
- document. In particular, compatibility was always favored over\r
- elegance.\r
-\r
- MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]\r
- [RFC-1342]. This document is a relatively minor updating of RFC\r
- 1341, and is intended to supersede it. The differences between this\r
- document and RFC 1341 are summarized in Appendix H. Please refer to\r
- the current edition of the "IAB Official Protocol Standards" for the\r
- standardization state and status of this protocol. Several other RFC\r
- documents will be of interest to the MIME implementor, in particular\r
- [RFC 1343], [RFC-1344], and [RFC-1345].\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 5]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-2. Notations, Conventions, and Generic BNF Grammar\r
-\r
- This document is being published in two versions, one as plain ASCII\r
- text and one as PostScript (PostScript is a trademark of Adobe\r
- Systems Incorporated.). While the text version is the official\r
- specification, some will find the PostScript version easier to read.\r
- The textual contents are identical. An Andrew-format copy of this\r
- document is also available from the first author (Borenstein).\r
-\r
- Although the mechanisms specified in this document are all described\r
- in prose, most are also described formally in the modified BNF\r
- notation of RFC 822. Implementors will need to be familiar with this\r
- notation in order to understand this specification, and are referred\r
- to RFC 822 for a complete explanation of the modified BNF notation.\r
-\r
- Some of the modified BNF in this document makes reference to\r
- syntactic entities that are defined in RFC 822 and not in this\r
- document. A complete formal grammar, then, is obtained by combining\r
- the collected grammar appendix of this document with that of RFC 822\r
- plus the modifications to RFC 822 defined in RFC 1123, which\r
- specifically changes the syntax for `return', `date' and `mailbox'.\r
-\r
- The term CRLF, in this document, refers to the sequence of the two\r
- ASCII characters CR (13) and LF (10) which, taken together, in this\r
- order, denote a line break in RFC 822 mail.\r
-\r
- The term "character set" is used in this document to refer to a\r
- method used with one or more tables to convert encoded text to a\r
- series of octets. This definition is intended to allow various kinds\r
- of text encodings, from simple single-table mappings such as ASCII to\r
- complex table switching methods such as those that use ISO 2022's\r
- techniques. However, a MIME character set name must fully specify\r
- the mapping to be performed.\r
-\r
- The term "message", when not further qualified, means either the\r
- (complete or "top-level") message being transferred on a network, or\r
- a message encapsulated in a body of type "message".\r
-\r
- The term "body part", in this document, means one of the parts of the\r
- body of a multipart entity. A body part has a header and a body, so\r
- it makes sense to speak about the body of a body part.\r
-\r
- The term "entity", in this document, means either a message or a body\r
- part. All kinds of entities share the property that they have a\r
- header and a body.\r
-\r
- The term "body", when not further qualified, means the body of an\r
- entity, that is the body of either a message or of a body part.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 6]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- NOTE: The previous four definitions are clearly circular. This is\r
- unavoidable, since the overall structure of a MIME message is\r
- indeed recursive.\r
-\r
- In this document, all numeric and octet values are given in decimal\r
- notation.\r
-\r
- It must be noted that Content-Type values, subtypes, and parameter\r
- names as defined in this document are case-insensitive. However,\r
- parameter values are case-sensitive unless otherwise specified for\r
- the specific parameter.\r
-\r
- FORMATTING NOTE: This document has been carefully formatted for\r
- ease of reading. The PostScript version of this document, in\r
- particular, places notes like this one, which may be skipped by\r
- the reader, in a smaller, italicized, font, and indents it as\r
- well. In the text version, only the indentation is preserved, so\r
- if you are reading the text version of this you might consider\r
- using the PostScript version instead. However, all such notes will\r
- be indented and preceded by "NOTE:" or some similar introduction,\r
- even in the text version.\r
-\r
- The primary purpose of these non-essential notes is to convey\r
- information about the rationale of this document, or to place this\r
- document in the proper historical or evolutionary context. Such\r
- information may be skipped by those who are focused entirely on\r
- building a conformant implementation, but may be of use to those\r
- who wish to understand why this document is written as it is.\r
-\r
- For ease of recognition, all BNF definitions have been placed in a\r
- fixed-width font in the PostScript version of this document.\r
-\r
-3. The MIME-Version Header Field\r
-\r
- Since RFC 822 was published in 1982, there has really been only one\r
- format standard for Internet messages, and there has been little\r
- perceived need to declare the format standard in use. This document\r
- is an independent document that complements RFC 822. Although the\r
- extensions in this document have been defined in such a way as to be\r
- compatible with RFC 822, there are still circumstances in which it\r
- might be desirable for a mail-processing agent to know whether a\r
- message was composed with the new standard in mind.\r
-\r
- Therefore, this document defines a new header field, "MIME-Version",\r
- which is to be used to declare the version of the Internet message\r
- body format standard in use.\r
-\r
- Messages composed in accordance with this document MUST include such\r
-\r
-\r
-\r
-Borenstein & Freed [Page 7]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- a header field, with the following verbatim text:\r
-\r
- MIME-Version: 1.0\r
-\r
- The presence of this header field is an assertion that the message\r
- has been composed in compliance with this document.\r
-\r
- Since it is possible that a future document might extend the message\r
- format standard again, a formal BNF is given for the content of the\r
- MIME-Version field:\r
-\r
- version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT\r
-\r
- Thus, future format specifiers, which might replace or extend "1.0",\r
- are constrained to be two integer fields, separated by a period. If\r
- a message is received with a MIME-version value other than "1.0", it\r
- cannot be assumed to conform with this specification.\r
-\r
- Note that the MIME-Version header field is required at the top level\r
- of a message. It is not required for each body part of a multipart\r
- entity. It is required for the embedded headers of a body of type\r
- "message" if and only if the embedded message is itself claimed to be\r
- MIME-conformant.\r
-\r
- It is not possible to fully specify how a mail reader that conforms\r
- with MIME as defined in this document should treat a message that\r
- might arrive in the future with some value of MIME-Version other than\r
- "1.0". However, conformant software is encouraged to check the\r
- version number and at least warn the user if an unrecognized MIME-\r
- version is encountered.\r
-\r
- It is also worth noting that version control for specific content-\r
- types is not accomplished using the MIME-Version mechanism. In\r
- particular, some formats (such as application/postscript) have\r
- version numbering conventions that are internal to the document\r
- format. Where such conventions exist, MIME does nothing to supersede\r
- them. Where no such conventions exist, a MIME type might use a\r
- "version" parameter in the content-type field if necessary.\r
-\r
- NOTE TO IMPLEMENTORS: All header fields defined in this document,\r
- including MIME-Version, Content-type, etc., are subject to the\r
- general syntactic rules for header fields specified in RFC 822. In\r
- particular, all can include comments, which means that the following\r
- two MIME-Version fields are equivalent:\r
-\r
- MIME-Version: 1.0\r
- MIME-Version: 1.0 (Generated by GBD-killer 3.7)\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 8]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-4. The Content-Type Header Field\r
-\r
- The purpose of the Content-Type field is to describe the data\r
- contained in the body fully enough that the receiving user agent can\r
- pick an appropriate agent or mechanism to present the data to the\r
- user, or otherwise deal with the data in an appropriate manner.\r
-\r
- HISTORICAL NOTE: The Content-Type header field was first defined in\r
- RFC 1049. RFC 1049 Content-types used a simpler and less powerful\r
- syntax, but one that is largely compatible with the mechanism given\r
- here.\r
-\r
- The Content-Type header field is used to specify the nature of the\r
- data in the body of an entity, by giving type and subtype\r
- identifiers, and by providing auxiliary information that may be\r
- required for certain types. After the type and subtype names, the\r
- remainder of the header field is simply a set of parameters,\r
- specified in an attribute/value notation. The set of meaningful\r
- parameters differs for the different types. In particular, there are\r
- NO globally-meaningful parameters that apply to all content-types.\r
- Global mechanisms are best addressed, in the MIME model, by the\r
- definition of additional Content-* header fields. The ordering of\r
- parameters is not significant. Among the defined parameters is a\r
- "charset" parameter by which the character set used in the body may\r
- be declared. Comments are allowed in accordance with RFC 822 rules\r
- for structured header fields.\r
-\r
- In general, the top-level Content-Type is used to declare the general\r
- type of data, while the subtype specifies a specific format for that\r
- type of data. Thus, a Content-Type of "image/xyz" is enough to tell\r
- a user agent that the data is an image, even if the user agent has no\r
- knowledge of the specific image format "xyz". Such information can\r
- be used, for example, to decide whether or not to show a user the raw\r
- data from an unrecognized subtype -- such an action might be\r
- reasonable for unrecognized subtypes of text, but not for\r
- unrecognized subtypes of image or audio. For this reason, registered\r
- subtypes of audio, image, text, and video, should not contain\r
- embedded information that is really of a different type. Such\r
- compound types should be represented using the "multipart" or\r
- "application" types.\r
-\r
- Parameters are modifiers of the content-subtype, and do not\r
- fundamentally affect the requirements of the host system. Although\r
- most parameters make sense only with certain content-types, others\r
- are "global" in the sense that they might apply to any subtype. For\r
- example, the "boundary" parameter makes sense only for the\r
- "multipart" content-type, but the "charset" parameter might make\r
- sense with several content-types.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 9]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- An initial set of seven Content-Types is defined by this document.\r
- This set of top-level names is intended to be substantially complete.\r
- It is expected that additions to the larger set of supported types\r
- can generally be accomplished by the creation of new subtypes of\r
- these initial types. In the future, more top-level types may be\r
- defined only by an extension to this standard. If another primary\r
- type is to be used for any reason, it must be given a name starting\r
- with "X-" to indicate its non-standard status and to avoid a\r
- potential conflict with a future official name.\r
-\r
- In the Augmented BNF notation of RFC 822, a Content-Type header field\r
- value is defined as follows:\r
-\r
- content := "Content-Type" ":" type "/" subtype *(";"\r
- parameter)\r
- ; case-insensitive matching of type and subtype\r
-\r
- type := "application" / "audio"\r
- / "image" / "message"\r
- / "multipart" / "text"\r
- / "video" / extension-token\r
- ; All values case-insensitive\r
-\r
- extension-token := x-token / iana-token\r
-\r
- iana-token := <a publicly-defined extension token,\r
- registered with IANA, as specified in\r
- appendix E>\r
-\r
- x-token := <The two characters "X-" or "x-" followed, with\r
- no intervening white space, by any token>\r
-\r
- subtype := token ; case-insensitive\r
-\r
- parameter := attribute "=" value\r
-\r
- attribute := token ; case-insensitive\r
-\r
- value := token / quoted-string\r
-\r
- token := 1*<any (ASCII) CHAR except SPACE, CTLs,\r
- or tspecials>\r
-\r
- tspecials := "(" / ")" / "<" / ">" / "@"\r
- / "," / ";" / ":" / "\" / <">\r
- / "/" / "[" / "]" / "?" / "="\r
- ; Must be in quoted-string,\r
- ; to use within parameter values\r
-\r
-\r
-\r
-Borenstein & Freed [Page 10]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Note that the definition of "tspecials" is the same as the RFC 822\r
- definition of "specials" with the addition of the three characters\r
- "/", "?", and "=", and the removal of ".".\r
-\r
- Note also that a subtype specification is MANDATORY. There are no\r
- default subtypes.\r
-\r
- The type, subtype, and parameter names are not case sensitive. For\r
- example, TEXT, Text, and TeXt are all equivalent. Parameter values\r
- are normally case sensitive, but certain parameters are interpreted\r
- to be case-insensitive, depending on the intended use. (For example,\r
- multipart boundaries are case-sensitive, but the "access-type" for\r
- message/External-body is not case-sensitive.)\r
-\r
- Beyond this syntax, the only constraint on the definition of subtype\r
- names is the desire that their uses must not conflict. That is, it\r
- would be undesirable to have two different communities using\r
- "Content-Type: application/foobar" to mean two different things. The\r
- process of defining new content-subtypes, then, is not intended to be\r
- a mechanism for imposing restrictions, but simply a mechanism for\r
- publicizing the usages. There are, therefore, two acceptable\r
- mechanisms for defining new Content-Type subtypes:\r
-\r
- 1. Private values (starting with "X-") may be\r
- defined bilaterally between two cooperating\r
- agents without outside registration or\r
- standardization.\r
-\r
- 2. New standard values must be documented,\r
- registered with, and approved by IANA, as\r
- described in Appendix E. Where intended for\r
- public use, the formats they refer to must\r
- also be defined by a published specification,\r
- and possibly offered for standardization.\r
-\r
- The seven standard initial predefined Content-Types are detailed in\r
- the bulk of this document. They are:\r
-\r
- text -- textual information. The primary subtype,\r
- "plain", indicates plain (unformatted) text. No\r
- special software is required to get the full\r
- meaning of the text, aside from support for the\r
- indicated character set. Subtypes are to be used\r
- for enriched text in forms where application\r
- software may enhance the appearance of the text,\r
- but such software must not be required in order to\r
- get the general idea of the content. Possible\r
- subtypes thus include any readable word processor\r
-\r
-\r
-\r
-Borenstein & Freed [Page 11]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- format. A very simple and portable subtype,\r
- richtext, was defined in RFC 1341, with a future\r
- revision expected.\r
-\r
- multipart -- data consisting of multiple parts of\r
- independent data types. Four initial subtypes\r
- are defined, including the primary "mixed"\r
- subtype, "alternative" for representing the same\r
- data in multiple formats, "parallel" for parts\r
- intended to be viewed simultaneously, and "digest"\r
- for multipart entities in which each part is of\r
- type "message".\r
-\r
- message -- an encapsulated message. A body of\r
- Content-Type "message" is itself all or part of a\r
- fully formatted RFC 822 conformant message which\r
- may contain its own different Content-Type header\r
- field. The primary subtype is "rfc822". The\r
- "partial" subtype is defined for partial messages,\r
- to permit the fragmented transmission of bodies\r
- that are thought to be too large to be passed\r
- through mail transport facilities. Another\r
- subtype, "External-body", is defined for\r
- specifying large bodies by reference to an\r
- external data source.\r
-\r
- image -- image data. Image requires a display device\r
- (such as a graphical display, a printer, or a FAX\r
- machine) to view the information. Initial\r
- subtypes are defined for two widely-used image\r
- formats, jpeg and gif.\r
-\r
- audio -- audio data, with initial subtype "basic".\r
- Audio requires an audio output device (such as a\r
- speaker or a telephone) to "display" the contents.\r
-\r
- video -- video data. Video requires the capability to\r
- display moving images, typically including\r
- specialized hardware and software. The initial\r
- subtype is "mpeg".\r
-\r
- application -- some other kind of data, typically\r
- either uninterpreted binary data or information to\r
- be processed by a mail-based application. The\r
- primary subtype, "octet-stream", is to be used in\r
- the case of uninterpreted binary data, in which\r
- case the simplest recommended action is to offer\r
- to write the information into a file for the user.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 12]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- An additional subtype, "PostScript", is defined\r
- for transporting PostScript documents in bodies.\r
- Other expected uses for "application" include\r
- spreadsheets, data for mail-based scheduling\r
- systems, and languages for "active"\r
- (computational) email. (Note that active email\r
- and other application data may entail several\r
- security considerations, which are discussed later\r
- in this memo, particularly in the context of\r
- application/PostScript.)\r
-\r
- Default RFC 822 messages are typed by this protocol as plain text in\r
- the US-ASCII character set, which can be explicitly specified as\r
- "Content-type: text/plain; charset=us-ascii". If no Content-Type is\r
- specified, this default is assumed. In the presence of a MIME-\r
- Version header field, a receiving User Agent can also assume that\r
- plain US-ASCII text was the sender's intent. In the absence of a\r
- MIME-Version specification, plain US-ASCII text must still be\r
- assumed, but the sender's intent might have been otherwise.\r
-\r
- RATIONALE: In the absence of any Content-Type header field or\r
- MIME-Version header field, it is impossible to be certain that a\r
- message is actually text in the US-ASCII character set, since it\r
- might well be a message that, using the conventions that predate\r
- this document, includes text in another character set or non-\r
- textual data in a manner that cannot be automatically recognized\r
- (e.g., a uuencoded compressed UNIX tar file). Although there is\r
- no fully acceptable alternative to treating such untyped messages\r
- as "text/plain; charset=us-ascii", implementors should remain\r
- aware that if a message lacks both the MIME-Version and the\r
- Content-Type header fields, it may in practice contain almost\r
- anything.\r
-\r
- It should be noted that the list of Content-Type values given here\r
- may be augmented in time, via the mechanisms described above, and\r
- that the set of subtypes is expected to grow substantially.\r
-\r
- When a mail reader encounters mail with an unknown Content-type\r
- value, it should generally treat it as equivalent to\r
- "application/octet-stream", as described later in this document.\r
-\r
-5. The Content-Transfer-Encoding Header Field\r
-\r
- Many Content-Types which could usefully be transported via email are\r
- represented, in their "natural" format, as 8-bit character or binary\r
- data. Such data cannot be transmitted over some transport protocols.\r
- For example, RFC 821 restricts mail messages to 7-bit US-ASCII data\r
- with lines no longer than 1000 characters.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 13]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- It is necessary, therefore, to define a standard mechanism for re-\r
- encoding such data into a 7-bit short-line format. This document\r
- specifies that such encodings will be indicated by a new "Content-\r
- Transfer-Encoding" header field. The Content-Transfer-Encoding field\r
- is used to indicate the type of transformation that has been used in\r
- order to represent the body in an acceptable manner for transport.\r
-\r
- Unlike Content-Types, a proliferation of Content-Transfer-Encoding\r
- values is undesirable and unnecessary. However, establishing only a\r
- single Content-Transfer-Encoding mechanism does not seem possible.\r
- There is a tradeoff between the desire for a compact and efficient\r
- encoding of largely-binary data and the desire for a readable\r
- encoding of data that is mostly, but not entirely, 7-bit data. For\r
- this reason, at least two encoding mechanisms are necessary: a\r
- "readable" encoding and a "dense" encoding.\r
-\r
- The Content-Transfer-Encoding field is designed to specify an\r
- invertible mapping between the "native" representation of a type of\r
- data and a representation that can be readily exchanged using 7 bit\r
- mail transport protocols, such as those defined by RFC 821 (SMTP).\r
- This field has not been defined by any previous standard. The field's\r
- value is a single token specifying the type of encoding, as\r
- enumerated below. Formally:\r
-\r
- encoding := "Content-Transfer-Encoding" ":" mechanism\r
-\r
- mechanism := "7bit" ; case-insensitive\r
- / "quoted-printable"\r
- / "base64"\r
- / "8bit"\r
- / "binary"\r
- / x-token\r
-\r
- These values are not case sensitive. That is, Base64 and BASE64 and\r
- bAsE64 are all equivalent. An encoding type of 7BIT requires that\r
- the body is already in a seven-bit mail-ready representation. This\r
- is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is\r
- assumed if the Content-Transfer-Encoding header field is not present.\r
-\r
- The values "8bit", "7bit", and "binary" all mean that NO encoding has\r
- been performed. However, they are potentially useful as indications\r
- of the kind of data contained in the object, and therefore of the\r
- kind of encoding that might need to be performed for transmission in\r
- a given transport system. In particular:\r
-\r
- "7bit" means that the data is all represented as short\r
- lines of US-ASCII data.\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 14]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- "8bit" means that the lines are short, but there may be\r
- non-ASCII characters (octets with the high-order\r
- bit set).\r
-\r
- "Binary" means that not only may non-ASCII characters\r
- be present, but also that the lines are not\r
- necessarily short enough for SMTP transport.\r
-\r
- The difference between "8bit" (or any other conceivable bit-width\r
- token) and the "binary" token is that "binary" does not require\r
- adherence to any limits on line length or to the SMTP CRLF semantics,\r
- while the bit-width tokens do require such adherence. If the body\r
- contains data in any bit-width other than 7-bit, the appropriate\r
- bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"\r
- for unencoded 8 bit wide data). If the body contains binary data,\r
- the "binary" Content-Transfer-Encoding token must be used.\r
-\r
- NOTE: The distinction between the Content-Transfer-Encoding values\r
- of "binary", "8bit", etc. may seem unimportant, in that all of\r
- them really mean "none" -- that is, there has been no encoding of\r
- the data for transport. However, clear labeling will be of\r
- enormous value to gateways between future mail transport systems\r
- with differing capabilities in transporting data that do not meet\r
- the restrictions of RFC 821 transport.\r
-\r
- Mail transport for unencoded 8-bit data is defined in RFC-1426\r
- [RFC-1426]. As of the publication of this document, there are no\r
- standardized Internet mail transports for which it is legitimate\r
- to include unencoded binary data in mail bodies. Thus there are\r
- no circumstances in which the "binary" Content-Transfer-Encoding\r
- is actually legal on the Internet. However, in the event that\r
- binary mail transport becomes a reality in Internet mail, or when\r
- this document is used in conjunction with any other binary-capable\r
- transport mechanism, binary bodies should be labeled as such using\r
- this mechanism.\r
-\r
- NOTE: The five values defined for the Content-Transfer-Encoding\r
- field imply nothing about the Content-Type other than the\r
- algorithm by which it was encoded or the transport system\r
- requirements if unencoded.\r
-\r
- Implementors may, if necessary, define new Content-Transfer-Encoding\r
- values, but must use an x-token, which is a name prefixed by "X-" to\r
- indicate its non-standard status, e.g., "Content-Transfer-Encoding:\r
- x-my-new-encoding". However, unlike Content-Types and subtypes, the\r
- creation of new Content-Transfer-Encoding values is explicitly and\r
- strongly discouraged, as it seems likely to hinder interoperability\r
- with little potential benefit. Their use is allowed only as the\r
-\r
-\r
-\r
-Borenstein & Freed [Page 15]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- result of an agreement between cooperating user agents.\r
-\r
- If a Content-Transfer-Encoding header field appears as part of a\r
- message header, it applies to the entire body of that message. If a\r
- Content-Transfer-Encoding header field appears as part of a body\r
- part's headers, it applies only to the body of that body part. If an\r
- entity is of type "multipart" or "message", the Content-Transfer-\r
- Encoding is not permitted to have any value other than a bit width\r
- (e.g., "7bit", "8bit", etc.) or "binary".\r
-\r
- It should be noted that email is character-oriented, so that the\r
- mechanisms described here are mechanisms for encoding arbitrary octet\r
- streams, not bit streams. If a bit stream is to be encoded via one\r
- of these mechanisms, it must first be converted to an 8-bit byte\r
- stream using the network standard bit order ("big-endian"), in which\r
- the earlier bits in a stream become the higher-order bits in a byte.\r
- A bit stream not ending at an 8-bit boundary must be padded with\r
- zeroes. This document provides a mechanism for noting the addition\r
- of such padding in the case of the application Content-Type, which\r
- has a "padding" parameter.\r
-\r
- The encoding mechanisms defined here explicitly encode all data in\r
- ASCII. Thus, for example, suppose an entity has header fields such\r
- as:\r
-\r
- Content-Type: text/plain; charset=ISO-8859-1\r
- Content-transfer-encoding: base64\r
-\r
- This must be interpreted to mean that the body is a base64 ASCII\r
- encoding of data that was originally in ISO-8859-1, and will be in\r
- that character set again after decoding.\r
-\r
- The following sections will define the two standard encoding\r
- mechanisms. The definition of new content-transfer-encodings is\r
- explicitly discouraged and should only occur when absolutely\r
- necessary. All content-transfer-encoding namespace except that\r
- beginning with "X-" is explicitly reserved to the IANA for future\r
- use. Private agreements about content-transfer-encodings are also\r
- explicitly discouraged.\r
-\r
- Certain Content-Transfer-Encoding values may only be used on certain\r
- Content-Types. In particular, it is expressly forbidden to use any\r
- encodings other than "7bit", "8bit", or "binary" with any Content-\r
- Type that recursively includes other Content-Type fields, notably the\r
- "multipart" and "message" Content-Types. All encodings that are\r
- desired for bodies of type multipart or message must be done at the\r
- innermost level, by encoding the actual body that needs to be\r
- encoded.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 16]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- NOTE ON ENCODING RESTRICTIONS: Though the prohibition against\r
- using content-transfer-encodings on data of type multipart or\r
- message may seem overly restrictive, it is necessary to prevent\r
- nested encodings, in which data are passed through an encoding\r
- algorithm multiple times, and must be decoded multiple times in\r
- order to be properly viewed. Nested encodings add considerable\r
- complexity to user agents: aside from the obvious efficiency\r
- problems with such multiple encodings, they can obscure the basic\r
- structure of a message. In particular, they can imply that\r
- several decoding operations are necessary simply to find out what\r
- types of objects a message contains. Banning nested encodings may\r
- complicate the job of certain mail gateways, but this seems less\r
- of a problem than the effect of nested encodings on user agents.\r
-\r
- NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-\r
- TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding\r
- could be inferred from the characteristics of the Content-Type\r
- that is to be encoded, or, at the very least, that certain\r
- Content-Transfer-Encodings could be mandated for use with specific\r
- Content-Types. There are several reasons why this is not the case.\r
- First, given the varying types of transports used for mail, some\r
- encodings may be appropriate for some Content-Type/transport\r
- combinations and not for others. (For example, in an 8-bit\r
- transport, no encoding would be required for text in certain\r
- character sets, while such encodings are clearly required for 7-\r
- bit SMTP.) Second, certain Content-Types may require different\r
- types of transfer encoding under different circumstances. For\r
- example, many PostScript bodies might consist entirely of short\r
- lines of 7-bit data and hence require little or no encoding.\r
- Other PostScript bodies (especially those using Level 2\r
- PostScript's binary encoding mechanism) may only be reasonably\r
- represented using a binary transport encoding. Finally, since\r
- Content-Type is intended to be an open-ended specification\r
- mechanism, strict specification of an association between\r
- Content-Types and encodings effectively couples the specification\r
- of an application protocol with a specific lower-level transport.\r
- This is not desirable since the developers of a Content-Type\r
- should not have to be aware of all the transports in use and what\r
- their limitations are.\r
-\r
- NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64\r
- encodings are designed so that conversion between them is\r
- possible. The only issue that arises in such a conversion is the\r
- handling of line breaks. When converting from quoted-printable to\r
- base64 a line break must be converted into a CRLF sequence.\r
- Similarly, a CRLF sequence in base64 data must be converted to a\r
- quoted-printable line break, but ONLY when converting text data.\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 17]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in\r
- earlier drafts of this memo, regarding the model for when email\r
- data was to be converted to canonical form and encoded, and in\r
- particular how this process would affect the treatment of CRLFs,\r
- given that the representation of newlines varies greatly from\r
- system to system, and the relationship between content-transfer-\r
- encodings and character sets. For this reason, a canonical model\r
- for encoding is presented as Appendix G.\r
-\r
-5.1. Quoted-Printable Content-Transfer-Encoding\r
-\r
- The Quoted-Printable encoding is intended to represent data that\r
- largely consists of octets that correspond to printable characters in\r
- the ASCII character set. It encodes the data in such a way that the\r
- resulting octets are unlikely to be modified by mail transport. If\r
- the data being encoded are mostly ASCII text, the encoded form of the\r
- data remains largely recognizable by humans. A body which is\r
- entirely ASCII may also be encoded in Quoted-Printable to ensure the\r
- integrity of the data should the message pass through a character-\r
- translating, and/or line-wrapping gateway.\r
-\r
- In this encoding, octets are to be represented as determined by the\r
- following rules:\r
-\r
- Rule #1: (General 8-bit representation) Any octet, except those\r
- indicating a line break according to the newline convention of the\r
- canonical (standard) form of the data being encoded, may be\r
- represented by an "=" followed by a two digit hexadecimal\r
- representation of the octet's value. The digits of the\r
- hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".\r
- Uppercase letters must be used when sending hexadecimal data,\r
- though a robust implementation may choose to recognize lowercase\r
- letters on receipt. Thus, for example, the value 12 (ASCII form\r
- feed) can be represented by "=0C", and the value 61 (ASCII EQUAL\r
- SIGN) can be represented by "=3D". Except when the following\r
- rules allow an alternative encoding, this rule is mandatory.\r
-\r
- Rule #2: (Literal representation) Octets with decimal values of 33\r
- through 60 inclusive, and 62 through 126, inclusive, MAY be\r
- represented as the ASCII characters which correspond to those\r
- octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN\r
- through TILDE, respectively).\r
-\r
- Rule #3: (White Space): Octets with values of 9 and 32 MAY be\r
- represented as ASCII TAB (HT) and SPACE characters, respectively,\r
- but MUST NOT be so represented at the end of an encoded line. Any\r
- TAB (HT) or SPACE characters on an encoded line MUST thus be\r
- followed on that line by a printable character. In particular, an\r
-\r
-\r
-\r
-Borenstein & Freed [Page 18]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- "=" at the end of an encoded line, indicating a soft line break\r
- (see rule #5) may follow one or more TAB (HT) or SPACE characters.\r
- It follows that an octet with value 9 or 32 appearing at the end\r
- of an encoded line must be represented according to Rule #1. This\r
- rule is necessary because some MTAs (Message Transport Agents,\r
- programs which transport messages from one user to another, or\r
- perform a part of such transfers) are known to pad lines of text\r
- with SPACEs, and others are known to remove "white space"\r
- characters from the end of a line. Therefore, when decoding a\r
- Quoted-Printable body, any trailing white space on a line must be\r
- deleted, as it will necessarily have been added by intermediate\r
- transport agents.\r
-\r
- Rule #4 (Line Breaks): A line break in a text body, independent of\r
- what its representation is following the canonical representation\r
- of the data being encoded, must be represented by a (RFC 822) line\r
- break, which is a CRLF sequence, in the Quoted-Printable encoding.\r
- Since the canonical representation of types other than text do not\r
- generally include the representation of line breaks, no hard line\r
- breaks (i.e. line breaks that are intended to be meaningful and\r
- to be displayed to the user) should occur in the quoted-printable\r
- encoding of such types. Of course, occurrences of "=0D", "=0A",\r
- "0A=0D" and "=0D=0A" will eventually be encountered. In general,\r
- however, base64 is preferred over quoted-printable for binary\r
- data.\r
-\r
- Note that many implementations may elect to encode the local\r
- representation of various content types directly, as described in\r
- Appendix G. In particular, this may apply to plain text material\r
- on systems that use newline conventions other than CRLF\r
- delimiters. Such an implementation is permissible, but the\r
- generation of line breaks must be generalized to account for the\r
- case where alternate representations of newline sequences are\r
- used.\r
-\r
- Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES\r
- that encoded lines be no more than 76 characters long. If longer\r
- lines are to be encoded with the Quoted-Printable encoding, 'soft'\r
- line breaks must be used. An equal sign as the last character on a\r
- encoded line indicates such a non-significant ('soft') line break\r
- in the encoded text. Thus if the "raw" form of the line is a\r
- single unencoded line that says:\r
-\r
- Now's the time for all folk to come to the aid of\r
- their country.\r
-\r
- This can be represented, in the Quoted-Printable encoding, as\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 19]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Now's the time =\r
- for all folk to come=\r
- to the aid of their country.\r
-\r
- This provides a mechanism with which long lines are encoded in\r
- such a way as to be restored by the user agent. The 76 character\r
- limit does not count the trailing CRLF, but counts all other\r
- characters, including any equal signs.\r
-\r
- Since the hyphen character ("-") is represented as itself in the\r
- Quoted-Printable encoding, care must be taken, when encapsulating a\r
- quoted-printable encoded body in a multipart entity, to ensure that\r
- the encapsulation boundary does not appear anywhere in the encoded\r
- body. (A good strategy is to choose a boundary that includes a\r
- character sequence such as "=_" which can never appear in a quoted-\r
- printable body. See the definition of multipart messages later in\r
- this document.)\r
-\r
- NOTE: The quoted-printable encoding represents something of a\r
- compromise between readability and reliability in transport.\r
- Bodies encoded with the quoted-printable encoding will work\r
- reliably over most mail gateways, but may not work perfectly over\r
- a few gateways, notably those involving translation into EBCDIC.\r
- (In theory, an EBCDIC gateway could decode a quoted-printable body\r
- and re-encode it using base64, but such gateways do not yet\r
- exist.) A higher level of confidence is offered by the base64\r
- Content-Transfer-Encoding. A way to get reasonably reliable\r
- transport through EBCDIC gateways is to also quote the ASCII\r
- characters\r
-\r
- !"#$@[\]^`{|}~\r
-\r
- according to rule #1. See Appendix B for more information.\r
-\r
- Because quoted-printable data is generally assumed to be line-\r
- oriented, it is to be expected that the representation of the breaks\r
- between the lines of quoted printable data may be altered in\r
- transport, in the same manner that plain text mail has always been\r
- altered in Internet mail when passing between systems with differing\r
- newline conventions. If such alterations are likely to constitute a\r
- corruption of the data, it is probably more sensible to use the\r
- base64 encoding rather than the quoted-printable encoding.\r
-\r
- WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-\r
- printable, care must be taken to encode CR and LF characters as "=0D"\r
- and "=0A", respectively. In particular, a CRLF sequence in binary\r
- data should be encoded as "=0D=0A". Otherwise, if CRLF were\r
- represented as a hard line break, it might be incorrectly decoded on\r
-\r
-\r
-\r
-Borenstein & Freed [Page 20]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- platforms with different line break conventions.\r
-\r
- For formalists, the syntax of quoted-printable data is described by\r
- the following grammar:\r
-\r
- quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)\r
- ; Maximum line length of 76 characters excluding CRLF\r
-\r
- ptext := octet /<any ASCII character except "=", SPACE, or TAB>\r
- ; characters not listed as "mail-safe" in Appendix B\r
- ; are also not recommended.\r
-\r
- octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")\r
- ; octet must be used for characters > 127, =, SPACE, or TAB,\r
- ; and is recommended for any characters not listed in\r
- ; Appendix B as "mail-safe".\r
-\r
-5.2. Base64 Content-Transfer-Encoding\r
-\r
- The Base64 Content-Transfer-Encoding is designed to represent\r
- arbitrary sequences of octets in a form that need not be humanly\r
- readable. The encoding and decoding algorithms are simple, but the\r
- encoded data are consistently only about 33 percent larger than the\r
- unencoded data. This encoding is virtually identical to the one used\r
- in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.\r
- The base64 encoding is adapted from RFC 1421, with one change: base64\r
- eliminates the "*" mechanism for embedded clear text.\r
-\r
- A 65-character subset of US-ASCII is used, enabling 6 bits to be\r
- represented per printable character. (The extra 65th character, "=",\r
- is used to signify a special processing function.)\r
-\r
- NOTE: This subset has the important property that it is\r
- represented identically in all versions of ISO 646, including US\r
- ASCII, and all characters in the subset are also represented\r
- identically in all versions of EBCDIC. Other popular encodings,\r
- such as the encoding used by the uuencode utility and the base85\r
- encoding specified as part of Level 2 PostScript, do not share\r
- these properties, and thus do not fulfill the portability\r
- requirements a binary transport encoding for mail must meet.\r
-\r
- The encoding process represents 24-bit groups of input bits as output\r
- strings of 4 encoded characters. Proceeding from left to right, a\r
- 24-bit input group is formed by concatenating 3 8-bit input groups.\r
- These 24 bits are then treated as 4 concatenated 6-bit groups, each\r
- of which is translated into a single digit in the base64 alphabet.\r
- When encoding a bit stream via the base64 encoding, the bit stream\r
- must be presumed to be ordered with the most-significant-bit first.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 21]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- That is, the first bit in the stream will be the high-order bit in\r
- the first byte, and the eighth bit will be the low-order bit in the\r
- first byte, and so on.\r
-\r
- Each 6-bit group is used as an index into an array of 64 printable\r
- characters. The character referenced by the index is placed in the\r
- output string. These characters, identified in Table 1, below, are\r
- selected so as to be universally representable, and the set excludes\r
- characters with particular significance to SMTP (e.g., ".", CR, LF)\r
- and to the encapsulation boundaries defined in this document (e.g.,\r
- "-").\r
-\r
- Table 1: The Base64 Alphabet\r
-\r
- Value Encoding Value Encoding Value Encoding Value Encoding\r
- 0 A 17 R 34 i 51 z\r
- 1 B 18 S 35 j 52 0\r
- 2 C 19 T 36 k 53 1\r
- 3 D 20 U 37 l 54 2\r
- 4 E 21 V 38 m 55 3\r
- 5 F 22 W 39 n 56 4\r
- 6 G 23 X 40 o 57 5\r
- 7 H 24 Y 41 p 58 6\r
- 8 I 25 Z 42 q 59 7\r
- 9 J 26 a 43 r 60 8\r
- 10 K 27 b 44 s 61 9\r
- 11 L 28 c 45 t 62 +\r
- 12 M 29 d 46 u 63 /\r
- 13 N 30 e 47 v\r
- 14 O 31 f 48 w (pad) =\r
- 15 P 32 g 49 x\r
- 16 Q 33 h 50 y\r
-\r
- The output stream (encoded bytes) must be represented in lines of no\r
- more than 76 characters each. All line breaks or other characters\r
- not found in Table 1 must be ignored by decoding software. In base64\r
- data, characters other than those in Table 1, line breaks, and other\r
- white space probably indicate a transmission error, about which a\r
- warning message or even a message rejection might be appropriate\r
- under some circumstances.\r
-\r
- Special processing is performed if fewer than 24 bits are available\r
- at the end of the data being encoded. A full encoding quantum is\r
- always completed at the end of a body. When fewer than 24 input bits\r
- are available in an input group, zero bits are added (on the right)\r
- to form an integral number of 6-bit groups. Padding at the end of\r
- the data is performed using the '=' character. Since all base64\r
- input is an integral number of octets, only the following cases can\r
-\r
-\r
-\r
-Borenstein & Freed [Page 22]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- arise: (1) the final quantum of encoding input is an integral\r
- multiple of 24 bits; here, the final unit of encoded output will be\r
- an integral multiple of 4 characters with no "=" padding, (2) the\r
- final quantum of encoding input is exactly 8 bits; here, the final\r
- unit of encoded output will be two characters followed by two "="\r
- padding characters, or (3) the final quantum of encoding input is\r
- exactly 16 bits; here, the final unit of encoded output will be three\r
- characters followed by one "=" padding character.\r
-\r
- Because it is used only for padding at the end of the data, the\r
- occurrence of any '=' characters may be taken as evidence that the\r
- end of the data has been reached (without truncation in transit). No\r
- such assurance is possible, however, when the number of octets\r
- transmitted was a multiple of three.\r
-\r
- Any characters outside of the base64 alphabet are to be ignored in\r
- base64-encoded data. The same applies to any illegal sequence of\r
- characters in the base64 encoding, such as "====="\r
-\r
- Care must be taken to use the proper octets for line breaks if base64\r
- encoding is applied directly to text material that has not been\r
- converted to canonical form. In particular, text line breaks must be\r
- converted into CRLF sequences prior to base64 encoding. The important\r
- thing to note is that this may be done directly by the encoder rather\r
- than in a prior canonicalization step in some implementations.\r
-\r
- NOTE: There is no need to worry about quoting apparent\r
- encapsulation boundaries within base64-encoded parts of multipart\r
- entities because no hyphen characters are used in the base64\r
- encoding.\r
-\r
-6. Additional Content-Header Fields\r
-\r
-6.1. Optional Content-ID Header Field\r
-\r
- In constructing a high-level user agent, it may be desirable to allow\r
- one body to make reference to another. Accordingly, bodies may be\r
- labeled using the "Content-ID" header field, which is syntactically\r
- identical to the "Message-ID" header field:\r
-\r
- id := "Content-ID" ":" msg-id\r
- Like the Message-ID values, Content-ID values must be generated to be\r
- world-unique.\r
-\r
- The Content-ID value may be used for uniquely identifying MIME\r
- entities in several contexts, particularly for cacheing data\r
- referenced by the message/external-body mechanism. Although the\r
- Content-ID header is generally optional, its use is mandatory in\r
-\r
-\r
-\r
-Borenstein & Freed [Page 23]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- implementations which generate data of the optional MIME Content-type\r
- "message/external-body". That is, each message/external-body entity\r
- must have a Content-ID field to permit cacheing of such data.\r
-\r
- It is also worth noting that the Content-ID value has special\r
- semantics in the case of the multipart/alternative content-type.\r
- This is explained in the section of this document dealing with\r
- multipart/alternative.\r
-\r
-6.2. Optional Content-Description Header Field\r
-\r
- The ability to associate some descriptive information with a given\r
- body is often desirable. For example, it may be useful to mark an\r
- "image" body as "a picture of the Space Shuttle Endeavor." Such text\r
- may be placed in the Content-Description header field.\r
-\r
- description := "Content-Description" ":" *text\r
-\r
- The description is presumed to be given in the US-ASCII character\r
- set, although the mechanism specified in [RFC-1522] may be used for\r
- non-US-ASCII Content-Description values.\r
-\r
-7. The Predefined Content-Type Values\r
-\r
- This document defines seven initial Content-Type values and an\r
- extension mechanism for private or experimental types. Further\r
- standard types must be defined by new published specifications. It\r
- is expected that most innovation in new types of mail will take place\r
- as subtypes of the seven types defined here. The most essential\r
- characteristics of the seven content-types are summarized in Appendix\r
- F.\r
-\r
-7.1 The Text Content-Type\r
-\r
- The text Content-Type is intended for sending material which is\r
- principally textual in form. It is the default Content-Type. A\r
- "charset" parameter may be used to indicate the character set of the\r
- body text for some text subtypes, notably including the primary\r
- subtype, "text/plain", which indicates plain (unformatted) text. The\r
- default Content-Type for Internet mail is "text/plain; charset=us-\r
- ascii".\r
-\r
- Beyond plain text, there are many formats for representing what might\r
- be known as "extended text" -- text with embedded formatting and\r
- presentation information. An interesting characteristic of many such\r
- representations is that they are to some extent readable even without\r
- the software that interprets them. It is useful, then, to\r
- distinguish them, at the highest level, from such unreadable data as\r
-\r
-\r
-\r
-Borenstein & Freed [Page 24]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- images, audio, or text represented in an unreadable form. In the\r
- absence of appropriate interpretation software, it is reasonable to\r
- show subtypes of text to the user, while it is not reasonable to do\r
- so with most nontextual data.\r
-\r
- Such formatted textual data should be represented using subtypes of\r
- text. Plausible subtypes of text are typically given by the common\r
- name of the representation format, e.g., "text/richtext" [RFC-1341].\r
-\r
-7.1.1. The charset parameter\r
-\r
- A critical parameter that may be specified in the Content-Type field\r
- for text/plain data is the character set. This is specified with a\r
- "charset" parameter, as in:\r
-\r
- Content-type: text/plain; charset=us-ascii\r
-\r
- Unlike some other parameter values, the values of the charset\r
- parameter are NOT case sensitive. The default character set, which\r
- must be assumed in the absence of a charset parameter, is US-ASCII.\r
-\r
- The specification for any future subtypes of "text" must specify\r
- whether or not they will also utilize a "charset" parameter, and may\r
- possibly restrict its values as well. When used with a particular\r
- body, the semantics of the "charset" parameter should be identical to\r
- those specified here for "text/plain", i.e., the body consists\r
- entirely of characters in the given charset. In particular, definers\r
- of future text subtypes should pay close attention the the\r
- implications of multibyte character sets for their subtype\r
- definitions.\r
-\r
- This RFC specifies the definition of the charset parameter for the\r
- purposes of MIME to be a unique mapping of a byte stream to glyphs, a\r
- mapping which does not require external profiling information.\r
-\r
- An initial list of predefined character set names can be found at the\r
- end of this section. Additional character sets may be registered\r
- with IANA, although the standardization of their use requires the\r
- usual IESG [RFC-1340] review and approval. Note that if the\r
- specified character set includes 8-bit data, a Content-Transfer-\r
- Encoding header field and a corresponding encoding on the data are\r
- required in order to transmit the body via some mail transfer\r
- protocols, such as SMTP.\r
-\r
- The default character set, US-ASCII, has been the subject of some\r
- confusion and ambiguity in the past. Not only were there some\r
- ambiguities in the definition, there have been wide variations in\r
- practice. In order to eliminate such ambiguity and variations in the\r
-\r
-\r
-\r
-Borenstein & Freed [Page 25]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- future, it is strongly recommended that new user agents explicitly\r
- specify a character set via the Content-Type header field. "US-\r
- ASCII" does not indicate an arbitrary seven-bit character code, but\r
- specifies that the body uses character coding that uses the exact\r
- correspondence of codes to characters specified in ASCII. National\r
- use variations of ISO 646 [ISO-646] are NOT ASCII and their use in\r
- Internet mail is explicitly discouraged. The omission of the ISO 646\r
- character set is deliberate in this regard. The character set name\r
- of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.\r
- The character set name "ASCII" is reserved and must not be used for\r
- any purpose.\r
-\r
- NOTE: RFC 821 explicitly specifies "ASCII", and references an\r
- earlier version of the American Standard. Insofar as one of the\r
- purposes of specifying a Content-Type and character set is to\r
- permit the receiver to unambiguously determine how the sender\r
- intended the coded message to be interpreted, assuming anything\r
- other than "strict ASCII" as the default would risk unintentional\r
- and incompatible changes to the semantics of messages now being\r
- transmitted. This also implies that messages containing\r
- characters coded according to national variations on ISO 646, or\r
- using code-switching procedures (e.g., those of ISO 2022), as well\r
- as 8-bit or multiple octet character encodings MUST use an\r
- appropriate character set specification to be consistent with this\r
- specification.\r
-\r
- The complete US-ASCII character set is listed in [US-ASCII]. Note\r
- that the control characters including DEL (0-31, 127) have no defined\r
- meaning apart from the combination CRLF (ASCII values 13 and 10)\r
- indicating a new line. Two of the characters have de facto meanings\r
- in wide use: FF (12) often means "start subsequent text on the\r
- beginning of a new page"; and TAB or HT (9) often (though not always)\r
- means "move the cursor to the next available column after the current\r
- position where the column number is a multiple of 8 (counting the\r
- first column as column 0)." Apart from this, any use of the control\r
- characters or DEL in a body must be part of a private agreement\r
- between the sender and recipient. Such private agreements are\r
- discouraged and should be replaced by the other capabilities of this\r
- document.\r
-\r
- NOTE: Beyond US-ASCII, an enormous proliferation of character sets\r
- is possible. It is the opinion of the IETF working group that a\r
- large number of character sets is NOT a good thing. We would\r
- prefer to specify a single character set that can be used\r
- universally for representing all of the world's languages in\r
- electronic mail. Unfortunately, existing practice in several\r
- communities seems to point to the continued use of multiple\r
- character sets in the near future. For this reason, we define\r
-\r
-\r
-\r
-Borenstein & Freed [Page 26]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- names for a small number of character sets for which a strong\r
- constituent base exists.\r
-\r
- The defined charset values are:\r
-\r
- US-ASCII -- as defined in [US-ASCII].\r
-\r
- ISO-8859-X -- where "X" is to be replaced, as necessary, for the\r
- parts of ISO-8859 [ISO-8859]. Note that the ISO 646\r
- character sets have deliberately been omitted in favor of\r
- their 8859 replacements, which are the designated character\r
- sets for Internet mail. As of the publication of this\r
- document, the legitimate values for "X" are the digits 1\r
- through 9.\r
-\r
- The character sets specified above are the ones that were relatively\r
- uncontroversial during the drafting of MIME. This document does not\r
- endorse the use of any particular character set other than US-ASCII,\r
- and recognizes that the future evolution of world character sets\r
- remains unclear. It is expected that in the future, additional\r
- character sets will be registered for use in MIME.\r
-\r
- Note that the character set used, if anything other than US-ASCII,\r
- must always be explicitly specified in the Content-Type field.\r
-\r
- No other character set name may be used in Internet mail without the\r
- publication of a formal specification and its registration with IANA,\r
- or by private agreement, in which case the character set name must\r
- begin with "X-".\r
-\r
- Implementors are discouraged from defining new character sets for\r
- mail use unless absolutely necessary.\r
-\r
- The "charset" parameter has been defined primarily for the purpose of\r
- textual data, and is described in this section for that reason.\r
- However, it is conceivable that non-textual data might also wish to\r
- specify a charset value for some purpose, in which case the same\r
- syntax and values should be used.\r
-\r
- In general, mail-sending software must always use the "lowest common\r
- denominator" character set possible. For example, if a body contains\r
- only US-ASCII characters, it must be marked as being in the US-ASCII\r
- character set, not ISO-8859-1, which, like all the ISO-8859 family of\r
- character sets, is a superset of US-ASCII. More generally, if a\r
- widely-used character set is a subset of another character set, and a\r
- body contains only characters in the widely-used subset, it must be\r
- labeled as being in that subset. This will increase the chances that\r
- the recipient will be able to view the mail correctly.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 27]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-7.1.2. The Text/plain subtype\r
-\r
- The primary subtype of text is "plain". This indicates plain\r
- (unformatted) text. The default Content-Type for Internet mail,\r
- "text/plain; charset=us-ascii", describes existing Internet practice.\r
- That is, it is the type of body defined by RFC 822.\r
-\r
- No other text subtype is defined by this document.\r
-\r
- The formal grammar for the content-type header field for text is as\r
- follows:\r
-\r
- text-type := "text" "/" text-subtype [";" "charset" "=" charset]\r
-\r
- text-subtype := "plain" / extension-token\r
-\r
- charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"\r
- / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"\r
- / "iso-8859-8" / "iso-8859-9" / extension-token\r
- ; case insensitive\r
-\r
-7.2. The Multipart Content-Type\r
-\r
- In the case of multiple part entities, in which one or more different\r
- sets of data are combined in a single body, a "multipart" Content-\r
- Type field must appear in the entity's header. The body must then\r
- contain one or more "body parts," each preceded by an encapsulation\r
- boundary, and the last one followed by a closing boundary. Each part\r
- starts with an encapsulation boundary, and then contains a body part\r
- consisting of header area, a blank line, and a body area. Thus a\r
- body part is similar to an RFC 822 message in syntax, but different\r
- in meaning.\r
-\r
- A body part is NOT to be interpreted as actually being an RFC 822\r
- message. To begin with, NO header fields are actually required in\r
- body parts. A body part that starts with a blank line, therefore, is\r
- allowed and is a body part for which all default values are to be\r
- assumed. In such a case, the absence of a Content-Type header field\r
- implies that the corresponding body is plain US-ASCII text. The only\r
- header fields that have defined meaning for body parts are those the\r
- names of which begin with "Content-". All other header fields are\r
- generally to be ignored in body parts. Although they should\r
- generally be retained in mail processing, they may be discarded by\r
- gateways if necessary. Such other fields are permitted to appear in\r
- body parts but must not be depended on. "X-" fields may be created\r
- for experimental or private purposes, with the recognition that the\r
- information they contain may be lost at some gateways.\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 28]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- NOTE: The distinction between an RFC 822 message and a body part\r
- is subtle, but important. A gateway between Internet and X.400\r
- mail, for example, must be able to tell the difference between a\r
- body part that contains an image and a body part that contains an\r
- encapsulated message, the body of which is an image. In order to\r
- represent the latter, the body part must have "Content-Type:\r
- message", and its body (after the blank line) must be the\r
- encapsulated message, with its own "Content-Type: image" header\r
- field. The use of similar syntax facilitates the conversion of\r
- messages to body parts, and vice versa, but the distinction\r
- between the two must be understood by implementors. (For the\r
- special case in which all parts actually are messages, a "digest"\r
- subtype is also defined.)\r
-\r
- As stated previously, each body part is preceded by an encapsulation\r
- boundary. The encapsulation boundary MUST NOT appear inside any of\r
- the encapsulated parts. Thus, it is crucial that the composing agent\r
- be able to choose and specify the unique boundary that will separate\r
- the parts.\r
-\r
- All present and future subtypes of the "multipart" type must use an\r
- identical syntax. Subtypes may differ in their semantics, and may\r
- impose additional restrictions on syntax, but must conform to the\r
- required syntax for the multipart type. This requirement ensures\r
- that all conformant user agents will at least be able to recognize\r
- and separate the parts of any multipart entity, even of an\r
- unrecognized subtype.\r
-\r
- As stated in the definition of the Content-Transfer-Encoding field,\r
- no encoding other than "7bit", "8bit", or "binary" is permitted for\r
- entities of type "multipart". The multipart delimiters and header\r
- fields are always represented as 7-bit ASCII in any case (though the\r
- header fields may encode non-ASCII header text as per [RFC-1522]),\r
- and data within the body parts can be encoded on a part-by-part\r
- basis, with Content-Transfer-Encoding fields for each appropriate\r
- body part.\r
-\r
- Mail gateways, relays, and other mail handling agents are commonly\r
- known to alter the top-level header of an RFC 822 message. In\r
- particular, they frequently add, remove, or reorder header fields.\r
- Such alterations are explicitly forbidden for the body part headers\r
- embedded in the bodies of messages of type "multipart."\r
-\r
-7.2.1. Multipart: The common syntax\r
-\r
- All subtypes of "multipart" share a common syntax, defined in this\r
- section. A simple example of a multipart message also appears in\r
- this section. An example of a more complex multipart message is\r
-\r
-\r
-\r
-Borenstein & Freed [Page 29]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- given in Appendix C.\r
-\r
- The Content-Type field for multipart entities requires one parameter,\r
- "boundary", which is used to specify the encapsulation boundary. The\r
- encapsulation boundary is defined as a line consisting entirely of\r
- two hyphen characters ("-", decimal code 45) followed by the boundary\r
- parameter value from the Content-Type header field.\r
-\r
- NOTE: The hyphens are for rough compatibility with the earlier RFC\r
- 934 method of message encapsulation, and for ease of searching for\r
- the boundaries in some implementations. However, it should be\r
- noted that multipart messages are NOT completely compatible with\r
- RFC 934 encapsulations; in particular, they do not obey RFC 934\r
- quoting conventions for embedded lines that begin with hyphens.\r
- This mechanism was chosen over the RFC 934 mechanism because the\r
- latter causes lines to grow with each level of quoting. The\r
- combination of this growth with the fact that SMTP implementations\r
- sometimes wrap long lines made the RFC 934 mechanism unsuitable\r
- for use in the event that deeply-nested multipart structuring is\r
- ever desired.\r
-\r
- WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-\r
- type field is such that it is often necessary to enclose the\r
- boundaries in quotes on the Content-type line. This is not always\r
- necessary, but never hurts. Implementors should be sure to study the\r
- grammar carefully in order to avoid producing illegal Content-type\r
- fields. Thus, a typical multipart Content-Type header field might\r
- look like this:\r
-\r
- Content-Type: multipart/mixed;\r
- boundary=gc0p4Jq0M2Yt08jU534c0p\r
-\r
- But the following is illegal:\r
-\r
- Content-Type: multipart/mixed;\r
- boundary=gc0p4Jq0M:2Yt08jU534c0p\r
-\r
- (because of the colon) and must instead be represented as\r
-\r
- Content-Type: multipart/mixed;\r
- boundary="gc0p4Jq0M:2Yt08jU534c0p"\r
-\r
- This indicates that the entity consists of several parts, each itself\r
- with a structure that is syntactically identical to an RFC 822\r
- message, except that the header area might be completely empty, and\r
- that the parts are each preceded by the line\r
-\r
- --gc0p4Jq0M:2Yt08jU534c0p\r
-\r
-\r
-\r
-Borenstein & Freed [Page 30]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Note that the encapsulation boundary must occur at the beginning of a\r
- line, i.e., following a CRLF, and that the initial CRLF is considered\r
- to be attached to the encapsulation boundary rather than part of the\r
- preceding part. The boundary must be followed immediately either by\r
- another CRLF and the header fields for the next part, or by two\r
- CRLFs, in which case there are no header fields for the next part\r
- (and it is therefore assumed to be of Content-Type text/plain).\r
-\r
- NOTE: The CRLF preceding the encapsulation line is conceptually\r
- attached to the boundary so that it is possible to have a part\r
- that does not end with a CRLF (line break). Body parts that must\r
- be considered to end with line breaks, therefore, must have two\r
- CRLFs preceding the encapsulation line, the first of which is part\r
- of the preceding body part, and the second of which is part of the\r
- encapsulation boundary.\r
-\r
- Encapsulation boundaries must not appear within the encapsulations,\r
- and must be no longer than 70 characters, not counting the two\r
- leading hyphens.\r
-\r
- The encapsulation boundary following the last body part is a\r
- distinguished delimiter that indicates that no further body parts\r
- will follow. Such a delimiter is identical to the previous\r
- delimiters, with the addition of two more hyphens at the end of the\r
- line:\r
-\r
- --gc0p4Jq0M2Yt08jU534c0p--\r
-\r
- There appears to be room for additional information prior to the\r
- first encapsulation boundary and following the final boundary. These\r
- areas should generally be left blank, and implementations must ignore\r
- anything that appears before the first boundary or after the last\r
- one.\r
-\r
- NOTE: These "preamble" and "epilogue" areas are generally not used\r
- because of the lack of proper typing of these parts and the lack\r
- of clear semantics for handling these areas at gateways,\r
- particularly X.400 gateways. However, rather than leaving the\r
- preamble area blank, many MIME implementations have found this to\r
- be a convenient place to insert an explanatory note for recipients\r
- who read the message with pre-MIME software, since such notes will\r
- be ignored by MIME-compliant software.\r
-\r
- NOTE: Because encapsulation boundaries must not appear in the body\r
- parts being encapsulated, a user agent must exercise care to\r
- choose a unique boundary. The boundary in the example above could\r
- have been the result of an algorithm designed to produce\r
- boundaries with a very low probability of already existing in the\r
-\r
-\r
-\r
-Borenstein & Freed [Page 31]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- data to be encapsulated without having to prescan the data.\r
- Alternate algorithms might result in more 'readable' boundaries\r
- for a recipient with an old user agent, but would require more\r
- attention to the possibility that the boundary might appear in the\r
- encapsulated part. The simplest boundary possible is something\r
- like "---", with a closing boundary of "-----".\r
-\r
- As a very simple example, the following multipart message has two\r
- parts, both of them plain text, one of them explicitly typed and one\r
- of them implicitly typed:\r
-\r
- From: Nathaniel Borenstein <nsb@bellcore.com>\r
- To: Ned Freed <ned@innosoft.com>\r
- Subject: Sample message\r
- MIME-Version: 1.0\r
- Content-type: multipart/mixed; boundary="simple\r
- boundary"\r
-\r
- This is the preamble. It is to be ignored, though it\r
- is a handy place for mail composers to include an\r
- explanatory note to non-MIME conformant readers.\r
- --simple boundary\r
-\r
- This is implicitly typed plain ASCII text.\r
- It does NOT end with a linebreak.\r
- --simple boundary\r
- Content-type: text/plain; charset=us-ascii\r
-\r
- This is explicitly typed plain ASCII text.\r
- It DOES end with a linebreak.\r
-\r
- --simple boundary--\r
- This is the epilogue. It is also to be ignored.\r
-\r
- The use of a Content-Type of multipart in a body part within another\r
- multipart entity is explicitly allowed. In such cases, for obvious\r
- reasons, care must be taken to ensure that each nested multipart\r
- entity must use a different boundary delimiter. See Appendix C for an\r
- example of nested multipart entities.\r
-\r
- The use of the multipart Content-Type with only a single body part\r
- may be useful in certain contexts, and is explicitly permitted.\r
-\r
- The only mandatory parameter for the multipart Content-Type is the\r
- boundary parameter, which consists of 1 to 70 characters from a set\r
- of characters known to be very robust through email gateways, and NOT\r
- ending with white space. (If a boundary appears to end with white\r
- space, the white space must be presumed to have been added by a\r
-\r
-\r
-\r
-Borenstein & Freed [Page 32]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- gateway, and must be deleted.) It is formally specified by the\r
- following BNF:\r
-\r
- boundary := 0*69<bchars> bcharsnospace\r
-\r
- bchars := bcharsnospace / " "\r
-\r
- bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"\r
- / "," / "-" / "." / "/" / ":" / "=" / "?"\r
-\r
- Overall, the body of a multipart entity may be specified as\r
- follows:\r
-\r
- multipart-body := preamble 1*encapsulation\r
- close-delimiter epilogue\r
-\r
- encapsulation := delimiter body-part CRLF\r
-\r
- delimiter := "--" boundary CRLF ; taken from Content-Type field.\r
- ; There must be no space\r
- ; between "--" and boundary.\r
-\r
- close-delimiter := "--" boundary "--" CRLF ; Again, no space\r
- by "--",\r
-\r
- preamble := discard-text ; to be ignored upon receipt.\r
-\r
- epilogue := discard-text ; to be ignored upon receipt.\r
-\r
- discard-text := *(*text CRLF)\r
-\r
- body-part := <"message" as defined in RFC 822,\r
- with all header fields optional, and with the\r
- specified delimiter not occurring anywhere in\r
- the message body, either on a line by itself\r
- or as a substring anywhere. Note that the\r
- semantics of a part differ from the semantics\r
- of a message, as described in the text.>\r
-\r
- NOTE: In certain transport enclaves, RFC 822 restrictions such as\r
- the one that limits bodies to printable ASCII characters may not\r
- be in force. (That is, the transport domains may resemble\r
- standard Internet mail transport as specified in RFC821 and\r
- assumed by RFC822, but without certain restrictions.) The\r
- relaxation of these restrictions should be construed as locally\r
- extending the definition of bodies, for example to include octets\r
- outside of the ASCII range, as long as these extensions are\r
- supported by the transport and adequately documented in the\r
-\r
-\r
-\r
-Borenstein & Freed [Page 33]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Content-Transfer-Encoding header field. However, in no event are\r
- headers (either message headers or body-part headers) allowed to\r
- contain anything other than ASCII characters.\r
-\r
- NOTE: Conspicuously missing from the multipart type is a notion of\r
- structured, related body parts. In general, it seems premature to\r
- try to standardize interpart structure yet. It is recommended\r
- that those wishing to provide a more structured or integrated\r
- multipart messaging facility should define a subtype of multipart\r
- that is syntactically identical, but that always expects the\r
- inclusion of a distinguished part that can be used to specify the\r
- structure and integration of the other parts, probably referring\r
- to them by their Content-ID field. If this approach is used,\r
- other implementations will not recognize the new subtype, but will\r
- treat it as the primary subtype (multipart/mixed) and will thus be\r
- able to show the user the parts that are recognized.\r
-\r
-7.2.2. The Multipart/mixed (primary) subtype\r
-\r
- The primary subtype for multipart, "mixed", is intended for use when\r
- the body parts are independent and need to be bundled in a particular\r
- order. Any multipart subtypes that an implementation does not\r
- recognize must be treated as being of subtype "mixed".\r
-\r
-7.2.3. The Multipart/alternative subtype\r
-\r
- The multipart/alternative type is syntactically identical to\r
- multipart/mixed, but the semantics are different. In particular,\r
- each of the parts is an "alternative" version of the same\r
- information.\r
-\r
- Systems should recognize that the content of the various parts are\r
- interchangeable. Systems should choose the "best" type based on the\r
- local environment and preferences, in some cases even through user\r
- interaction. As with multipart/mixed, the order of body parts is\r
- significant. In this case, the alternatives appear in an order of\r
- increasing faithfulness to the original content. In general, the best\r
- choice is the LAST part of a type supported by the recipient system's\r
- local environment.\r
-\r
- Multipart/alternative may be used, for example, to send mail in a\r
- fancy text format in such a way that it can easily be displayed\r
- anywhere:\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 34]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- From: Nathaniel Borenstein <nsb@bellcore.com>\r
- To: Ned Freed <ned@innosoft.com>\r
- Subject: Formatted text mail\r
- MIME-Version: 1.0\r
- Content-Type: multipart/alternative; boundary=boundary42\r
-\r
- --boundary42\r
-\r
- Content-Type: text/plain; charset=us-ascii\r
-\r
- ...plain text version of message goes here....\r
- --boundary42\r
- Content-Type: text/richtext\r
-\r
- .... RFC 1341 richtext version of same message goes here ...\r
- --boundary42\r
- Content-Type: text/x-whatever\r
-\r
- .... fanciest formatted version of same message goes here\r
- ...\r
- --boundary42--\r
-\r
- In this example, users whose mail system understood the "text/x-\r
- whatever" format would see only the fancy version, while other users\r
- would see only the richtext or plain text version, depending on the\r
- capabilities of their system.\r
-\r
- In general, user agents that compose multipart/alternative entities\r
- must place the body parts in increasing order of preference, that is,\r
- with the preferred format last. For fancy text, the sending user\r
- agent should put the plainest format first and the richest format\r
- last. Receiving user agents should pick and display the last format\r
- they are capable of displaying. In the case where one of the\r
- alternatives is itself of type "multipart" and contains unrecognized\r
- sub-parts, the user agent may choose either to show that alternative,\r
- an earlier alternative, or both.\r
-\r
- NOTE: From an implementor's perspective, it might seem more\r
- sensible to reverse this ordering, and have the plainest\r
- alternative last. However, placing the plainest alternative first\r
- is the friendliest possible option when multipart/alternative\r
- entities are viewed using a non-MIME-conformant mail reader.\r
- While this approach does impose some burden on conformant mail\r
- readers, interoperability with older mail readers was deemed to be\r
- more important in this case.\r
-\r
- It may be the case that some user agents, if they can recognize more\r
- than one of the formats, will prefer to offer the user the choice of\r
-\r
-\r
-\r
-Borenstein & Freed [Page 35]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- which format to view. This makes sense, for example, if mail\r
- includes both a nicely-formatted image version and an easily-edited\r
- text version. What is most critical, however, is that the user not\r
- automatically be shown multiple versions of the same data. Either\r
- the user should be shown the last recognized version or should be\r
- given the choice.\r
-\r
- NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each\r
- part of a multipart/alternative entity represents the same data, but\r
- the mappings between the two are not necessarily without information\r
- loss. For example, information is lost when translating ODA to\r
- PostScript or plain text. It is recommended that each part should\r
- have a different Content-ID value in the case where the information\r
- content of the two parts is not identical. However, where the\r
- information content is identical -- for example, where several parts\r
- of type "application/external- body" specify alternate ways to access\r
- the identical data -- the same Content-ID field value should be used,\r
- to optimize any cacheing mechanisms that might be present on the\r
- recipient's end. However, it is recommended that the Content-ID\r
- values used by the parts should not be the same Content-ID value that\r
- describes the multipart/alternative as a whole, if there is any such\r
- Content-ID field. That is, one Content-ID value will refer to the\r
- multipart/alternative entity, while one or more other Content-ID\r
- values will refer to the parts inside it.\r
-\r
-7.2.4. The Multipart/digest subtype\r
-\r
- This document defines a "digest" subtype of the multipart Content-\r
- Type. This type is syntactically identical to multipart/mixed, but\r
- the semantics are different. In particular, in a digest, the default\r
- Content-Type value for a body part is changed from "text/plain" to\r
- "message/rfc822". This is done to allow a more readable digest\r
- format that is largely compatible (except for the quoting convention)\r
- with RFC 934.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 36]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- A digest in this format might, then, look something like this:\r
-\r
- From: Moderator-Address\r
- To: Recipient-List\r
- MIME-Version: 1.0\r
- Subject: Internet Digest, volume 42\r
- Content-Type: multipart/digest;\r
- boundary="---- next message ----"\r
-\r
- ------ next message ----\r
-\r
- From: someone-else\r
- Subject: my opinion\r
-\r
- ...body goes here ...\r
-\r
- ------ next message ----\r
-\r
- From: someone-else-again\r
- Subject: my different opinion\r
-\r
- ... another body goes here...\r
-\r
- ------ next message ------\r
-\r
-7.2.5. The Multipart/parallel subtype\r
-\r
- This document defines a "parallel" subtype of the multipart Content-\r
- Type. This type is syntactically identical to multipart/mixed, but\r
- the semantics are different. In particular, in a parallel entity,\r
- the order of body parts is not significant.\r
-\r
- A common presentation of this type is to display all of the parts\r
- simultaneously on hardware and software that are capable of doing so.\r
- However, composing agents should be aware that many mail readers will\r
- lack this capability and will show the parts serially in any event.\r
-\r
-7.2.6. Other Multipart subtypes\r
-\r
- Other multipart subtypes are expected in the future. MIME\r
- implementations must in general treat unrecognized subtypes of\r
- multipart as being equivalent to "multipart/mixed".\r
-\r
- The formal grammar for content-type header fields for multipart data\r
- is given by:\r
-\r
- multipart-type := "multipart" "/" multipart-subtype\r
- ";" "boundary" "=" boundary\r
-\r
-\r
-\r
-Borenstein & Freed [Page 37]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- multipart-subtype := "mixed" / "parallel" / "digest"\r
- / "alternative" / extension-token\r
-\r
-7.3. The Message Content-Type\r
-\r
- It is frequently desirable, in sending mail, to encapsulate another\r
- mail message. For this common operation, a special Content-Type,\r
- "message", is defined. The primary subtype, message/rfc822, has no\r
- required parameters in the Content-Type field. Additional subtypes,\r
- "partial" and "External-body", do have required parameters. These\r
- subtypes are explained below.\r
-\r
- NOTE: It has been suggested that subtypes of message might be\r
- defined for forwarded or rejected messages. However, forwarded\r
- and rejected messages can be handled as multipart messages in\r
- which the first part contains any control or descriptive\r
- information, and a second part, of type message/rfc822, is the\r
- forwarded or rejected message. Composing rejection and forwarding\r
- messages in this manner will preserve the type information on the\r
- original message and allow it to be correctly presented to the\r
- recipient, and hence is strongly encouraged.\r
-\r
- As stated in the definition of the Content-Transfer-Encoding field,\r
- no encoding other than "7bit", "8bit", or "binary" is permitted for\r
- messages or parts of type "message". Even stronger restrictions\r
- apply to the subtypes "message/partial" and "message/external-body",\r
- as specified below. The message header fields are always US-ASCII in\r
- any case, and data within the body can still be encoded, in which\r
- case the Content-Transfer-Encoding header field in the encapsulated\r
- message will reflect this. Non-ASCII text in the headers of an\r
- encapsulated message can be specified using the mechanisms described\r
- in [RFC-1522].\r
-\r
- Mail gateways, relays, and other mail handling agents are commonly\r
- known to alter the top-level header of an RFC 822 message. In\r
- particular, they frequently add, remove, or reorder header fields.\r
- Such alterations are explicitly forbidden for the encapsulated\r
- headers embedded in the bodies of messages of type "message."\r
-\r
-7.3.1. The Message/rfc822 (primary) subtype\r
-\r
- A Content-Type of "message/rfc822" indicates that the body contains\r
- an encapsulated message, with the syntax of an RFC 822 message.\r
- However, unlike top-level RFC 822 messages, it is not required that\r
- each message/rfc822 body must include a "From", "Subject", and at\r
- least one destination header.\r
-\r
- It should be noted that, despite the use of the numbers "822", a\r
-\r
-\r
-\r
-Borenstein & Freed [Page 38]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- message/rfc822 entity can include enhanced information as defined in\r
- this document. In other words, a message/rfc822 message may be a\r
- MIME message.\r
-\r
-7.3.2. The Message/Partial subtype\r
-\r
- A subtype of message, "partial", is defined in order to allow large\r
- objects to be delivered as several separate pieces of mail and\r
- automatically reassembled by the receiving user agent. (The concept\r
- is similar to IP fragmentation/reassembly in the basic Internet\r
- Protocols.) This mechanism can be used when intermediate transport\r
- agents limit the size of individual messages that can be sent.\r
- Content-Type "message/partial" thus indicates that the body contains\r
- a fragment of a larger message.\r
-\r
- Three parameters must be specified in the Content-Type field of type\r
- message/partial: The first, "id", is a unique identifier, as close to\r
- a world-unique identifier as possible, to be used to match the parts\r
- together. (In general, the identifier is essentially a message-id;\r
- if placed in double quotes, it can be any message-id, in accordance\r
- with the BNF for "parameter" given earlier in this specification.)\r
- The second, "number", an integer, is the part number, which indicates\r
- where this part fits into the sequence of fragments. The third,\r
- "total", another integer, is the total number of parts. This third\r
- subfield is required on the final part, and is optional (though\r
- encouraged) on the earlier parts. Note also that these parameters\r
- may be given in any order.\r
-\r
- Thus, part 2 of a 3-part message may have either of the following\r
- header fields:\r
-\r
- Content-Type: Message/Partial;\r
- number=2; total=3;\r
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com"\r
-\r
- Content-Type: Message/Partial;\r
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com";\r
- number=2\r
-\r
- But part 3 MUST specify the total number of parts:\r
-\r
- Content-Type: Message/Partial;\r
- number=3; total=3;\r
- id="oc=jpbe0M2Yt4s@thumper.bellcore.com"\r
-\r
- Note that part numbering begins with 1, not 0.\r
-\r
- When the parts of a message broken up in this manner are put\r
-\r
-\r
-\r
-Borenstein & Freed [Page 39]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- together, the result is a complete MIME entity, which may have its\r
- own Content-Type header field, and thus may contain any other data\r
- type.\r
-\r
- Message fragmentation and reassembly: The semantics of a reassembled\r
- partial message must be those of the "inner" message, rather than of\r
- a message containing the inner message. This makes it possible, for\r
- example, to send a large audio message as several partial messages,\r
- and still have it appear to the recipient as a simple audio message\r
- rather than as an encapsulated message containing an audio message.\r
- That is, the encapsulation of the message is considered to be\r
- "transparent".\r
-\r
- When generating and reassembling the parts of a message/partial\r
- message, the headers of the encapsulated message must be merged with\r
- the headers of the enclosing entities. In this process the following\r
- rules must be observed:\r
-\r
- (1) All of the header fields from the initial enclosing entity\r
- (part one), except those that start with "Content-" and the\r
- specific header fields "Message-ID", "Encrypted", and "MIME-\r
- Version", must be copied, in order, to the new message.\r
-\r
- (2) Only those header fields in the enclosed message which start\r
- with "Content-" and "Message-ID", "Encrypted", and "MIME-Version"\r
- must be appended, in order, to the header fields of the new\r
- message. Any header fields in the enclosed message which do not\r
- start with "Content-" (except for "Message-ID", "Encrypted", and\r
- "MIME-Version") will be ignored.\r
-\r
- (3) All of the header fields from the second and any subsequent\r
- messages will be ignored.\r
-\r
- For example, if an audio message is broken into two parts, the first\r
- part might look something like this:\r
-\r
- X-Weird-Header-1: Foo\r
- From: Bill@host.com\r
- To: joe@otherhost.com\r
- Subject: Audio mail\r
- Message-ID: <id1@host.com>\r
- MIME-Version: 1.0\r
- Content-type: message/partial;\r
- id="ABC@host.com";\r
- number=1; total=2\r
-\r
- X-Weird-Header-1: Bar\r
- X-Weird-Header-2: Hello\r
-\r
-\r
-\r
-Borenstein & Freed [Page 40]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Message-ID: <anotherid@foo.com>\r
- MIME-Version: 1.0\r
- Content-type: audio/basic\r
- Content-transfer-encoding: base64\r
-\r
- ... first half of encoded audio data goes here...\r
-\r
- and the second half might look something like this:\r
-\r
- From: Bill@host.com\r
- To: joe@otherhost.com\r
- Subject: Audio mail\r
- MIME-Version: 1.0\r
- Message-ID: <id2@host.com>\r
- Content-type: message/partial;\r
- id="ABC@host.com"; number=2; total=2\r
-\r
- ... second half of encoded audio data goes here...\r
-\r
- Then, when the fragmented message is reassembled, the resulting\r
- message to be displayed to the user should look something like this:\r
-\r
- X-Weird-Header-1: Foo\r
- From: Bill@host.com\r
- To: joe@otherhost.com\r
- Subject: Audio mail\r
- Message-ID: <anotherid@foo.com>\r
- MIME-Version: 1.0\r
- Content-type: audio/basic\r
- Content-transfer-encoding: base64\r
-\r
- ... first half of encoded audio data goes here...\r
- ... second half of encoded audio data goes here...\r
-\r
- Note on encoding of MIME entities encapsulated inside message/partial\r
- entities: Because data of type "message" may never be encoded in\r
- base64 or quoted-printable, a problem might arise if message/partial\r
- entities are constructed in an environment that supports binary or\r
- 8-bit transport. The problem is that the binary data would be split\r
- into multiple message/partial objects, each of them requiring binary\r
- transport. If such objects were encountered at a gateway into a 7-\r
- bit transport environment, there would be no way to properly encode\r
- them for the 7-bit world, aside from waiting for all of the parts,\r
- reassembling the message, and then encoding the reassembled data in\r
- base64 or quoted-printable. Since it is possible that different\r
- parts might go through different gateways, even this is not an\r
- acceptable solution. For this reason, it is specified that MIME\r
- entities of type message/partial must always have a content-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 41]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- transfer-encoding of 7-bit (the default). In particular, even in\r
- environments that support binary or 8-bit transport, the use of a\r
- content-transfer-encoding of "8bit" or "binary" is explicitly\r
- prohibited for entities of type message/partial.\r
-\r
- It should be noted that, because some message transfer agents may\r
- choose to automatically fragment large messages, and because such\r
- agents may use different fragmentation thresholds, it is possible\r
- that the pieces of a partial message, upon reassembly, may prove\r
- themselves to comprise a partial message. This is explicitly\r
- permitted.\r
-\r
- It should also be noted that the inclusion of a "References" field in\r
- the headers of the second and subsequent pieces of a fragmented\r
- message that references the Message-Id on the previous piece may be\r
- of benefit to mail readers that understand and track references.\r
- However, the generation of such "References" fields is entirely\r
- optional.\r
-\r
- Finally, it should be noted that the "Encrypted" header field has\r
- been made obsolete by Privacy Enhanced Messaging (PEM), but the rules\r
- above are believed to describe the correct way to treat it if it is\r
- encountered in the context of conversion to and from message/partial\r
- fragments.\r
-\r
-7.3.3. The Message/External-Body subtype\r
-\r
- The external-body subtype indicates that the actual body data are not\r
- included, but merely referenced. In this case, the parameters\r
- describe a mechanism for accessing the external data.\r
-\r
- When an entity is of type "message/external-body", it consists of a\r
- header, two consecutive CRLFs, and the message header for the\r
- encapsulated message. If another pair of consecutive CRLFs appears,\r
- this of course ends the message header for the encapsulated message.\r
- However, since the encapsulated message's body is itself external, it\r
- does NOT appear in the area that follows. For example, consider the\r
- following message:\r
-\r
- Content-type: message/external-body; access-\r
- type=local-file;\r
-\r
- name="/u/nsb/Me.gif"\r
-\r
- Content-type: image/gif\r
- Content-ID: <id42@guppylake.bellcore.com>\r
- Content-Transfer-Encoding: binary\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 42]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- THIS IS NOT REALLY THE BODY!\r
-\r
- The area at the end, which might be called the "phantom body", is\r
- ignored for most external-body messages. However, it may be used to\r
- contain auxiliary information for some such messages, as indeed it is\r
- when the access-type is "mail-server". Of the access-types defined\r
- by this document, the phantom body is used only when the access-type\r
- is "mail-server". In all other cases, the phantom body is ignored.\r
-\r
- The only always-mandatory parameter for message/external-body is\r
- "access-type"; all of the other parameters may be mandatory or\r
- optional depending on the value of access-type.\r
-\r
- ACCESS-TYPE -- A case-insensitive word, indicating the supported\r
- access mechanism by which the file or data may be obtained.\r
- Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP",\r
- "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for\r
- experimental values beginning with "X-" must be registered with\r
- IANA, as described in Appendix E .\r
-\r
- In addition, the following three parameters are optional for ALL\r
- access-types:\r
-\r
- EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as\r
- extended by RFC 1123 to permit 4 digits in the year field) after\r
- which the existence of the external data is not guaranteed.\r
-\r
- SIZE -- The size (in octets) of the data. The intent of this\r
- parameter is to help the recipient decide whether or not to expend\r
- the necessary resources to retrieve the external data. Note that\r
- this describes the size of the data in its canonical form, that\r
- is, before any Content- Transfer-Encoding has been applied or\r
- after the data have been decoded.\r
-\r
- PERMISSION -- A case-insensitive field that indicates whether or\r
- not it is expected that clients might also attempt to overwrite\r
- the data. By default, or if permission is "read", the assumption\r
- is that they are not, and that if the data is retrieved once, it\r
- is never needed again. If PERMISSION is "read-write", this\r
- assumption is invalid, and any local copy must be considered no\r
- more than a cache. "Read" and "Read-write" are the only defined\r
- values of permission.\r
-\r
- The precise semantics of the access-types defined here are described\r
- in the sections that follow.\r
-\r
- The encapsulated headers in ALL message/external-body entities MUST\r
- include a Content-ID header field to give a unique identifier by\r
-\r
-\r
-\r
-Borenstein & Freed [Page 43]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- which to reference the data. This identifier may be used for\r
- cacheing mechanisms, and for recognizing the receipt of the data when\r
- the access-type is "mail-server".\r
-\r
- Note that, as specified here, the tokens that describe external-body\r
- data, such as file names and mail server commands, are required to be\r
- in the US-ASCII character set. If this proves problematic in\r
- practice, a new mechanism may be required as a future extension to\r
- MIME, either as newly defined access-types for message/external-body\r
- or by some other mechanism.\r
-\r
- As with message/partial, it is specified that MIME entities of type\r
- message/external-body must always have a content-transfer-encoding of\r
- 7-bit (the default). In particular, even in environments that\r
- support binary or 8-bit transport, the use of a content-transfer-\r
- encoding of "8bit" or "binary" is explicitly prohibited for entities\r
- of type message/external-body.\r
-\r
-7.3.3.1. The "ftp" and "tftp" access-types\r
-\r
- An access-type of FTP or TFTP indicates that the message body is\r
- accessible as a file using the FTP [RFC-959] or TFTP [RFC-783]\r
- protocols, respectively. For these access-types, the following\r
- additional parameters are mandatory:\r
-\r
- NAME -- The name of the file that contains the actual body data.\r
-\r
- SITE -- A machine from which the file may be obtained, using the\r
- given protocol. This must be a fully qualified domain name, not a\r
- nickname.\r
-\r
- Before any data are retrieved, using FTP, the user will generally\r
- need to be asked to provide a login id and a password for the machine\r
- named by the site parameter. For security reasons, such an id and\r
- password are not specified as content-type parameters, but must be\r
- obtained from the user.\r
-\r
- In addition, the following parameters are optional:\r
-\r
- DIRECTORY -- A directory from which the data named by NAME should\r
- be retrieved.\r
-\r
- MODE -- A case-insensitive string indicating the mode to be used\r
- when retrieving the information. The legal values for access-type\r
- "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the\r
- TFTP protocol [RFC-783]. The legal values for access-type "FTP"\r
- are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a\r
- decimal integer, typically 8. These correspond to the\r
-\r
-\r
-\r
-Borenstein & Freed [Page 44]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- representation types "A" "E" "I" and "L n" as specified by the FTP\r
- protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid\r
- values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be\r
- used instead. IF MODE is not specified, the default value is\r
- "NETASCII" for TFTP and "ASCII" otherwise.\r
-\r
-7.3.3.2. The "anon-ftp" access-type\r
-\r
- The "anon-ftp" access-type is identical to the "ftp" access type,\r
- except that the user need not be asked to provide a name and password\r
- for the specified site. Instead, the ftp protocol will be used with\r
- login "anonymous" and a password that corresponds to the user's email\r
- address.\r
-\r
-7.3.3.3. The "local-file" and "afs" access-types\r
-\r
- An access-type of "local-file" indicates that the actual body is\r
- accessible as a file on the local machine. An access-type of "afs"\r
- indicates that the file is accessible via the global AFS file system.\r
- In both cases, only a single parameter is required:\r
-\r
- NAME -- The name of the file that contains the actual body data.\r
-\r
- The following optional parameter may be used to describe the locality\r
- of reference for the data, that is, the site or sites at which the\r
- file is expected to be visible:\r
-\r
- SITE -- A domain specifier for a machine or set of machines that\r
- are known to have access to the data file. Asterisks may be used\r
- for wildcard matching to a part of a domain name, such as\r
- "*.bellcore.com", to indicate a set of machines on which the data\r
- should be directly visible, while a single asterisk may be used to\r
- indicate a file that is expected to be universally available,\r
- e.g., via a global file system.\r
-\r
-7.3.3.4. The "mail-server" access-type\r
-\r
- The "mail-server" access-type indicates that the actual body is\r
- available from a mail server. The mandatory parameter for this\r
- access-type is:\r
-\r
- SERVER -- The email address of the mail server from which the\r
- actual body data can be obtained.\r
-\r
- Because mail servers accept a variety of syntaxes, some of which is\r
- multiline, the full command to be sent to a mail server is not\r
- included as a parameter on the content-type line. Instead, it is\r
- provided as the "phantom body" when the content-type is\r
-\r
-\r
-\r
-Borenstein & Freed [Page 45]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- message/external-body and the access- type is mail-server.\r
-\r
- An optional parameter for this access-type is:\r
-\r
- SUBJECT -- The subject that is to be used in the mail that is sent\r
- to obtain the data. Note that keying mail servers on Subject lines\r
- is NOT recommended, but such mail servers are known to exist.\r
-\r
- Note that MIME does not define a mail server syntax. Rather, it\r
- allows the inclusion of arbitrary mail server commands in the phantom\r
- body. Implementations must include the phantom body in the body of\r
- the message it sends to the mail server address to retrieve the\r
- relevant data.\r
-\r
- It is worth noting that, unlike other access-types, mail-server\r
- access is asynchronous and will happen at an unpredictable time in\r
- the future. For this reason, it is important that there be a\r
- mechanism by which the returned data can be matched up with the\r
- original message/external-body entity. MIME mailservers must use the\r
- same Content-ID field on the returned message that was used in the\r
- original message/external-body entity, to facilitate such matching.\r
-\r
-7.3.3.5. Examples and Further Explanations\r
-\r
- With the emerging possibility of very wide-area file systems, it\r
- becomes very hard to know in advance the set of machines where a file\r
- will and will not be accessible directly from the file system.\r
- Therefore it may make sense to provide both a file name, to be tried\r
- directly, and the name of one or more sites from which the file is\r
- known to be accessible. An implementation can try to retrieve remote\r
- files using FTP or any other protocol, using anonymous file retrieval\r
- or prompting the user for the necessary name and password. If an\r
- external body is accessible via multiple mechanisms, the sender may\r
- include multiple parts of type message/external-body within an entity\r
- of type multipart/alternative.\r
-\r
- However, the external-body mechanism is not intended to be limited to\r
- file retrieval, as shown by the mail-server access-type. Beyond\r
- this, one can imagine, for example, using a video server for external\r
- references to video clips.\r
-\r
- If an entity is of type "message/external-body", then the body of the\r
- entity will contain the header fields of the encapsulated message.\r
- The body itself is to be found in the external location. This means\r
- that if the body of the "message/external-body" message contains two\r
- consecutive CRLFs, everything after those pairs is NOT part of the\r
- message itself. For most message/external-body messages, this\r
- trailing area must simply be ignored. However, it is a convenient\r
-\r
-\r
-\r
-Borenstein & Freed [Page 46]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- place for additional data that cannot be included in the content-type\r
- header field. In particular, if the "access-type" value is "mail-\r
- server", then the trailing area must contain commands to be sent to\r
- the mail server at the address given by the value of the SERVER\r
- parameter.\r
-\r
- The embedded message header fields which appear in the body of the\r
- message/external-body data must be used to declare the Content-type\r
- of the external body if it is anything other than plain ASCII text,\r
- since the external body does not have a header section to declare its\r
- type. Similarly, any Content-transfer-encoding other than "7bit"\r
- must also be declared here. Thus a complete message/external-body\r
- message, referring to a document in PostScript format, might look\r
- like this:\r
-\r
- From: Whomever\r
- To: Someone\r
- Subject: whatever\r
- MIME-Version: 1.0\r
- Message-ID: <id1@host.com>\r
- Content-Type: multipart/alternative; boundary=42\r
- Content-ID: <id001@guppylake.bellcore.com>\r
-\r
- --42\r
- Content-Type: message/external-body;\r
- name="BodyFormats.ps";\r
- site="thumper.bellcore.com";\r
- access-type=ANON-FTP;\r
- directory="pub";\r
- mode="image";\r
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"\r
-\r
- Content-type: application/postscript\r
- Content-ID: <id42@guppylake.bellcore.com>\r
-\r
- --42\r
- Content-Type: message/external-body;\r
- name="/u/nsb/writing/rfcs/RFC-MIME.ps";\r
- site="thumper.bellcore.com";\r
- access-type=AFS\r
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"\r
-\r
- Content-type: application/postscript\r
- Content-ID: <id42@guppylake.bellcore.com>\r
-\r
- --42\r
- Content-Type: message/external-body;\r
- access-type=mail-server\r
-\r
-\r
-\r
-Borenstein & Freed [Page 47]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- server="listserv@bogus.bitnet";\r
- expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"\r
-\r
- Content-type: application/postscript\r
- Content-ID: <id42@guppylake.bellcore.com>\r
-\r
- get RFC-MIME.DOC\r
-\r
- --42--\r
-\r
- Note that in the above examples, the default Content-transfer-\r
- encoding of "7bit" is assumed for the external postscript data.\r
-\r
- Like the message/partial type, the message/external-body type is\r
- intended to be transparent, that is, to convey the data type in the\r
- external body rather than to convey a message with a body of that\r
- type. Thus the headers on the outer and inner parts must be merged\r
- using the same rules as for message/partial. In particular, this\r
- means that the Content-type header is overridden, but the From and\r
- Subject headers are preserved.\r
-\r
- Note that since the external bodies are not transported as mail, they\r
- need not conform to the 7-bit and line length requirements, but might\r
- in fact be binary files. Thus a Content-Transfer-Encoding is not\r
- generally necessary, though it is permitted.\r
-\r
- Note that the body of a message of type "message/external-body" is\r
- governed by the basic syntax for an RFC 822 message. In particular,\r
- anything before the first consecutive pair of CRLFs is header\r
- information, while anything after it is body information, which is\r
- ignored for most access-types.\r
-\r
- The formal grammar for content-type header fields for data of type\r
- message is given by:\r
-\r
- message-type := "message" "/" message-subtype\r
-\r
- message-subtype := "rfc822"\r
- / "partial" 2#3partial-param\r
- / "external-body" 1*external-param\r
- / extension-token\r
-\r
- partial-param := (";" "id" "=" value)\r
- / (";" "number" "=" 1*DIGIT)\r
- / (";" "total" "=" 1*DIGIT)\r
- ; id & number required; total required for last part\r
-\r
- external-param := (";" "access-type" "=" atype)\r
-\r
-\r
-\r
-Borenstein & Freed [Page 48]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- / (";" "expiration" "=" date-time)\r
- ; Note that date-time is quoted\r
- / (";" "size" "=" 1*DIGIT)\r
- / (";" "permission" "=" ("read" / "read-write"))\r
- ; Permission is case-insensitive\r
- / (";" "name" "=" value)\r
- / (";" "site" "=" value)\r
- / (";" "dir" "=" value)\r
- / (";" "mode" "=" value)\r
- / (";" "server" "=" value)\r
- / (";" "subject" "=" value)\r
- ; access-type required;others required based on access-type\r
-\r
- atype := "ftp" / "anon-ftp" / "tftp" / "local-file"\r
- / "afs" / "mail-server" / extension-token\r
- ; Case-insensitive\r
-\r
-7.4. The Application Content-Type\r
-\r
- The "application" Content-Type is to be used for data which do not\r
- fit in any of the other categories, and particularly for data to be\r
- processed by mail-based uses of application programs. This is\r
- information which must be processed by an application before it is\r
- viewable or usable to a user. Expected uses for Content-Type\r
- application include mail-based file transfer, spreadsheets, data for\r
- mail-based scheduling systems, and languages for "active"\r
- (computational) email. (The latter, in particular, can pose security\r
- problems which must be understood by implementors, and are considered\r
- in detail in the discussion of the application/PostScript content-\r
- type.)\r
-\r
- For example, a meeting scheduler might define a standard\r
- representation for information about proposed meeting dates. An\r
- intelligent user agent would use this information to conduct a dialog\r
- with the user, and might then send further mail based on that dialog.\r
- More generally, there have been several "active" messaging languages\r
- developed in which programs in a suitably specialized language are\r
- sent through the mail and automatically run in the recipient's\r
- environment.\r
-\r
- Such applications may be defined as subtypes of the "application"\r
- Content-Type. This document defines two subtypes: octet-stream, and\r
- PostScript.\r
-\r
- In general, the subtype of application will often be the name of the\r
- application for which the data are intended. This does not mean,\r
- however, that any application program name may be used freely as a\r
- subtype of application. Such usages (other than subtypes beginning\r
-\r
-\r
-\r
-Borenstein & Freed [Page 49]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- with "x-") must be registered with IANA, as described in Appendix E.\r
-\r
-7.4.1. The Application/Octet-Stream (primary) subtype\r
-\r
- The primary subtype of application, "octet-stream", may be used to\r
- indicate that a body contains binary data. The set of possible\r
- parameters includes, but is not limited to:\r
-\r
- TYPE -- the general type or category of binary data. This is\r
- intended as information for the human recipient rather than for\r
- any automatic processing.\r
-\r
- PADDING -- the number of bits of padding that were appended to the\r
- bit-stream comprising the actual contents to produce the enclosed\r
- byte-oriented data. This is useful for enclosing a bit-stream in\r
- a body when the total number of bits is not a multiple of the byte\r
- size.\r
-\r
- An additional parameter, "conversions", was defined in [RFC-1341] but\r
- has been removed.\r
-\r
- RFC 1341 also defined the use of a "NAME" parameter which gave a\r
- suggested file name to be used if the data were to be written to a\r
- file. This has been deprecated in anticipation of a separate\r
- Content-Disposition header field, to be defined in a subsequent RFC.\r
-\r
- The recommended action for an implementation that receives\r
- application/octet-stream mail is to simply offer to put the data in a\r
- file, with any Content-Transfer-Encoding undone, or perhaps to use it\r
- as input to a user-specified process.\r
-\r
- To reduce the danger of transmitting rogue programs through the mail,\r
- it is strongly recommended that implementations NOT implement a\r
- path-search mechanism whereby an arbitrary program named in the\r
- Content-Type parameter (e.g., an "interpreter=" parameter) is found\r
- and executed using the mail body as input.\r
-\r
-7.4.2. The Application/PostScript subtype\r
-\r
- A Content-Type of "application/postscript" indicates a PostScript\r
- program. Currently two variants of the PostScript language are\r
- allowed; the original level 1 variant is described in [POSTSCRIPT]\r
- and the more recent level 2 variant is described in [POSTSCRIPT2].\r
-\r
- PostScript is a registered trademark of Adobe Systems, Inc. Use of\r
- the MIME content-type "application/postscript" implies recognition of\r
- that trademark and all the rights it entails.\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 50]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- The PostScript language definition provides facilities for internal\r
- labeling of the specific language features a given program uses. This\r
- labeling, called the PostScript document structuring conventions, is\r
- very general and provides substantially more information than just\r
- the language level.\r
-\r
- The use of document structuring conventions, while not required, is\r
- strongly recommended as an aid to interoperability. Documents which\r
- lack proper structuring conventions cannot be tested to see whether\r
- or not they will work in a given environment. As such, some systems\r
- may assume the worst and refuse to process unstructured documents.\r
-\r
- The execution of general-purpose PostScript interpreters entails\r
- serious security risks, and implementors are discouraged from simply\r
- sending PostScript email bodies to "off-the-shelf" interpreters.\r
- While it is usually safe to send PostScript to a printer, where the\r
- potential for harm is greatly constrained, implementors should\r
- consider all of the following before they add interactive display of\r
- PostScript bodies to their mail readers.\r
-\r
- The remainder of this section outlines some, though probably not all,\r
- of the possible problems with sending PostScript through the mail.\r
-\r
- Dangerous operations in the PostScript language include, but may not\r
- be limited to, the PostScript operators deletefile, renamefile,\r
- filenameforall, and file. File is only dangerous when applied to\r
- something other than standard input or output. Implementations may\r
- also define additional nonstandard file operators; these may also\r
- pose a threat to security. Filenameforall, the wildcard file search\r
- operator, may appear at first glance to be harmless. Note, however,\r
- that this operator has the potential to reveal information about what\r
- files the recipient has access to, and this information may itself be\r
- sensitive. Message senders should avoid the use of potentially\r
- dangerous file operators, since these operators are quite likely to\r
- be unavailable in secure PostScript implementations. Message-\r
- receiving and -displaying software should either completely disable\r
- all potentially dangerous file operators or take special care not to\r
- delegate any special authority to their operation. These operators\r
- should be viewed as being done by an outside agency when interpreting\r
- PostScript documents. Such disabling and/or checking should be done\r
- completely outside of the reach of the PostScript language itself;\r
- care should be taken to insure that no method exists for re-enabling\r
- full-function versions of these operators.\r
-\r
- The PostScript language provides facilities for exiting the normal\r
- interpreter, or server, loop. Changes made in this "outer"\r
- environment are customarily retained across documents, and may in\r
- some cases be retained semipermanently in nonvolatile memory. The\r
-\r
-\r
-\r
-Borenstein & Freed [Page 51]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- operators associated with exiting the interpreter loop have the\r
- potential to interfere with subsequent document processing. As such,\r
- their unrestrained use constitutes a threat of service denial.\r
- PostScript operators that exit the interpreter loop include, but may\r
- not be limited to, the exitserver and startjob operators. Message-\r
- sending software should not generate PostScript that depends on\r
- exiting the interpreter loop to operate. The ability to exit will\r
- probably be unavailable in secure PostScript implementations.\r
- Message-receiving and -displaying software should, if possible,\r
- disable the ability to make retained changes to the PostScript\r
- environment, and eliminate the startjob and exitserver commands. If\r
- these commands cannot be eliminated, the password associated with\r
- them should at least be set to a hard-to-guess value.\r
-\r
- PostScript provides operators for setting system-wide and device-\r
- specific parameters. These parameter settings may be retained across\r
- jobs and may potentially pose a threat to the correct operation of\r
- the interpreter. The PostScript operators that set system and device\r
- parameters include, but may not be limited to, the setsystemparams\r
- and setdevparams operators. Message-sending software should not\r
- generate PostScript that depends on the setting of system or device\r
- parameters to operate correctly. The ability to set these parameters\r
- will probably be unavailable in secure PostScript implementations.\r
- Message-receiving and -displaying software should, if possible,\r
- disable the ability to change system and device parameters. If these\r
- operators cannot be disabled, the password associated with them\r
- should at least be set to a hard-to-guess value.\r
-\r
- Some PostScript implementations provide nonstandard facilities for\r
- the direct loading and execution of machine code. Such facilities\r
- are quite obviously open to substantial abuse. Message-sending\r
- software should not make use of such features. Besides being totally\r
- hardware- specific, they are also likely to be unavailable in secure\r
- implementations of PostScript. Message-receiving and -displaying\r
- software should not allow such operators to be used if they exist.\r
-\r
- PostScript is an extensible language, and many, if not most,\r
- implementations of it provide a number of their own extensions. This\r
- document does not deal with such extensions explicitly since they\r
- constitute an unknown factor. Message-sending software should not\r
- make use of nonstandard extensions; they are likely to be missing\r
- from some implementations. Message-receiving and -displaying software\r
- should make sure that any nonstandard PostScript operators are secure\r
- and don't present any kind of threat.\r
-\r
- It is possible to write PostScript that consumes huge amounts of\r
- various system resources. It is also possible to write PostScript\r
- programs that loop infinitely. Both types of programs have the\r
-\r
-\r
-\r
-Borenstein & Freed [Page 52]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- potential to cause damage if sent to unsuspecting recipients.\r
- Message-sending software should avoid the construction and\r
- dissemination of such programs, which is antisocial. Message-\r
- receiving and -displaying software should provide appropriate\r
- mechanisms to abort processing of a document after a reasonable\r
- amount of time has elapsed. In addition, PostScript interpreters\r
- should be limited to the consumption of only a reasonable amount of\r
- any given system resource.\r
-\r
- Finally, bugs may exist in some PostScript interpreters which could\r
- possibly be exploited to gain unauthorized access to a recipient's\r
- system. Apart from noting this possibility, there is no specific\r
- action to take to prevent this, apart from the timely correction of\r
- such bugs if any are found.\r
-\r
-7.4.3. Other Application subtypes\r
-\r
- It is expected that many other subtypes of application will be\r
- defined in the future. MIME implementations must generally treat any\r
- unrecognized subtypes as being equivalent to application/octet-\r
- stream.\r
-\r
- The formal grammar for content-type header fields for application\r
- data is given by:\r
-\r
- application-type := "application" "/" application-subtype\r
-\r
- application-subtype := ("octet-stream" *stream-param)\r
- / "postscript" / extension-token\r
-\r
- stream-param := (";" "type" "=" value)\r
- / (";" "padding" "=" padding)\r
-\r
- padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"\r
-\r
-7.5. The Image Content-Type\r
-\r
- A Content-Type of "image" indicates that the body contains an image.\r
- The subtype names the specific image format. These names are case\r
- insensitive. Two initial subtypes are "jpeg" for the JPEG format,\r
- JFIF encoding, and "gif" for GIF format [GIF].\r
-\r
- The list of image subtypes given here is neither exclusive nor\r
- exhaustive, and is expected to grow as more types are registered with\r
- IANA, as described in Appendix E.\r
-\r
- The formal grammar for the content-type header field for data of type\r
- image is given by:\r
-\r
-\r
-\r
-Borenstein & Freed [Page 53]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- image-type := "image" "/" ("gif" / "jpeg" / extension-token)\r
-\r
-7.6. The Audio Content-Type\r
-\r
- A Content-Type of "audio" indicates that the body contains audio\r
- data. Although there is not yet a consensus on an "ideal" audio\r
- format for use with computers, there is a pressing need for a format\r
- capable of providing interoperable behavior.\r
-\r
- The initial subtype of "basic" is specified to meet this requirement\r
- by providing an absolutely minimal lowest common denominator audio\r
- format. It is expected that richer formats for higher quality and/or\r
- lower bandwidth audio will be defined by a later document.\r
-\r
- The content of the "audio/basic" subtype is audio encoded using 8-bit\r
- ISDN mu-law [PCM]. When this subtype is present, a sample rate of\r
- 8000 Hz and a single channel is assumed.\r
-\r
- The formal grammar for the content-type header field for data of type\r
- audio is given by:\r
-\r
- audio-type := "audio" "/" ("basic" / extension-token)\r
-\r
-7.7. The Video Content-Type\r
-\r
- A Content-Type of "video" indicates that the body contains a time-\r
- varying-picture image, possibly with color and coordinated sound.\r
- The term "video" is used extremely generically, rather than with\r
- reference to any particular technology or format, and is not meant to\r
- preclude subtypes such as animated drawings encoded compactly. The\r
- subtype "mpeg" refers to video coded according to the MPEG standard\r
- [MPEG].\r
-\r
- Note that although in general this document strongly discourages the\r
- mixing of multiple media in a single body, it is recognized that many\r
- so-called "video" formats include a representation for synchronized\r
- audio, and this is explicitly permitted for subtypes of "video".\r
-\r
- The formal grammar for the content-type header field for data of type\r
- video is given by:\r
-\r
- video-type := "video" "/" ("mpeg" / extension-token)\r
-\r
-7.8. Experimental Content-Type Values\r
-\r
- A Content-Type value beginning with the characters "X-" is a private\r
- value, to be used by consenting mail systems by mutual agreement.\r
- Any format without a rigorous and public definition must be named\r
-\r
-\r
-\r
-Borenstein & Freed [Page 54]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- with an "X-" prefix, and publicly specified values shall never begin\r
- with "X-". (Older versions of the widely-used Andrew system use the\r
- "X-BE2" name, so new systems should probably choose a different\r
- name.)\r
-\r
- In general, the use of "X-" top-level types is strongly discouraged.\r
- Implementors should invent subtypes of the existing types whenever\r
- possible. The invention of new types is intended to be restricted\r
- primarily to the development of new media types for email, such as\r
- digital odors or holography, and not for new data formats in general.\r
- In many cases, a subtype of application will be more appropriate than\r
- a new top-level type.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 55]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-8. Summary\r
-\r
- Using the MIME-Version, Content-Type, and Content-Transfer-Encoding\r
- header fields, it is possible to include, in a standardized way,\r
- arbitrary types of data objects with RFC 822 conformant mail\r
- messages. No restrictions imposed by either RFC 821 or RFC 822 are\r
- violated, and care has been taken to avoid problems caused by\r
- additional restrictions imposed by the characteristics of some\r
- Internet mail transport mechanisms (see Appendix B). The "multipart"\r
- and "message" Content-Types allow mixing and hierarchical structuring\r
- of objects of different types in a single message. Further Content-\r
- Types provide a standardized mechanism for tagging messages or body\r
- parts as audio, image, or several other kinds of data. A\r
- distinguished parameter syntax allows further specification of data\r
- format details, particularly the specification of alternate character\r
- sets. Additional optional header fields provide mechanisms for\r
- certain extensions deemed desirable by many implementors. Finally, a\r
- number of useful Content-Types are defined for general use by\r
- consenting user agents, notably message/partial, and\r
- message/external-body.\r
-\r
-9. Security Considerations\r
-\r
- Security issues are discussed in Section 7.4.2 and in Appendix F.\r
- Implementors should pay special attention to the security\r
- implications of any mail content-types that can cause the remote\r
- execution of any actions in the recipient's environment. In such\r
- cases, the discussion of the application/postscript content-type in\r
- Section 7.4.2 may serve as a model for considering other content-\r
- types with remote execution capabilities.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 56]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-10. Authors' Addresses\r
-\r
- For more information, the authors of this document may be contacted\r
- via Internet mail:\r
-\r
- Nathaniel S. Borenstein\r
- MRE 2D-296, Bellcore\r
- 445 South St.\r
- Morristown, NJ 07962-1910\r
-\r
- Phone: +1 201 829 4270\r
- Fax: +1 201 829 7019\r
- Email: nsb@bellcore.com\r
-\r
-\r
- Ned Freed\r
- Innosoft International, Inc.\r
- 250 West First Street\r
- Suite 240\r
- Claremont, CA 91711\r
-\r
- Phone: +1 909 624 7907\r
- Fax: +1 909 621 5319\r
- Email: ned@innosoft.com\r
-\r
- MIME is a result of the work of the Internet Engineering Task Force\r
- Working Group on Email Extensions. The chairman of that group, Greg\r
- Vaudreuil, may be reached at:\r
-\r
- Gregory M. Vaudreuil\r
- Tigon Corporation\r
- 17060 Dallas Parkway\r
- Dallas Texas, 75248\r
-\r
- Phone: +1 214-733-2722\r
- EMail: gvaudre@cnri.reston.va.us\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 57]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-11. Acknowledgements\r
-\r
- This document is the result of the collective effort of a large\r
- number of people, at several IETF meetings, on the IETF-SMTP and\r
- IETF-822 mailing lists, and elsewhere. Although any enumeration\r
- seems doomed to suffer from egregious omissions, the following are\r
- among the many contributors to this effort:\r
-\r
- Harald Tveit Alvestrand Timo Lehtinen\r
- Randall Atkinson John R. MacMillan\r
- Philippe Brandon Rick McGowan\r
- Kevin Carosso Leo Mclaughlin\r
- Uhhyung Choi Goli Montaser-Kohsari\r
- Cristian Constantinof Keith Moore\r
- Mark Crispin Tom Moore\r
- Dave Crocker Erik Naggum\r
- Terry Crowley Mark Needleman\r
- Walt Daniels John Noerenberg\r
- Frank Dawson Mats Ohrman\r
- Hitoshi Doi Julian Onions\r
- Kevin Donnelly Michael Patton\r
- Keith Edwards David J. Pepper\r
- Chris Eich Blake C. Ramsdell\r
- Johnny Eriksson Luc Rooijakkers\r
- Craig Everhart Marshall T. Rose\r
- Patrik Faeltstroem Jonathan Rosenberg\r
- Erik E. Fair Jan Rynning\r
- Roger Fajman Harri Salminen\r
- Alain Fontaine Michael Sanderson\r
- James M. Galvin Masahiro Sekiguchi\r
- Philip Gladstone Mark Sherman\r
- Thomas Gordon Keld Simonsen\r
- Phill Gross Bob Smart\r
- James Hamilton Peter Speck\r
- Steve Hardcastle-Kille Henry Spencer\r
- David Herron Einar Stefferud\r
- Bruce Howard Michael Stein\r
- Bill Janssen Klaus Steinberger\r
- Olle Jaernefors Peter Svanberg\r
- Risto Kankkunen James Thompson\r
- Phil Karn Steve Uhler\r
- Alan Katz Stuart Vance\r
- Tim Kehres Erik van der Poel\r
- Neil Katin Guido van Rossum\r
- Kyuho Kim Peter Vanderbilt\r
- Anders Klemets Greg Vaudreuil\r
- John Klensin Ed Vielmetti\r
- Valdis Kletniek Ryan Waldron\r
-\r
-\r
-\r
-Borenstein & Freed [Page 58]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Jim Knowles Wally Wedel\r
- Stev Knowles Sven-Ove Westberg\r
- Bob Kummerfeld Brian Wideen\r
- Pekka Kytolaakso John Wobus\r
- Stellan Lagerstrom Glenn Wright\r
- Vincent Lau Rayan Zachariassen\r
- Donald Lindsay David Zimmerman\r
- Marc Andreessen Bob Braden\r
- Brian Capouch Peter Clitherow\r
- Dave Collier-Brown John Coonrod\r
- Stephen Crocker Jim Davis\r
- Axel Deininger Dana S Emery\r
- Martin Forssen Stephen Gildea\r
- Terry Gray Mark Horton\r
- Warner Losh Carlyn Lowery\r
- Laurence Lundblade Charles Lynn\r
- Larry Masinter Michael J. McInerny\r
- Jon Postel Christer Romson\r
- Yutaka Sato Markku Savela\r
- Richard Alan Schafer Larry W. Virden\r
- Rhys Weatherly Jay Weber\r
- Dave Wecker\r
-\r
-The authors apologize for any omissions from this list, which are\r
-certainly unintentional.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 59]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix A -- Minimal MIME-Conformance\r
-\r
- The mechanisms described in this document are open-ended. It is\r
- definitely not expected that all implementations will support all of\r
- the Content-Types described, nor that they will all share the same\r
- extensions. In order to promote interoperability, however, it is\r
- useful to define the concept of "MIME-conformance" to define a\r
- certain level of implementation that allows the useful interworking\r
- of messages with content that differs from US ASCII text. In this\r
- section, we specify the requirements for such conformance.\r
-\r
- A mail user agent that is MIME-conformant MUST:\r
-\r
- 1. Always generate a "MIME-Version: 1.0" header field.\r
-\r
- 2. Recognize the Content-Transfer-Encoding header field, and\r
- decode all received data encoded with either the quoted-printable\r
- or base64 implementations. Encode any data sent that is not in\r
- seven-bit mail-ready representation using one of these\r
- transformations and include the appropriate Content-Transfer-\r
- Encoding header field, unless the underlying transport mechanism\r
- supports non-seven-bit data, as SMTP does not.\r
-\r
- 3. Recognize and interpret the Content-Type header field, and\r
- avoid showing users raw data with a Content-Type field other than\r
- text. Be able to send at least text/plain messages, with the\r
- character set specified as a parameter if it is not US-ASCII.\r
-\r
- 4. Explicitly handle the following Content-Type values, to at\r
- least the following extents:\r
-\r
- Text:\r
-\r
- -- Recognize and display "text" mail\r
- with the character set "US-ASCII."\r
-\r
- -- Recognize other character sets at\r
- least to the extent of being able\r
- to inform the user about what\r
- character set the message uses.\r
-\r
- -- Recognize the "ISO-8859-*" character\r
- sets to the extent of being able to\r
- display those characters that are\r
- common to ISO-8859-* and US-ASCII,\r
- namely all characters represented\r
- by octet values 0-127.\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 60]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- -- For unrecognized subtypes, show or\r
- offer to show the user the "raw"\r
- version of the data after\r
- conversion of the content from\r
- canonical form to local form.\r
-\r
- Message:\r
-\r
- -- Recognize and display at least the\r
- primary (822) encapsulation.\r
-\r
- Multipart:\r
-\r
- -- Recognize the primary (mixed)\r
- subtype. Display all relevant\r
- information on the message level\r
- and the body part header level and\r
- then display or offer to display\r
- each of the body parts individually.\r
-\r
- -- Recognize the "alternative" subtype,\r
- and avoid showing the user\r
- redundant parts of\r
- multipart/alternative mail.\r
-\r
- -- Treat any unrecognized subtypes as if\r
- they were "mixed".\r
-\r
- Application:\r
-\r
- -- Offer the ability to remove either of\r
- the two types of Content-Transfer-\r
- Encoding defined in this document\r
- and put the resulting information\r
- in a user file.\r
-\r
- 5. Upon encountering any unrecognized Content- Type, an\r
- implementation must treat it as if it had a Content-Type of\r
- "application/octet-stream" with no parameter sub-arguments. How\r
- such data are handled is up to an implementation, but likely\r
- options for handling such unrecognized data include offering the\r
- user to write it into a file (decoded from its mail transport\r
- format) or offering the user to name a program to which the\r
- decoded data should be passed as input. Unrecognized predefined\r
- types, which in a MIME-conformant mailer might still include\r
- audio, image, or video, should also be treated in this way.\r
-\r
- A user agent that meets the above conditions is said to be MIME-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 61]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- conformant. The meaning of this phrase is that it is assumed to be\r
- "safe" to send virtually any kind of properly-marked data to users of\r
- such mail systems, because such systems will at least be able to\r
- treat the data as undifferentiated binary, and will not simply splash\r
- it onto the screen of unsuspecting users. There is another sense in\r
- which it is always "safe" to send data in a format that is MIME-\r
- conformant, which is that such data will not break or be broken by\r
- any known systems that are conformant with RFC 821 and RFC 822. User\r
- agents that are MIME-conformant have the additional guarantee that\r
- the user will not be shown data that were never intended to be viewed\r
- as text.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 62]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix B -- General Guidelines For Sending Email Data\r
-\r
- Internet email is not a perfect, homogeneous system. Mail may become\r
- corrupted at several stages in its travel to a final destination.\r
- Specifically, email sent throughout the Internet may travel across\r
- many networking technologies. Many networking and mail technologies\r
- do not support the full functionality possible in the SMTP transport\r
- environment. Mail traversing these systems is likely to be modified\r
- in such a way that it can be transported.\r
-\r
- There exist many widely-deployed non-conformant MTAs in the Internet.\r
- These MTAs, speaking the SMTP protocol, alter messages on the fly to\r
- take advantage of the internal data structure of the hosts they are\r
- implemented on, or are just plain broken.\r
-\r
- The following guidelines may be useful to anyone devising a data\r
- format (Content-Type) that will survive the widest range of\r
- networking technologies and known broken MTAs unscathed. Note that\r
- anything encoded in the base64 encoding will satisfy these rules, but\r
- that some well-known mechanisms, notably the UNIX uuencode facility,\r
- will not. Note also that anything encoded in the Quoted-Printable\r
- encoding will survive most gateways intact, but possibly not some\r
- gateways to systems that use the EBCDIC character set.\r
-\r
- (1) Under some circumstances the encoding used for data may change\r
- as part of normal gateway or user agent operation. In particular,\r
- conversion from base64 to quoted-printable and vice versa may be\r
- necessary. This may result in the confusion of CRLF sequences with\r
- line breaks in text bodies. As such, the persistence of CRLF as\r
- something other than a line break must not be relied on.\r
-\r
- (2) Many systems may elect to represent and store text data using\r
- local newline conventions. Local newline conventions may not match\r
- the RFC822 CRLF convention -- systems are known that use plain CR,\r
- plain LF, CRLF, or counted records. The result is that isolated\r
- CR and LF characters are not well tolerated in general; they may\r
- be lost or converted to delimiters on some systems, and hence must\r
- not be relied on.\r
-\r
- (3) TAB (HT) characters may be misinterpreted or may be\r
- automatically converted to variable numbers of spaces. This is\r
- unavoidable in some environments, notably those not based on the\r
- ASCII character set. Such conversion is STRONGLY DISCOURAGED, but\r
- it may occur, and mail formats must not rely on the persistence of\r
- TAB (HT) characters.\r
-\r
- (4) Lines longer than 76 characters may be wrapped or truncated in\r
- some environments. Line wrapping and line truncation are STRONGLY\r
-\r
-\r
-\r
-Borenstein & Freed [Page 63]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- DISCOURAGED, but unavoidable in some cases. Applications which\r
- require long lines must somehow differentiate between soft and\r
- hard line breaks. (A simple way to do this is to use the quoted-\r
- printable encoding.)\r
-\r
- (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line\r
- may be discarded by some transport agents, while other transport\r
- agents may pad lines with these characters so that all lines in a\r
- mail file are of equal length. The persistence of trailing white\r
- space, therefore, must not be relied on.\r
-\r
- (6) Many mail domains use variations on the ASCII character set,\r
- or use character sets such as EBCDIC which contain most but not\r
- all of the US-ASCII characters. The correct translation of\r
- characters not in the "invariant" set cannot be depended on across\r
- character converting gateways. For example, this situation is a\r
- problem when sending uuencoded information across BITNET, an\r
- EBCDIC system. Similar problems can occur without crossing a\r
- gateway, since many Internet hosts use character sets other than\r
- ASCII internally. The definition of Printable Strings in X.400\r
- adds further restrictions in certain special cases. In\r
- particular, the only characters that are known to be consistent\r
- across all gateways are the 73 characters that correspond to the\r
- upper and lower case letters A-Z and a-z, the 10 digits 0-9, and\r
- the following eleven special characters:\r
-\r
- "'" (ASCII code 39)\r
- "(" (ASCII code 40)\r
- ")" (ASCII code 41)\r
- "+" (ASCII code 43)\r
- "," (ASCII code 44)\r
- "-" (ASCII code 45)\r
- "." (ASCII code 46)\r
- "/" (ASCII code 47)\r
- ":" (ASCII code 58)\r
- "=" (ASCII code 61)\r
- "?" (ASCII code 63)\r
-\r
- A maximally portable mail representation, such as the base64\r
- encoding, will confine itself to relatively short lines of text in\r
- which the only meaningful characters are taken from this set of 73\r
- characters.\r
-\r
- (7) Some mail transport agents will corrupt data that includes\r
- certain literal strings. In particular, a period (".") alone on a\r
- line is known to be corrupted by some (incorrect) SMTP\r
- implementations, and a line that starts with the five characters\r
- "From " (the fifth character is a SPACE) are commonly corrupted as\r
-\r
-\r
-\r
-Borenstein & Freed [Page 64]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- well. A careful composition agent can prevent these corruptions\r
- by encoding the data (e.g., in the quoted-printable encoding,\r
- "=46rom " in place of "From " at the start of a line, and "=2E" in\r
- place of "." alone on a line.\r
-\r
- Please note that the above list is NOT a list of recommended\r
- practices for MTAs. RFC 821 MTAs are prohibited from altering the\r
- character of white space or wrapping long lines. These BAD and\r
- illegal practices are known to occur on established networks, and\r
- implementations should be robust in dealing with the bad effects they\r
- can cause.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 65]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix C -- A Complex Multipart Example\r
-\r
- What follows is the outline of a complex multipart message. This\r
- message has five parts to be displayed serially: two introductory\r
- plain text parts, an embedded multipart message, a richtext part, and\r
- a closing encapsulated text message in a non-ASCII character set.\r
- The embedded multipart message has two parts to be displayed in\r
- parallel, a picture and an audio fragment.\r
-\r
- MIME-Version: 1.0\r
- From: Nathaniel Borenstein <nsb@bellcore.com>\r
- To: Ned Freed <ned@innosoft.com>\r
- Subject: A multipart example\r
- Content-Type: multipart/mixed;\r
- boundary=unique-boundary-1\r
-\r
- This is the preamble area of a multipart message.\r
- Mail readers that understand multipart format\r
- should ignore this preamble.\r
- If you are reading this text, you might want to\r
- consider changing to a mail reader that understands\r
- how to properly display multipart messages.\r
- --unique-boundary-1\r
-\r
- ...Some text appears here...\r
- [Note that the preceding blank line means\r
- no header fields were given and this is text,\r
- with charset US ASCII. It could have been\r
- done with explicit typing as in the next part.]\r
-\r
- --unique-boundary-1\r
- Content-type: text/plain; charset=US-ASCII\r
-\r
- This could have been part of the previous part,\r
- but illustrates explicit versus implicit\r
- typing of body parts.\r
-\r
- --unique-boundary-1\r
- Content-Type: multipart/parallel;\r
- boundary=unique-boundary-2\r
-\r
-\r
- --unique-boundary-2\r
- Content-Type: audio/basic\r
- Content-Transfer-Encoding: base64\r
-\r
- ... base64-encoded 8000 Hz single-channel\r
- mu-law-format audio data goes here....\r
-\r
-\r
-\r
-Borenstein & Freed [Page 66]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- --unique-boundary-2\r
- Content-Type: image/gif\r
- Content-Transfer-Encoding: base64\r
-\r
- ... base64-encoded image data goes here....\r
-\r
- --unique-boundary-2--\r
-\r
- --unique-boundary-1\r
- Content-type: text/richtext\r
-\r
- This is <bold><italic>richtext.</italic></bold>\r
- <smaller>as defined in RFC 1341</smaller>\r
- <nl><nl>Isn't it\r
- <bigger><bigger>cool?</bigger></bigger>\r
-\r
- --unique-boundary-1\r
- Content-Type: message/rfc822\r
-\r
- From: (mailbox in US-ASCII)\r
- To: (address in US-ASCII)\r
- Subject: (subject in US-ASCII)\r
- Content-Type: Text/plain; charset=ISO-8859-1\r
- Content-Transfer-Encoding: Quoted-printable\r
-\r
- ... Additional text in ISO-8859-1 goes here ...\r
-\r
- --unique-boundary-1--\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 67]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix D -- Collected Grammar\r
-\r
- This appendix contains the complete BNF grammar for all the syntax\r
- specified by this document.\r
-\r
- By itself, however, this grammar is incomplete. It refers to several\r
- entities that are defined by RFC 822. Rather than reproduce those\r
- definitions here, and risk unintentional differences between the two,\r
- this document simply refers the reader to RFC 822 for the remaining\r
- definitions. Wherever a term is undefined, it refers to the RFC 822\r
- definition.\r
-\r
- application-subtype := ("octet-stream" *stream-param)\r
- / "postscript" / extension-token\r
-\r
- application-type := "application" "/" application-subtype\r
-\r
- attribute := token ; case-insensitive\r
-\r
- atype := "ftp" / "anon-ftp" / "tftp" / "local-file"\r
- / "afs" / "mail-server" / extension-token\r
- ; Case-insensitive\r
-\r
- audio-type := "audio" "/" ("basic" / extension-token)\r
-\r
- body-part := <"message" as defined in RFC 822,\r
- with all header fields optional, and with the\r
- specified delimiter not occurring anywhere in\r
- the message body, either on a line by itself\r
- or as a substring anywhere.>\r
-\r
- NOTE: In certain transport enclaves, RFC 822 restrictions such as\r
- the one that limits bodies to printable ASCII characters may not\r
- be in force. (That is, the transport domains may resemble\r
- standard Internet mail transport as specified in RFC821 and\r
- assumed by RFC822, but without certain restrictions.) The\r
- relaxation of these restrictions should be construed as locally\r
- extending the definition of bodies, for example to include octets\r
- outside of the ASCII range, as long as these extensions are\r
- supported by the transport and adequately documented in the\r
- Content-Transfer-Encoding header field. However, in no event are\r
- headers (either message headers or body-part headers) allowed to\r
- contain anything other than ASCII characters.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 68]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- boundary := 0*69<bchars> bcharsnospace\r
-\r
- bchars := bcharsnospace / " "\r
-\r
- bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_"\r
- / "," / "-" / "." / "/" / ":" / "=" / "?"\r
-\r
- charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3"\r
- / "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7"\r
- / "iso-8859-8" / "iso-8859-9" / extension-token\r
- ; case insensitive\r
-\r
- close-delimiter := "--" boundary "--" CRLF;Again,no space by "--",\r
-\r
- content := "Content-Type" ":" type "/" subtype *(";" parameter)\r
- ; case-insensitive matching of type and subtype\r
-\r
- delimiter := "--" boundary CRLF ;taken from Content-Type field.\r
- ; There must be no space\r
- ; between "--" and boundary.\r
-\r
- description := "Content-Description" ":" *text\r
-\r
- discard-text := *(*text CRLF)\r
-\r
- encapsulation := delimiter body-part CRLF\r
-\r
- encoding := "Content-Transfer-Encoding" ":" mechanism\r
-\r
- epilogue := discard-text ; to be ignored upon receipt.\r
-\r
- extension-token := x-token / iana-token\r
-\r
- external-param := (";" "access-type" "=" atype)\r
- / (";" "expiration" "=" date-time)\r
-\r
- ; Note that date-time is quoted\r
- / (";" "size" "=" 1*DIGIT)\r
- / (";" "permission" "=" ("read" / "read-write"))\r
- ; Permission is case-insensitive\r
- / (";" "name" "=" value)\r
- / (";" "site" "=" value)\r
- / (";" "dir" "=" value)\r
- / (";" "mode" "=" value)\r
- / (";" "server" "=" value)\r
- / (";" "subject" "=" value)\r
- ;access-type required; others required based on access-type\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 69]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- iana-token := <a publicly-defined extension token,\r
- registered with IANA, as specified in\r
- appendix E>\r
-\r
- id := "Content-ID" ":" msg-id\r
-\r
- image-type := "image" "/" ("gif" / "jpeg" / extension-token)\r
-\r
- mechanism := "7bit" ; case-insensitive\r
- / "quoted-printable"\r
- / "base64"\r
- / "8bit"\r
- / "binary"\r
- / x-token\r
-\r
- message-subtype := "rfc822"\r
- / "partial" 2#3partial-param\r
- / "external-body" 1*external-param\r
- / extension-token\r
-\r
- message-type := "message" "/" message-subtype\r
-\r
- multipart-body :=preamble 1*encapsulation close-delimiter epilogue\r
-\r
- multipart-subtype := "mixed" / "parallel" / "digest"\r
- / "alternative" / extension-token\r
-\r
- multipart-type := "multipart" "/" multipart-subtype\r
- ";" "boundary" "=" boundary\r
-\r
- octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")\r
- ; octet must be used for characters > 127, =, SPACE, or\r
- TAB,\r
- ; and is recommended for any characters not listed in\r
- ; Appendix B as "mail-safe".\r
-\r
- padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"\r
-\r
- parameter := attribute "=" value\r
-\r
- partial-param := (";" "id" "=" value)\r
- / (";" "number" "=" 1*DIGIT)\r
- / (";" "total" "=" 1*DIGIT)\r
- ; id & number required;total required for last part\r
-\r
- preamble := discard-text ; to be ignored upon receipt.\r
-\r
- ptext := octet / <any ASCII character except "=", SPACE, or TAB>\r
-\r
-\r
-\r
-Borenstein & Freed [Page 70]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- ; characters not listed as "mail-safe" in Appendix B\r
- ; are also not recommended.\r
-\r
- quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)\r
- ; Maximum line length of 76 characters excluding CRLF\r
-\r
- stream-param := (";" "type" "=" value)\r
- / (";" "padding" "=" padding)\r
-\r
- subtype := token ; case-insensitive\r
-\r
- text-subtype := "plain" / extension-token\r
-\r
- text-type := "text" "/" text-subtype [";" "charset" "=" charset]\r
-\r
- token := 1*<any (ASCII) CHAR except SPACE, CTLs, or tspecials>\r
-\r
- tspecials := "(" / ")" / "<" / ">" / "@"\r
- / "," / ";" / ":" / "\" / <">\r
- / "/" / "[" / "]" / "?" / "="\r
- ; Must be in quoted-string,\r
- ; to use within parameter values\r
-\r
-\r
- type := "application" / "audio" ; case-insensitive\r
- / "image" / "message"\r
- / "multipart" / "text"\r
- / "video" / extension-token\r
- ; All values case-insensitive\r
-\r
- value := token / quoted-string\r
-\r
- version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT\r
-\r
- video-type := "video" "/" ("mpeg" / extension-token)\r
-\r
- x-token := <The two characters "X-" or "x-" followed, with no\r
- intervening white space, by any token>\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 71]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix E -- IANA Registration Procedures\r
-\r
- MIME has been carefully designed to have extensible mechanisms, and\r
- it is expected that the set of content-type/subtype pairs and their\r
- associated parameters will grow significantly with time. Several\r
- other MIME fields, notably character set names, access-type\r
- parameters for the message/external-body type, and possibly even\r
- Content-Transfer-Encoding values, are likely to have new values\r
- defined over time. In order to ensure that the set of such values is\r
- developed in an orderly, well-specified, and public manner, MIME\r
- defines a registration process which uses the Internet Assigned\r
- Numbers Authority (IANA) as a central registry for such values.\r
-\r
- In general, parameters in the content-type header field are used to\r
- convey supplemental information for various content types, and their\r
- use is defined when the content-type and subtype are defined. New\r
- parameters should not be defined as a way to introduce new\r
- functionality.\r
-\r
- In order to simplify and standardize the registration process, this\r
- appendix gives templates for the registration of new values with\r
- IANA. Each of these is given in the form of an email message\r
- template, to be filled in by the registering party.\r
-\r
- E.1 Registration of New Content-type/subtype Values\r
-\r
- Note that MIME is generally expected to be extended by subtypes. If\r
- a new fundamental top-level type is needed, its specification must be\r
- published as an RFC or submitted in a form suitable to become an RFC,\r
- and be subject to the Internet standards process.\r
-\r
- To: IANA@isi.edu\r
- Subject: Registration of new MIME\r
- content-type/subtype\r
-\r
- MIME type name:\r
-\r
- (If the above is not an existing top-level MIME type,\r
- please explain why an existing type cannot be used.)\r
-\r
- MIME subtype name:\r
-\r
- Required parameters:\r
-\r
- Optional parameters:\r
-\r
- Encoding considerations:\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 72]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Security considerations:\r
-\r
- Published specification:\r
-\r
- (The published specification must be an Internet RFC or\r
- RFC-to-be if a new top-level type is being defined, and\r
- must be a publicly available specification in any\r
- case.)\r
-\r
- Person & email address to contact for further information:\r
-\r
- E.2 Registration of New Access-type Values\r
- for Message/external-body\r
-\r
- To: IANA@isi.edu\r
- Subject: Registration of new MIME Access-type for\r
- Message/external-body content-type\r
-\r
- MIME access-type name:\r
-\r
- Required parameters:\r
-\r
- Optional parameters:\r
-\r
- Published specification:\r
-\r
- (The published specification must be an Internet RFC or\r
- RFC-to-be.)\r
-\r
- Person & email address to contact for further information:\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 73]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix F -- Summary of the Seven Content-types\r
-\r
- Content-type: text\r
-\r
- Subtypes defined by this document: plain\r
-\r
- Important Parameters: charset\r
-\r
- Encoding notes: quoted-printable generally preferred if an encoding\r
- is needed and the character set is mostly an ASCII superset.\r
-\r
- Security considerations: Rich text formats such as TeX and Troff\r
- often contain mechanisms for executing arbitrary commands or file\r
- system operations, and should not be used automatically unless\r
- these security problems have been addressed. Even plain text may\r
- contain control characters that can be used to exploit the\r
- capabilities of "intelligent" terminals and cause security\r
- violations. User interfaces designed to run on such terminals\r
- should be aware of and try to prevent such problems.\r
-\r
- ________________________________________________________\r
- Content-type: multipart\r
-\r
- Subtypes defined by this document: mixed, alternative,\r
- digest, parallel.\r
-\r
- Important Parameters: boundary\r
-\r
- Encoding notes: No content-transfer-encoding is permitted.\r
-\r
- ________________________________________________________\r
- Content-type: message\r
-\r
- Subtypes defined by this document: rfc822, partial, external-body\r
-\r
- Important Parameters: id, number, total, access-type, expiration,\r
- size, permission, name, site, directory, mode, server, subject\r
-\r
- Encoding notes: No content-transfer-encoding is permitted.\r
- Specifically, only "7bit" is permitted for "message/partial" or\r
- "message/external-body", and only "7bit", "8bit", or "binary" are\r
- permitted for other subtypes of "message".\r
- ______________________________________________________________\r
- Content-type: application\r
-\r
- Subtypes defined by this document: octet-stream, postscript\r
-\r
- Important Parameters: type, padding\r
-\r
-\r
-\r
-Borenstein & Freed [Page 74]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Deprecated Parameters: name and conversions were\r
- defined in RFC 1341.\r
-\r
- Encoding notes: base64 preferred for unreadable subtypes.\r
-\r
- Security considerations: This type is intended for the\r
- transmission of data to be interpreted by locally-installed\r
- programs. If used, for example, to transmit executable\r
- binary programs or programs in general-purpose interpreted\r
- languages, such as LISP programs or shell scripts, severe\r
- security problems could result. Authors of mail-reading\r
- agents are cautioned against giving their systems the power\r
- to execute mail-based application data without carefully\r
- considering the security implications. While it is\r
- certainly possible to define safe application formats and\r
- even safe interpreters for unsafe formats, each interpreter\r
- should be evaluated separately for possible security\r
- problems.\r
- ________________________________________________________________\r
- Content-type: image\r
-\r
- Subtypes defined by this document: jpeg, gif\r
-\r
- Important Parameters: none\r
-\r
- Encoding notes: base64 generally preferred\r
- ________________________________________________________________\r
- Content-type: audio\r
-\r
- Subtypes defined by this document: basic\r
-\r
- Important Parameters: none\r
-\r
- Encoding notes: base64 generally preferred\r
- ________________________________________________________________\r
- Content-type: video\r
-\r
- Subtypes defined by this document: mpeg\r
-\r
- Important Parameters: none\r
-\r
- Encoding notes: base64 generally preferred\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 75]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix G -- Canonical Encoding Model\r
-\r
- There was some confusion, in earlier drafts of this memo, regarding\r
- the model for when email data was to be converted to canonical form\r
- and encoded, and in particular how this process would affect the\r
- treatment of CRLFs, given that the representation of newlines varies\r
- greatly from system to system. For this reason, a canonical model\r
- for encoding is presented below.\r
-\r
- The process of composing a MIME entity can be modeled as being done\r
- in a number of steps. Note that these steps are roughly similar to\r
- those steps used in RFC 1421 and are performed for each 'innermost\r
- level' body:\r
-\r
- Step 1. Creation of local form.\r
-\r
- The body to be transmitted is created in the system's native format.\r
- The native character set is used, and where appropriate local end of\r
- line conventions are used as well. The body may be a UNIX-style text\r
- file, or a Sun raster image, or a VMS indexed file, or audio data in\r
- a system-dependent format stored only in memory, or anything else\r
- that corresponds to the local model for the representation of some\r
- form of information. Fundamentally, the data is created in the\r
- "native" form specified by the type/subtype information.\r
-\r
- Step 2. Conversion to canonical form.\r
-\r
- The entire body, including "out-of-band" information such as record\r
- lengths and possibly file attribute information, is converted to a\r
- universal canonical form. The specific content type of the body as\r
- well as its associated attributes dictate the nature of the canonical\r
- form that is used. Conversion to the proper canonical form may\r
- involve character set conversion, transformation of audio data,\r
- compression, or various other operations specific to the various\r
- content types. If character set conversion is involved, however,\r
- care must be taken to understand the semantics of the content-type,\r
- which may have strong implications for any character set conversion,\r
- e.g. with regard to syntactically meaningful characters in a text\r
- subtype other than "plain".\r
-\r
- For example, in the case of text/plain data, the text must be\r
- converted to a supported character set and lines must be delimited\r
- with CRLF delimiters in accordance with RFC822. Note that the\r
- restriction on line lengths implied by RFC822 is eliminated if the\r
- next step employs either quoted-printable or base64 encoding.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 76]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- Step 3. Apply transfer encoding.\r
-\r
- A Content-Transfer-Encoding appropriate for this body is applied.\r
- Note that there is no fixed relationship between the content type and\r
- the transfer encoding. In particular, it may be appropriate to base\r
- the choice of base64 or quoted-printable on character frequency\r
- counts which are specific to a given instance of a body.\r
-\r
- Step 4. Insertion into entity.\r
-\r
- The encoded object is inserted into a MIME entity with appropriate\r
- headers. The entity is then inserted into the body of a higher-level\r
- entity (message or multipart) if needed.\r
-\r
- It is vital to note that these steps are only a model; they are\r
- specifically NOT a blueprint for how an actual system would be built.\r
- In particular, the model fails to account for two common designs:\r
-\r
- 1. In many cases the conversion to a canonical form prior to\r
- encoding will be subsumed into the encoder itself, which\r
- understands local formats directly. For example, the local\r
- newline convention for text bodies might be carried through to the\r
- encoder itself along with knowledge of what that format is.\r
-\r
- 2. The output of the encoders may have to pass through one or\r
- more additional steps prior to being transmitted as a message. As\r
- such, the output of the encoder may not be conformant with the\r
- formats specified by RFC822. In particular, once again it may be\r
- appropriate for the converter's output to be expressed using local\r
- newline conventions rather than using the standard RFC822 CRLF\r
- delimiters.\r
-\r
- Other implementation variations are conceivable as well. The vital\r
- aspect of this discussion is that, in spite of any optimizations,\r
- collapsings of required steps, or insertion of additional processing,\r
- the resulting messages must be consistent with those produced by the\r
- model described here. For example, a message with the following\r
- header fields:\r
-\r
- Content-type: text/foo; charset=bar\r
- Content-Transfer-Encoding: base64\r
-\r
- must be first represented in the text/foo form, then (if necessary)\r
- represented in the "bar" character set, and finally transformed via\r
- the base64 algorithm into a mail-safe form.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 77]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-Appendix H -- Changes from RFC 1341\r
-\r
- This document is a relatively minor revision of RFC 1341. For\r
- the convenience of those familiar with RFC 1341, the technical\r
- changes from that document are summarized in this appendix.\r
-\r
- 1. The definition of "tspecials" has been changed to no longer\r
- include ".".\r
-\r
- 2. The Content-ID field is now mandatory for message/external-body\r
- parts.\r
-\r
- 3. The text/richtext type (including the old Section 7.1.3 and\r
- Appendix D) has been moved to a separate document.\r
-\r
- 4. The rules on header merging for message/partial data have been\r
- changed to treat the Encrypted and MIME-Version headers as special\r
- cases.\r
-\r
- 5. The definition of the external-body access-type parameter has\r
- been changed so that it can only indicate a single access method\r
- (which was all that made sense).\r
-\r
- 6. There is a new "Subject" parameter for message/external-body,\r
- access-type mail-server, to permit MIME-based use of mail servers\r
- that rely on Subject field information.\r
-\r
- 7. The "conversions" parameter for application/octet-stream has been\r
- removed.\r
-\r
- 8. Section 7.4.1 now deprecates the use of the "name" parameter for\r
- application/octet-stream, as this will be superseded in the future by\r
- a Content-Disposition header.\r
-\r
- 9. The formal grammar for multipart bodies has been changed so that\r
- a CRLF is no longer required before the first boundary line.\r
-\r
- 10. MIME entities of type "message/partial" and "message/external-\r
- body" are now required to use only the "7bit" transfer-encoding.\r
- (Specifically, "binary" and "8bit" are not permitted.)\r
-\r
- 11. The "application/oda" content-type has been removed.\r
-\r
- 12. A note has been added to the end of section 7.2.3, explaining\r
- the semantics of Content-ID in a multipart/alternative MIME entity.\r
-\r
- 13. The formal syntax for the "MIME-Version" field has been\r
- tightened, but in a way that is completely compatible with the only\r
-\r
-\r
-\r
-Borenstein & Freed [Page 78]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- version number defined in RFC 1341.\r
-\r
- 14. In Section 7.3.1, the definition of message/rfc822 has been\r
- relaxed regarding mandatory fields.\r
-\r
- All other changes from RFC 1341 were editorial changes and do not\r
- affect the technical content of MIME. Considerable formal grammar\r
- has been added, but this reflects the prose specification that was\r
- already in place.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 79]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
-References\r
-\r
- [US-ASCII] Coded Character Set--7-Bit American Standard Code for\r
- Information Interchange, ANSI X3.4-1986.\r
-\r
- [ATK] Borenstein, Nathaniel S., Multimedia Applications Development\r
- with the Andrew Toolkit, Prentice-Hall, 1990.\r
-\r
- [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc.,\r
- Columbus, Ohio, 1990.\r
-\r
- [ISO-2022] International Standard--Information Processing--ISO 7-bit\r
- and 8-bit coded character sets--Code extension techniques, ISO\r
- 2022:1986.\r
-\r
- [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic\r
- Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part\r
- 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet\r
- No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4,\r
- 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6:\r
- Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek\r
- alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO\r
- 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.\r
-\r
- [ISO-646] International Standard--Information Processing--ISO 7-bit\r
- coded character set for information interchange, ISO 646:1983.\r
-\r
- [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11\r
- (Motion Picture Experts Group), May, 1991.\r
-\r
- [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972,\r
- "Pulse Code Modulation (PCM) of Voice Frequencies".\r
-\r
- [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference\r
- Manual, Addison-Wesley, 1985.\r
-\r
- [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference\r
- Manual, Addison-Wesley, Second Edition, 1990.\r
-\r
- [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message\r
- Handling Systems and Distributed Applications, E. Stefferud, O-j.\r
- Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.\r
-\r
- [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT,\r
- June 1981.\r
-\r
- [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC\r
- 821, USC/Information Sciences Institute, August 1982.\r
-\r
-\r
-\r
-Borenstein & Freed [Page 80]\r
-\f\r
-RFC 1521 MIME September 1993\r
-\r
-\r
- [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text\r
- Messages", STD 11, RFC 822, UDEL, August 1982.\r
-\r
- [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message\r
- Encapsulation", RFC 934, Delaware and NMA, January 1985.\r
-\r
- [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol",\r
- STD 9, RFC 959, USC/Information Sciences Institute, October 1985.\r
-\r
- [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet\r
- Messages", STD 11, RFC 1049, CMU, March 1988.\r
-\r
- [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail:\r
- Part I - Message Encryption and Authentication Procedures", RFC\r
- 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.\r
-\r
- [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for\r
- Internet Messages", RFC 1154, Prime Computer, Inc., April 1990.\r
-\r
- [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet\r
- Mail Extensions): Mechanisms for Specifying and Describing the Format\r
- of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.\r
-\r
- [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet\r
- Message Headers", RFC 1342, University of Tennessee, June 1992.\r
-\r
- [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism\r
- for Multimedia Mail Format Information", RFC 1343, Bellcore, June\r
- 1992.\r
-\r
- [RFC-1344] Borenstein, N., "Implications of MIME for Internet\r
- Mail Gateways", RFC 1344, Bellcore, June 1992.\r
-\r
- [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets",\r
- RFC 1345, Rationel Almen Planlaegning, June 1992.\r
-\r
- [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,\r
- Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME\r
- transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach\r
- Consulting, Inc., Network Management Associates, Inc., The Branch\r
- Office, February 1993.\r
-\r
- [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet\r
- Message Headers" RFC 1522, University of Tennessee, September 1993.\r
-\r
- [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC\r
- 1340, USC/Information Sciences Institute, July 1992.\r
-\r
-\r
-\r
-\r
-Borenstein & Freed [Page 81]\r
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-\r
-\r
-\r
-\r
-\r
-\r
-Network Working Group M. Crispin\r
-Request for Comments: 1730 University of Washington\r
-Category: Standards Track December 1994\r
-\r
-\r
- INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4\r
-\r
-\r
-\r
-Status of this Memo\r
-\r
- This document specifies an Internet standards track protocol for the\r
- Internet community, and requests discussion and suggestions for\r
- improvements. Please refer to the current edition of the "Internet\r
- Official Protocol Standards" (STD 1) for the standardization state\r
- and status of this protocol. Distribution of this memo is unlimited.\r
-\r
-\r
-Abstract\r
-\r
- The Internet Message Access Protocol, Version 4 (IMAP4) allows a\r
- client to access and manipulate electronic mail messages on a server.\r
- IMAP4 permits manipulation of remote message folders, called\r
- "mailboxes", in a way that is functionally equivalent to local\r
- mailboxes. IMAP4 also provides the capability for an offline client\r
- to resynchronize with the server (see also [IMAP-DISC]).\r
-\r
- IMAP4 includes operations for creating, deleting, and renaming\r
- mailboxes; checking for new messages; permanently removing messages;\r
- setting and clearing flags; RFC 822 and MIME parsing; searching; and\r
- selective fetching of message attributes, texts, and portions\r
- thereof. Messages in IMAP4 are accessed by the use of numbers.\r
- These numbers are either message sequence numbers (relative position\r
- from 1 to the number of messages in the mailbox) or unique\r
- identifiers (immutable, strictly ascending values assigned to each\r
- message, but which are not necessarily contiguous).\r
-\r
- IMAP4 supports a single server. A mechanism for supporting multiple\r
- IMAP4 servers is discussed in [IMSP].\r
-\r
- IMAP4 does not specify a means of posting mail; this function is\r
- handled by a mail transfer protocol such as [SMTP].\r
-\r
- IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.\r
- Compatibility issues are discussed in [IMAP-COMPAT].\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page i]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-\r
-\r
-\r
-Table of Contents\r
-\r
-\r
-\r
-IMAP4 Protocol Specification ...................................... 1\r
-1. Organization of this Document ............................. 1\r
-1.1. How to Read This Document ................................. 1\r
-1.2. Conventions Used in this Document ......................... 1\r
-2. Protocol Overview ......................................... 1\r
-2.1. Link Level ................................................ 1\r
-2.2. Commands and Responses .................................... 1\r
-2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2\r
-2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2\r
-3. State and Flow Diagram .................................... 4\r
-3.1. Non-Authenticated State ................................... 4\r
-3.2. Authenticated State ....................................... 4\r
-3.3. Selected State ............................................ 4\r
-3.4. Logout State .............................................. 4\r
-4. Data Formats .............................................. 6\r
-4.1. Atom ...................................................... 6\r
-4.2. Number .................................................... 6\r
-4.3. String .................................................... 6\r
-4.3.1. 8-bit and Binary Strings .................................. 7\r
-4.4. Parenthesized List ........................................ 7\r
-4.5. NIL ....................................................... 7\r
-5. Operational Considerations ................................ 8\r
-5.1. Mailbox Naming ............................................ 8\r
-5.2. Mailbox Size and Message Status Updates ................... 8\r
-5.3. Response when no Command in Progress ...................... 8\r
-5.4. Autologout Timer .......................................... 9\r
-5.5. Multiple Commands in Progress ............................. 9\r
-6. Client Commands ........................................... 10\r
-6.1. Client Commands - Any State ............................... 10\r
-6.1.1. CAPABILITY Command ........................................ 10\r
-6.1.2. NOOP Command .............................................. 11\r
-6.1.3. LOGOUT Command ............................................ 11\r
-6.2. Client Commands - Non-Authenticated State ................. 12\r
-6.2.1. AUTHENTICATE Command ...................................... 12\r
-6.2.2. LOGIN Command ............................................. 14\r
-6.3. Client Commands - Authenticated State ..................... 14\r
-6.3.1. SELECT Command ............................................ 15\r
-6.3.2. EXAMINE Command ........................................... 16\r
-6.3.3. CREATE Command ............................................ 17\r
-6.3.4. DELETE Command ............................................ 18\r
-6.3.5. RENAME Command ............................................ 18\r
-\r
-\r
-\r
-Crispin [Page ii]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6.3.6. SUBSCRIBE Command ......................................... 19\r
-6.3.7. UNSUBSCRIBE Command ....................................... 19\r
-6.3.8. LIST Command .............................................. 20\r
-6.3.9. LSUB Command .............................................. 22\r
-6.3.10. APPEND Command ............................................ 22\r
-6.4. Client Commands - Selected State .......................... 23\r
-6.4.1. CHECK Command ............................................. 23\r
-6.4.2. CLOSE Command ............................................. 24\r
-6.4.3. EXPUNGE Command ........................................... 25\r
-6.4.4. SEARCH Command ............................................ 25\r
-6.4.5. FETCH Command ............................................. 29\r
-6.4.6. PARTIAL Command ........................................... 32\r
-6.4.7. STORE Command ............................................. 33\r
-6.4.8. COPY Command .............................................. 34\r
-6.4.9. UID Command ............................................... 35\r
-6.5. Client Commands - Experimental/Expansion .................. 37\r
-6.5.1. X<atom> Command ........................................... 37\r
-7. Server Responses .......................................... 38\r
-7.1. Server Responses - Status Responses ....................... 39\r
-7.1.1. OK Response ............................................... 40\r
-7.1.2. NO Response ............................................... 40\r
-7.1.3. BAD Response .............................................. 41\r
-7.1.4. PREAUTH Response .......................................... 41\r
-7.1.5. BYE Response .............................................. 41\r
-7.2. Server Responses - Server and Mailbox Status .............. 42\r
-7.2.1. CAPABILITY Response ....................................... 42\r
-7.2.2. LIST Response ............................................. 43\r
-7.2.3. LSUB Response ............................................. 44\r
-7.2.4. SEARCH Response ........................................... 44\r
-7.2.5. FLAGS Response ............................................ 44\r
-7.3. Server Responses - Message Status ......................... 45\r
-7.3.1. EXISTS Response ........................................... 45\r
-7.3.2. RECENT Response ........................................... 45\r
-7.3.3. EXPUNGE Response .......................................... 45\r
-7.3.4. FETCH Response ............................................ 46\r
-7.3.5. Obsolete Responses ........................................ 51\r
-7.4. Server Responses - Command Continuation Request ........... 51\r
-8. Sample IMAP4 session ...................................... 52\r
-9. Formal Syntax ............................................. 53\r
-10. Author's Note ............................................. 64\r
-11. Security Considerations ................................... 64\r
-12. Author's Address .......................................... 64\r
-Appendices ........................................................ 65\r
-A. Obsolete Commands ......................................... 65\r
-A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65\r
-A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65\r
-A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66\r
-A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66\r
-\r
-\r
-\r
-Crispin [Page iii]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-B. Obsolete Responses ........................................ 68\r
-B.7.2.OBS.1. MAILBOX Response .................................. 68\r
-B.7.3.OBS.1. COPY Response ..................................... 68\r
-B.7.3.OBS.2. STORE Response .................................... 69\r
-C. References ................................................ 70\r
-E. IMAP4 Keyword Index ....................................... 71\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page iv]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-IMAP4 Protocol Specification\r
-\r
-1. Organization of this Document\r
-\r
-1.1. How to Read This Document\r
-\r
- This document is written from the point of view of the implementor of\r
- an IMAP4 client or server. Beyond the protocol overview in section\r
- 2, it is not optimized for someone trying to understand the operation\r
- of the protocol. The material in sections 3 through 5 provides the\r
- general context and definitions with which IMAP4 operates.\r
-\r
- Sections 6, 7, and 9 describe the IMAP commands, responses, and\r
- syntax, respectively. The relationships among these are such that it\r
- is almost impossible to understand any of them separately. In\r
- particular, one should not attempt to deduce command syntax from the\r
- command section alone; one should instead refer to the formal syntax\r
- section.\r
-\r
-\r
-1.2. Conventions Used in this Document\r
-\r
- In examples, "C:" and "S:" indicate lines sent by the client and\r
- server respectively.\r
-\r
-\r
-2. Protocol Overview\r
-\r
-2.1. Link Level\r
-\r
- The IMAP4 protocol assumes a reliable data stream such as provided by\r
- TCP. When TCP is used, an IMAP4 server listens on port 143.\r
-\r
-\r
-2.2. Commands and Responses\r
-\r
- An IMAP4 session consists of the establishment of a client/server\r
- connection, an initial greeting from the server, and client/server\r
- interactions. These client/server interactions consist of a client\r
- command, server data, and a server completion result response.\r
-\r
- All interactions transmitted by client and server are in the form of\r
- lines; that is, strings that end with a CRLF. The protocol receiver\r
- of an IMAP4 client or server is either reading a line, or is reading\r
- a sequence of octets with a known count followed by a line.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 1]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-2.2.1. Client Protocol Sender and Server Protocol Receiver\r
-\r
- The client command begins an operation. Each client command is\r
- prefixed with a identifier (typically a short alphanumeric string,\r
- e.g. A0001, A0002, etc.) called a "tag". A different tag is\r
- generated by the client for each command.\r
-\r
- There are two cases in which a line from the client does not\r
- represent a complete command. In one case, a command argument is\r
- quoted with an octet count (see the description of literal in String\r
- under Data Formats); in the other case, the command arguments require\r
- server feedback (see the AUTHENTICATE command). In either case, the\r
- server sends a command continuation request response if it is ready\r
- for the octets (if appropriate) and the remainder of the command.\r
- This response is prefixed with the token "+".\r
-\r
- Note: If, instead, the server detected an error in the\r
- command, it sends a BAD completion response with tag\r
- matching the command (as described below) to reject the\r
- command and prevent the client from sending any more of the\r
- command.\r
-\r
- It is also possible for the server to send a completion\r
- response for some other command (if multiple commands are\r
- in progress), or untagged data. In either case, the\r
- command continuation request is still pending; the client\r
- takes the appropriate action for the response, and reads\r
- another response from the server.\r
-\r
- The protocol receiver of an IMAP4 server reads a command line from\r
- the client, parses the command and its arguments, and transmits\r
- server data and a server command completion result response.\r
-\r
-\r
-2.2.2. Server Protocol Sender and Client Protocol Receiver\r
-\r
- Data transmitted by the server to the client and status responses\r
- that do not indicate command completion are prefixed with the token\r
- "*", and are called untagged responses.\r
-\r
- Server data may be sent as a result of a client command, or may be\r
- sent unilaterally by the server. There is no syntactic difference\r
- between server data that resulted from a specific command and server\r
- data that were sent unilaterally.\r
-\r
- The server completion result response indicates the success or\r
- failure of the operation. It is tagged with the same tag as the\r
- client command which began the operation. Thus, if more than one\r
-\r
-\r
-\r
-Crispin [Page 2]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- command is in progress, the tag in a server completion response\r
- identifies the command to which the response applies. There are\r
- three possible server completion responses: OK (indicating success),\r
- NO (indicating failure), or BAD (indicating protocol error such as\r
- unrecognized command or command syntax error).\r
-\r
- The protocol receiver of an IMAP4 client reads a response line from\r
- the server. It then takes action on the response based upon the\r
- first token of the response, which may be a tag, a "*", or a "+". As\r
- described above.\r
-\r
- A client MUST be prepared to accept any server response at all times.\r
- This includes server data that it may not have requested. Server\r
- data SHOULD be recorded, so that the client can reference its\r
- recorded copy rather than sending a command to the server to request\r
- the data. In the case of certain server data, recording the data is\r
- mandatory.\r
-\r
- This topic is discussed in greater detail in the Server Responses\r
- section.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 3]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-3. State and Flow Diagram\r
-\r
- An IMAP4 server is in one of four states. Most commands are valid in\r
- only certain states. It is a protocol error for the client to\r
- attempt a command while the command is in an inappropriate state. In\r
- this case, a server will respond with a BAD or NO (depending upon\r
- server implementation) command completion result.\r
-\r
-\r
-3.1. Non-Authenticated State\r
-\r
- In non-authenticated state, the user must supply authentication\r
- credentials before most commands will be permitted. This state is\r
- entered when a connection starts unless the connection has been\r
- pre-authenticated.\r
-\r
-\r
-3.2. Authenticated State\r
-\r
- In authenticated state, the user is authenticated and must select a\r
- mailbox to access before commands that affect messages will be\r
- permitted. This state is entered when a pre-authenticated connection\r
- starts, when acceptable authentication credentials have been\r
- provided, or after an error in selecting a mailbox.\r
-\r
-\r
-3.3. Selected State\r
-\r
- In selected state, a mailbox has been selected to access. This state\r
- is entered when a mailbox has been successfully selected.\r
-\r
-\r
-3.4. Logout State\r
-\r
- In logout state, the session is being terminated, and the server will\r
- close the connection. This state can be entered as a result of a\r
- client request or by unilateral server decision.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 4]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- +--------------------------------------+\r
- |initial connection and server greeting|\r
- +--------------------------------------+\r
- || (1) || (2) || (3)\r
- VV || ||\r
- +-----------------+ || ||\r
- |non-authenticated| || ||\r
- +-----------------+ || ||\r
- || (7) || (4) || ||\r
- || VV VV ||\r
- || +----------------+ ||\r
- || | authenticated |<=++ ||\r
- || +----------------+ || ||\r
- || || (7) || (5) || (6) ||\r
- || || VV || ||\r
- || || +--------+ || ||\r
- || || |selected|==++ ||\r
- || || +--------+ ||\r
- || || || (7) ||\r
- VV VV VV VV\r
- +--------------------------------------+\r
- | logout and close connection |\r
- +--------------------------------------+\r
-\r
- (1) connection without pre-authentication (OK greeting)\r
- (2) pre-authenticated connection (PREAUTH greeting)\r
- (3) rejected connection (BYE greeting)\r
- (4) successful LOGIN or AUTHENTICATE command\r
- (5) successful SELECT or EXAMINE command\r
- (6) CLOSE command, or failed SELECT or EXAMINE command\r
- (7) LOGOUT command, server shutdown, or connection closed\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 5]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-4. Data Formats\r
-\r
- IMAP4 uses textual commands and responses. Data in IMAP4 can be in\r
- one of several forms: atom, number, string, parenthesized list, or\r
- NIL.\r
-\r
-\r
-4.1. Atom\r
-\r
- An atom consists of one or more non-special characters.\r
-\r
-\r
-4.2. Number\r
-\r
- A number consists of one or more digit characters, and represents a\r
- numeric value.\r
-\r
-\r
-4.3. String\r
-\r
- A string is in one of two forms: literal and quoted string. The\r
- literal form is the general form of string. The quoted string form\r
- is an alternative that avoids the overhead of processing a literal at\r
- the cost of restrictions of what may be in a quoted string.\r
-\r
- A literal is a sequence of zero or more octets (including CR and LF),\r
- prefix-quoted with an octet count in the form of an open brace ("{"),\r
- the number of octets, close brace ("}"), and CRLF. In the case of\r
- literals transmitted from server to client, the CRLF is immediately\r
- followed by the octet data. In the case of literals transmitted from\r
- client to server, the client must wait to receive a command\r
- continuation request (described later in this document) before\r
- sending the octet data (and the remainder of the command).\r
-\r
- A quoted string is a sequence of zero or more 7-bit characters,\r
- excluding CR and LF, with double quote (<">) characters at each end.\r
-\r
- The empty string is respresented as either "" (a quoted string with\r
- zero characters between double quotes) or as {0} followed by CRLF (a\r
- literal with an octet count of 0).\r
-\r
- Note: Even if the octet count is 0, a client transmitting a\r
- literal must wait to receive a command continuation\r
- request.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 6]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-4.3.1. 8-bit and Binary Strings\r
-\r
- 8-bit textual and binary mail is supported through the use of\r
- [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or\r
- multi-octet characters in literals, but should do so only when the\r
- character set is identified.\r
-\r
- Although a BINARY body encoding is defined, unencoded binary strings\r
- are not permitted. A "binary string" is any string with NUL\r
- characters. Implementations MUST encode binary data into a textual\r
- form such as BASE64 before transmitting the data. A string with an\r
- excessive amount of CTL characters may also be considered to be\r
- binary, although this is not required.\r
-\r
-\r
-4.4. Parenthesized List\r
-\r
- Data structures are represented as a "parenthesized list"; a sequence\r
- of data items, delimited by space, and bounded at each end by\r
- parentheses. A parenthesized list may itself contain other\r
- parenthesized lists, using multiple levels of parentheses to indicate\r
- nesting.\r
-\r
- The empty list is represented as () -- a parenthesized list with no\r
- members.\r
-\r
-\r
-4.5. NIL\r
-\r
- The special atom "NIL" represents the non-existence of a particular\r
- data item that is represented as a string or parenthesized list, as\r
- distinct from the empty string "" or the empty parenthesized list ().\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 7]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-5. Operational Considerations\r
-\r
-5.1. Mailbox Naming\r
-\r
- The interpretation of mailbox names is implementation-dependent.\r
- However, the mailbox name INBOX is a special name reserved to mean\r
- "the primary mailbox for this user on this server". If it is desired\r
- to export hierarchical mailbox names, mailbox names must be\r
- left-to-right hierarchical using a single character to separate\r
- levels of hierarchy. The same hierarchy separator character is used\r
- for all levels of hierarchy within a single name.\r
-\r
-5.2. Mailbox Size and Message Status Updates\r
-\r
- At any time, a server can send data that the client did not request.\r
- Sometimes, such behavior is required. For example, agents other than\r
- the server may add messages to the mailbox (e.g. new mail delivery),\r
- change the flags of message in the mailbox (e.g. simultaneous access\r
- to the same mailbox by multiple agents), or even remove messages from\r
- the mailbox. A server MUST send mailbox size updates automatically\r
- if a mailbox size change is observed during the processing of a\r
- command. A server SHOULD send message flag updates automatically,\r
- without requiring the client to request such updates explicitly.\r
- Special rules exist for server notification of a client about the\r
- removal of messages to prevent synchronization errors; see the\r
- description of the EXPUNGE response for more details.\r
-\r
- Regardless of what implementation decisions a client may take on\r
- remembering data from the server, a client implementation MUST record\r
- mailbox size updates. It MUST NOT assume that any command after\r
- initial mailbox selection will return the size of the mailbox.\r
-\r
-\r
-5.3. Response when no Command in Progress\r
-\r
- Server implementations are permitted to send an untagged response\r
- (except for EXPUNGE) while there is no command in progress. Server\r
- implementations that send such responses MUST deal with flow control\r
- considerations. Specifically, they must either (1) verify that the\r
- size of the data does not exceed the underlying transport's available\r
- window size, or (2) use non-blocking writes.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 8]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-5.4. Autologout Timer\r
-\r
- If a server has an inactivity autologout timer, that timer MUST be of\r
- at least 30 minutes' duration. The receipt of ANY command from the\r
- client during that interval should suffice to reset the autologout\r
- timer.\r
-\r
-\r
-5.5. Multiple Commands in Progress\r
-\r
- The client is not required to wait for the completion result response\r
- of a command before sending another command, subject to flow control\r
- constraints on the underlying data stream. Similarly, a server is\r
- not required to process a command to completion before beginning\r
- processing of the next command, unless an ambiguity would result\r
- because of a command that would affect the results of other commands.\r
- If there is such an ambiguity, the server executes commands to\r
- completion in the order given by the client.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 9]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6. Client Commands\r
-\r
- IMAP4 commands are described in this section. Commands are organized\r
- by the state in which the command is permitted. Commands which are\r
- permitted in multiple states are listed in the minimum permitted\r
- state (for example, commands valid in authenticated and selected\r
- state are listed in the authenticated state commands).\r
-\r
- Command arguments, identified by "Arguments:" in the command\r
- descriptions below, are described by function, not by syntax. The\r
- precise syntax of command arguments is described in the Formal Syntax\r
- section.\r
-\r
- Some commands cause specific server data to be returned; these are\r
- identified by "Data:" in the command descriptions below. See the\r
- response descriptions in the Responses section for information on\r
- these responses, and the Formal Syntax section for the precise syntax\r
- of these responses. It is possible for server data to be transmitted\r
- as a result of any command; thus, commands that do not specifically\r
- require server data specify "no specific data for this command"\r
- instead of "none".\r
-\r
- The "Result:" in the command description refers to the possible\r
- tagged status responses to a command, and any special interpretation\r
- of these status responses.\r
-\r
-\r
-6.1. Client Commands - Any State\r
-\r
- The following commands are valid in any state: CAPABILITY, NOOP, and\r
- LOGOUT.\r
-\r
-6.1.1. CAPABILITY Command\r
-\r
- Arguments: none\r
-\r
- Data: mandatory untagged response: CAPABILITY\r
-\r
- Result: OK - capability completed\r
- BAD - command unknown or arguments invalid\r
-\r
- The CAPABILITY command requests a listing of capabilities that the\r
- server supports. The server MUST send a single untagged\r
- CAPABILITY response with "IMAP4" as the first listed capability\r
- before the (tagged) OK response. This listing of capabilities is\r
- not dependent upon connection state or user. It is therefore not\r
- necessary to issue a CAPABILITY command more than once in a\r
- session.\r
-\r
-\r
-\r
-Crispin [Page 10]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Capability names other than "IMAP4" refer to extensions,\r
- revisions, or amendments to this specification. See the\r
- documentation of the CAPABILITY response for additional\r
- information. No capabilities are enabled without explicit client\r
- action to invoke the capability. See the section entitled "Client\r
- Commands - Experimental/Expansion" for information about the form\r
- of site or implementation-specific capabilities.\r
-\r
- Example: C: abcd CAPABILITY\r
- S: * CAPABILITY IMAP4\r
- S: abcd OK CAPABILITY completed\r
-\r
-\r
-6.1.2. NOOP Command\r
-\r
- Arguments: none\r
-\r
- Data: no specific data for this command (but see below)\r
-\r
- Result: OK - noop completed\r
- BAD - command unknown or arguments invalid\r
-\r
- The NOOP command always succeeds. It does nothing.\r
-\r
- Since any command can return a status update as untagged data, the\r
- NOOP command can be used as a periodic poll for new messages or\r
- message status updates during a period of inactivity. The NOOP\r
- command can also be used to reset any inactivity autologout timer\r
- on the server.\r
-\r
- Example: C: a002 NOOP\r
- S: a002 OK NOOP completed\r
- . . .\r
- C: a047 NOOP\r
- S: * 22 EXPUNGE\r
- S: * 23 EXISTS\r
- S: * 3 RECENT\r
- S: * 14 FETCH (FLAGS (\Seen \Deleted))\r
- S: a047 OK NOOP completed\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 11]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6.1.3. LOGOUT Command\r
-\r
- Arguments: none\r
-\r
- Data: mandatory untagged response: BYE\r
-\r
- Result: OK - logout completed\r
- BAD - command unknown or arguments invalid\r
-\r
- The LOGOUT command informs the server that the client is done with\r
- the session. The server must send a BYE untagged response before\r
- the (tagged) OK response, and then close the network connection.\r
-\r
- Example: C: A023 LOGOUT\r
- S: * BYE IMAP4 Server logging out\r
- S: A023 OK LOGOUT completed\r
- (Server and client then close the connection)\r
-\r
-\r
-\r
-6.2. Client Commands - Non-Authenticated State\r
-\r
- In non-authenticated state, the AUTHENTICATE or LOGIN command\r
- establishes authentication and enter authenticated state. The\r
- AUTHENTICATE command provides a general mechanism for a variety of\r
- authentication techniques, whereas the LOGIN command uses the\r
- traditional user name and plaintext password pair.\r
-\r
- Server implementations may allow non-authenticated access to certain\r
- mailboxes. The convention is to use a LOGIN command with the userid\r
- "anonymous". A password is required. It is implementation-dependent\r
- what requirements, if any, are placed on the password and what access\r
- restrictions are placed on anonymous users.\r
-\r
- Once authenticated (including as anonymous), it is not possible to\r
- re-enter non-authenticated state.\r
-\r
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),\r
- the following commands are valid in non-authenticated state:\r
- AUTHENTICATE and LOGIN.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 12]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6.2.1. AUTHENTICATE Command\r
-\r
- Arguments: authentication mechanism name\r
-\r
- Data: continuation data may be requested\r
-\r
- Result: OK - authenticate completed, now in authenticated state\r
- NO - authenticate failure: unsupported authentication\r
- mechanism, credentials rejected\r
- BAD - command unknown or arguments invalid,\r
- authentication exchange cancelled\r
-\r
- The AUTHENTICATE command indicates an authentication mechanism,\r
- such as described in [IMAP-AUTH], to the server. If the server\r
- supports the requested authentication mechanism, it performs an\r
- authentication protocol exchange to authenticate and identify the\r
- user. Optionally, it also negotiates a protection mechanism for\r
- subsequent protocol interactions. If the requested authentication\r
- mechanism is not supported, the server should reject the\r
- AUTHENTICATE command by sending a tagged NO response.\r
-\r
- The authentication protocol exchange consists of a series of\r
- server challenges and client answers that are specific to the\r
- authentication mechanism. A server challenge consists of a\r
- command continuation request response with the "+" token followed\r
- by a BASE64 encoded string. The client answer consists of a line\r
- consisting of a BASE64 encoded string. If the client wishes to\r
- cancel an authentication exchange, it should issue a line with a\r
- single "*". If the server receives such an answer, it must reject\r
- the AUTHENTICATE command by sending a tagged BAD response.\r
-\r
- A protection mechanism provides integrity and privacy protection\r
- to the protocol session. If a protection mechanism is negotiated,\r
- it is applied to all subsequent data sent over the connection.\r
- The protection mechanism takes effect immediately following the\r
- CRLF that concludes the authentication exchange for the client,\r
- and the CRLF of the tagged OK response for the server. Once the\r
- protection mechanism is in effect, the stream of command and\r
- response octets is processed into buffers of ciphertext. Each\r
- buffer is transferred over the connection as a stream of octets\r
- prepended with a four octet field in network byte order that\r
- represents the length of the following data. The maximum\r
- ciphertext buffer length is defined by the protection mechanism.\r
-\r
- The server is not required to support any particular\r
- authentication mechanism, nor are authentication mechanisms\r
- required to support any protection mechanisms. If an AUTHENTICATE\r
- command fails with a NO response, the client may try another\r
-\r
-\r
-\r
-Crispin [Page 13]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- authentication mechanism by issuing another AUTHENTICATE command,\r
- or may attempt to authenticate by using the LOGIN command. In\r
- other words, the client may request authentication types in\r
- decreasing order of preference, with the LOGIN command as a last\r
- resort.\r
-\r
- Example: S: * OK KerberosV4 IMAP4 Server\r
- C: A001 AUTHENTICATE KERBEROS_V4\r
- S: + AmFYig==\r
- C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT\r
- +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd\r
- WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh\r
- S: + or//EoAADZI=\r
- C: DiAF5A4gA+oOIALuBkAAmw==\r
- S: A001 OK Kerberos V4 authentication successful\r
-\r
- Note: the line breaks in the first client answer are for\r
- editorial clarity and are not in real authenticators.\r
-\r
-\r
-6.2.2. LOGIN Command\r
-\r
- Arguments: user name\r
- password\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - login completed, now in authenticated state\r
- NO - login failure: user name or password rejected\r
- BAD - command unknown or arguments invalid\r
-\r
- The LOGIN command identifies the user to the server and carries\r
- the plaintext password authenticating this user.\r
-\r
- Example: C: a001 LOGIN SMITH SESAME\r
- S: a001 OK LOGIN completed\r
-\r
-\r
-\r
-6.3. Client Commands - Authenticated State\r
-\r
- In authenticated state, commands that manipulate mailboxes as atomic\r
- entities are permitted. Of these commands, the SELECT and EXAMINE\r
- commands will select a mailbox for access and enter selected state.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 14]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),\r
- the following commands are valid in authenticated state: SELECT,\r
- EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,\r
- and APPEND.\r
-\r
-6.3.1. SELECT Command\r
-\r
- Arguments: mailbox name\r
-\r
- Data: mandatory untagged responses: FLAGS, EXISTS, RECENT\r
- optional OK untagged responses: UNSEEN, PERMANENTFLAGS\r
-\r
- Result: OK - select completed, now in selected state\r
- NO - select failure, now in authenticated state: no\r
- such mailbox, can't access mailbox\r
- BAD - command unknown or arguments invalid\r
-\r
- The SELECT command selects a mailbox so that messages in the\r
- mailbox can be accessed. Before returning an OK to the client,\r
- the server MUST send the following untagged data to the client:\r
-\r
- FLAGS Defined flags in the mailbox\r
-\r
- <n> EXISTS The number of messages in the mailbox\r
-\r
- <n> RECENT The number of messages added to the mailbox since\r
- the previous time this mailbox was read\r
-\r
- OK [UIDVALIDITY <n>]\r
- The unique identifier validity value. See the\r
- description of the UID command for more detail.\r
-\r
- to define the initial state of the mailbox at the client. If it\r
- is not possible to determine the messages that were added since\r
- the previous time a mailbox was read, then all messages SHOULD be\r
- considered recent.\r
-\r
- The server SHOULD also send an UNSEEN response code in an OK\r
- untagged response, indicating the message sequence number of the\r
- first unseen message in the mailbox.\r
-\r
- If the client can not change the permanent state of one or more of\r
- the flags listed in the FLAGS untagged response, the server SHOULD\r
- send a PERMANENTFLAGS response code in an OK untagged response,\r
- listing the flags that the client may change permanently.\r
-\r
- Only one mailbox may be selected at a time in a session;\r
- simultaneous access to multiple mailboxes requires multiple\r
-\r
-\r
-\r
-Crispin [Page 15]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- sessions. The SELECT command automatically deselects any\r
- currently selected mailbox before attempting the new selection.\r
- Consequently, if a mailbox is selected and a SELECT command that\r
- fails is attempted, no mailbox is selected.\r
-\r
- If the user is permitted to modify the mailbox, the server SHOULD\r
- prefix the text of the tagged OK response with the "[READ-WRITE]"\r
- response code.\r
-\r
- If the user is not permitted to modify the mailbox but is\r
- permitted read access, the mailbox is selected as read-only, and\r
- the server MUST prefix the text of the tagged OK response to\r
- SELECT with the "[READ-ONLY]" response code. Read-only access\r
- through SELECT differs from the EXAMINE command in that certain\r
- read-only mailboxes may permit the change of permanent state on a\r
- per-user (as opposed to global) basis. Netnews messages marked in\r
- a user's .newsrc file are an example of such per-user permanent\r
- state that can be modified with read-only mailboxes.\r
-\r
- Example: C: A142 SELECT INBOX\r
- S: * 172 EXISTS\r
- S: * 1 RECENT\r
- S: * OK [UNSEEN 12] Message 12 is first unseen\r
- S: * OK [UIDVALIDITY 3857529045] UIDs valid\r
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)\r
- S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited\r
- S: A142 OK [READ-WRITE] SELECT completed\r
-\r
-\r
-6.3.2. EXAMINE Command\r
-\r
- Arguments: mailbox name\r
-\r
- Data: mandatory untagged responses: FLAGS, EXISTS, RECENT\r
- optional OK untagged responses: UNSEEN, PERMANENTFLAGS\r
-\r
- Result: OK - examine completed, now in selected state\r
- NO - examine failure, now in authenticated state: no\r
- such mailbox, can't access mailbox\r
- BAD - command unknown or arguments invalid\r
-\r
- The EXAMINE command is identical to SELECT and returns the same\r
- output; however, the selected mailbox is identified as read-only.\r
- No changes to the permanent state of the mailbox, including\r
- per-user state, are permitted.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 16]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- The text of the tagged OK response to the EXAMINE command MUST\r
- begin with the "[READ-ONLY]" response code.\r
-\r
- Example: C: A932 EXAMINE blurdybloop\r
- S: * 17 EXISTS\r
- S: * 2 RECENT\r
- S: * OK [UNSEEN 8] Message 8 is first unseen\r
- S: * OK [UIDVALIDITY 3857529045] UIDs valid\r
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)\r
- S: * OK [PERMANENTFLAGS ()] No permanent flags permitted\r
- S: A932 OK [READ-ONLY] EXAMINE completed\r
-\r
-\r
-6.3.3. CREATE Command\r
-\r
- Arguments: mailbox name\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - create completed\r
- NO - create failure: can't create mailbox with that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The CREATE command creates a mailbox with the given name. An OK\r
- response is returned only if a new mailbox with that name has been\r
- created. It is an error to attempt to create INBOX or a mailbox\r
- with a name that refers to an extant mailbox. Any error in\r
- creation will return a tagged NO response.\r
-\r
- If the mailbox name is suffixed with the server's hierarchy\r
- separator character (as returned from the server by a LIST\r
- command), this is a declaration that the client may, in the\r
- future, create mailbox names under this name in the hierarchy.\r
- Server implementations that do not require this declaration MUST\r
- ignore it.\r
-\r
- If a new mailbox is created with the same name as a mailbox which\r
- was deleted, its unique identifiers MUST be greater than any\r
- unique identifiers used in the previous incarnation of the mailbox\r
- UNLESS the new incarnation has a different unique identifier\r
- validity value. See the description of the UID command for more\r
- detail.\r
-\r
- Example: C: A003 CREATE owatagusiam/\r
- S: A003 OK CREATE completed\r
- C: A004 CREATE owatagusiam/blurdybloop\r
- S: A004 OK CREATE completed\r
-\r
-\r
-\r
-\r
-Crispin [Page 17]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Note: the interpretation of this example depends on whether\r
- "/" was returned as the hierarchy separator from LIST. If\r
- "/" is the hierarchy separator, a new level of hierarchy\r
- named "owatagusiam" with a member called "blurdybloop" is\r
- created. Otherwise, two mailboxes at the same hierarchy\r
- level are created.\r
-\r
-\r
-6.3.4. DELETE Command\r
-\r
- Arguments: mailbox name\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - delete completed\r
- NO - delete failure: can't delete mailbox with that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The DELETE command permanently removes the mailbox with the given\r
- name. A tagged OK response is returned only if the mailbox has\r
- been deleted. It is an error to attempt to delete INBOX or a\r
- mailbox name that does not exist. Any error in deletion will\r
- return a tagged NO response.\r
-\r
- The value of the highest-used unique indentifier of the deleted\r
- mailbox MUST be preserved so that a new mailbox created with the\r
- same name will not reuse the identifiers of the former\r
- incarnation, UNLESS the new incarnation has a different unique\r
- identifier validity value. See the description of the UID command\r
- for more detail.\r
-\r
- Example: C: A683 DELETE blurdybloop\r
- S: A683 OK DELETE completed\r
-\r
-\r
-6.3.5. RENAME Command\r
-\r
- Arguments: existing mailbox name\r
- new mailbox name\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - rename completed\r
- NO - rename failure: can't rename mailbox with that name,\r
- can't rename to mailbox with that name\r
- BAD - command unknown or arguments invalid\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 18]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- The RENAME command changes the name of a mailbox. A tagged OK\r
- response is returned only if the mailbox has been renamed. It is\r
- an error to attempt to rename from a mailbox name that does not\r
- exist or to a mailbox name that already exists. Any error in\r
- renaming will return a tagged NO response.\r
-\r
- Renaming INBOX is permitted; a new, empty INBOX is created in its\r
- place.\r
-\r
- Example: C: Z4S9 RENAME blurdybloop owatagusiam\r
- S: Z4S9 OK RENAME completed\r
-\r
-\r
-6.3.6. SUBSCRIBE Command\r
-\r
- Arguments: mailbox\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - subscribe completed\r
- NO - subscribe failure: can't subscribe to that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The SUBSCRIBE command adds the specified mailbox name to the\r
- server's set of "active" or "subscribed" mailboxes as returned by\r
- the LSUB command. This command returns a tagged OK response only\r
- if the subscription is successful.\r
-\r
- Example: C: A002 SUBSCRIBE #news.comp.mail.mime\r
- S: A002 OK SUBSCRIBE completed\r
-\r
-\r
-6.3.7. UNSUBSCRIBE Command\r
-\r
- Arguments: mailbox name\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - unsubscribe completed\r
- NO - unsubscribe failure: can't unsubscribe that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The UNSUBSCRIBE command removes the specified mailbox name from\r
- the server's set of "active" or "subscribed" mailboxes as returned\r
- by the LSUB command. This command returns a tagged OK response\r
- only if the unsubscription is successful.\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 19]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime\r
- S: A002 OK UNSUBSCRIBE completed\r
-\r
-\r
-6.3.8. LIST Command\r
-\r
- Arguments: reference name\r
- mailbox name with possible wildcards\r
-\r
- Data: untagged responses: LIST\r
-\r
- Result: OK - list completed\r
- NO - list failure: can't list that reference or name\r
- BAD - command unknown or arguments invalid\r
-\r
- The LIST command returns a subset of names from the complete set\r
- of all names available to the user. Zero or more untagged LIST\r
- replies are returned, containing the name attributes, hierarchy\r
- delimiter, and name; see the description of the LIST reply for\r
- more detail.\r
-\r
- An empty ("" string) reference name argument indicates that the\r
- mailbox name is interpreted as by SELECT. The returned mailbox\r
- names MUST match the supplied mailbox name pattern. A non-empty\r
- reference name argument is the name of a mailbox or a level of\r
- mailbox hierarchy, and indicates a context in which the mailbox\r
- name is interpreted in an implementation-defined manner.\r
-\r
- The reference and mailbox name arguments are interpreted, in an\r
- implementation-dependent fashion, into a canonical form that\r
- represents an unambiguous left-to-right hierarchy. The returned\r
- mailbox names will be in the interpreted form.\r
-\r
- Any part of the reference argument that is included in the\r
- interpreted form SHOULD prefix the interpreted form. It should\r
- also be in the same form as the reference name argument. This\r
- rule permits the client to determine if the returned mailbox name\r
- is in the context of the reference argument, or if something about\r
- the mailbox argument overrode the reference argument. Without\r
- this rule, the client would have to have knowledge of the server's\r
- naming semantics including what characters are "breakouts" that\r
- override a naming context.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 20]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- For example, here are some examples of how references\r
- and mailbox names might be interpreted on a UNIX-based\r
- server:\r
-\r
- Reference Mailbox Name Interpretation\r
- ------------ ------------ --------------\r
- ~smith/Mail/ foo.* ~smith/Mail/foo.*\r
- archive/ % archive/%\r
- #news. comp.mail.* #news.comp.mail.*\r
- ~smith/Mail/ /usr/doc/foo /usr/doc/foo\r
- archive/ ~fred/Mail/* ~fred/Mail/*\r
-\r
- The first three examples demonstrate interpretations in\r
- the context of the reference argument. Note that\r
- "~smith/Mail" should not be transformed into something\r
- like "/u2/users/smith/Mail", or it would be impossible\r
- for the client to determine that the interpretation was\r
- in the context of the reference.\r
-\r
- The character "*" is a wildcard, and matches zero or more\r
- characters at this position. The character "%" is similar to "*",\r
- but it does not match a hierarchy delimiter. If the "%" wildcard\r
- is the last character of a mailbox name argument, matching levels\r
- of hierarchy are also returned. If these levels of hierarchy are\r
- not also selectable mailboxes, they are returned with the\r
- \Noselect mailbox name attribute (see the description of the LIST\r
- response for more detail).\r
-\r
- Server implementations are permitted to "hide" otherwise\r
- accessible mailboxes from the wildcard characters, by preventing\r
- certain characters or names from matching a wildcard in certain\r
- situations. For example, a UNIX-based server might restrict the\r
- interpretation of "*" so that an initial "/" character does not\r
- match.\r
-\r
- The special name INBOX is included in the output from LIST if it\r
- matches the input arguments and INBOX is supported by this server\r
- for this user. The criteria for omitting INBOX is whether SELECT\r
- INBOX will return failure; it is not relevant whether the user's\r
- real INBOX resides on this or some other server.\r
-\r
- Example: C: A002 LIST "~/Mail/" "%"\r
- S: * LIST (\Noselect) "/" ~/Mail/foo\r
- S: * LIST () "/" ~/Mail/meetings\r
- S: A002 OK LIST completed\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 21]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6.3.9. LSUB Command\r
-\r
- Arguments: reference name\r
- mailbox name with possible wildcards\r
-\r
- Data: untagged responses: LSUB\r
-\r
- Result: OK - lsub completed\r
- NO - lsub failure: can't list that reference or name\r
- BAD - command unknown or arguments invalid\r
-\r
- The LSUB command returns a subset of names from the set of names\r
- that the user has declared as being "active" or "subscribed".\r
- Zero or more untagged LSUB replies are returned. The arguments to\r
- LSUB are in the same form as those for LIST.\r
-\r
- Example: C: A002 LSUB "#news." "comp.mail.*"\r
- S: * LSUB () "." #news.comp.mail.mime\r
- S: * LSUB () "." #news.comp.mail.misc\r
- S: A002 OK LSUB completed\r
-\r
-\r
-6.3.10. APPEND Command\r
-\r
- Arguments: mailbox name\r
- optional flag parenthesized list\r
- optional date/time string\r
- message literal\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - append completed\r
- NO - append error: can't append to that mailbox, error\r
- in flags or date/time or message text\r
- BAD - command unknown or arguments invalid\r
-\r
- The APPEND command appends the literal argument as a new message\r
- in the specified destination mailbox. This argument is in the\r
- format of an [RFC-822] message. 8-bit characters are permitted in\r
- the message. A server implementation that is unable to preserve\r
- 8-bit data properly MUST be able to reversibly convert 8-bit\r
- APPEND data to 7-bit using [MIME-1] encoding.\r
-\r
- If a flag parenthesized list or date_time are specified, that data\r
- SHOULD be set in the resulting message; otherwise, the defaults of\r
- empty flags and the current date/time are used.\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 22]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- If the append is unsuccessful for any reason, the mailbox MUST be\r
- restored to its state before the APPEND attempt; no partial\r
- appending is permitted. If the mailbox is currently selected, the\r
- normal new mail actions should occur.\r
-\r
- If the destination mailbox does not exist, a server MUST return an\r
- error, and MUST NOT automatically create the mailbox. Unless it\r
- is certain that the destination mailbox can not be created, the\r
- server MUST send the response code "[TRYCREATE]" as the prefix of\r
- the text of the tagged NO response. This gives a hint to the\r
- client that it can attempt a CREATE command and retry the APPEND\r
- if the CREATE is successful.\r
-\r
- Example: C: A003 APPEND saved-messages (\Seen) {310}\r
- C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)\r
- C: From: Fred Foobar <foobar@Blurdybloop.COM>\r
- C: Subject: afternoon meeting\r
- C: To: mooch@owatagu.siam.edu\r
- C: Message-Id: <B27397-0100000@Blurdybloop.COM>\r
- C: MIME-Version: 1.0\r
- C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII\r
- C:\r
- C: Hello Joe, do you think we can meet at 3:30 tomorrow?\r
- C:\r
- S: A003 OK APPEND completed\r
-\r
- Note: the APPEND command is not used for message delivery,\r
- because it does not provide a mechanism to transfer [SMTP]\r
- envelope information.\r
-\r
-\r
-\r
-6.4. Client Commands - Selected State\r
-\r
- In selected state, commands that manipulate messages in a mailbox are\r
- permitted.\r
-\r
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),\r
- and the authenticated state commands (SELECT, EXAMINE, CREATE,\r
- DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND\r
- ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands\r
- are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,\r
- FETCH, PARTIAL, STORE, COPY, and UID.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 23]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6.4.1. CHECK Command\r
-\r
- Arguments: none\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - check completed\r
- BAD - command unknown or arguments invalid\r
-\r
- The CHECK command requests a checkpoint of the currently selected\r
- mailbox. A checkpoint refers to any implementation-dependent\r
- housekeeping associated with the mailbox (e.g. resolving the\r
- server's in-memory state of the mailbox with the state on its\r
- disk) that is not normally executed as part of each command. A\r
- checkpoint may take a non-instantaneous amount of real time to\r
- complete. If a server implementation has no such housekeeping\r
- considerations, CHECK is equivalent to NOOP.\r
-\r
- There is no guarantee that an EXISTS untagged response will happen\r
- as a result of CHECK. NOOP, not CHECK, should be used for new\r
- mail polling.\r
-\r
- Example: C: FXXZ CHECK\r
- S: FXXZ OK CHECK Completed\r
-\r
-\r
-6.4.2. CLOSE Command\r
-\r
- Arguments: none\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - close completed, now in authenticated state\r
- NO - close failure: no mailbox selected\r
- BAD - command unknown or arguments invalid\r
-\r
- The CLOSE command permanently removes from the currently selected\r
- mailbox all messages that have the \Deleted flag set, and returns\r
- to authenticated state from selected state. No untagged EXPUNGE\r
- responses are sent.\r
-\r
- No messages are removed, and no error is given, if the mailbox is\r
- selected by an EXAMINE command or is otherwise selected read-only.\r
-\r
- Even when a mailbox is selected, it is not required to send a\r
- CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The\r
- SELECT, EXAMINE, and LOGOUT commands implicitly close the\r
- currently selected mailbox without doing an expunge. However,\r
-\r
-\r
-\r
-Crispin [Page 24]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT\r
- sequence is considerably faster than an EXPUNGE-LOGOUT or\r
- EXPUNGE-SELECT because no untagged EXPUNGE responses (which the\r
- client would probably ignore) are sent.\r
-\r
- Example: C: A341 CLOSE\r
- S: A341 OK CLOSE completed\r
-\r
-\r
-6.4.3. EXPUNGE Command\r
-\r
- Arguments: none\r
-\r
- Data: untagged responses: EXPUNGE\r
-\r
- Result: OK - expunge completed\r
- NO - expunge failure: can't expunge (e.g. permission\r
- denied)\r
- BAD - command unknown or arguments invalid\r
-\r
- The EXPUNGE command permanently removes from the currently\r
- selected mailbox all messages that have the \Deleted flag set.\r
- Before returning an OK to the client, an untagged EXPUNGE response\r
- is sent for each message that is removed.\r
-\r
- Example: C: A202 EXPUNGE\r
- S: * 3 EXPUNGE\r
- S: * 3 EXPUNGE\r
- S: * 5 EXPUNGE\r
- S: * 8 EXPUNGE\r
- S: A202 OK EXPUNGE completed\r
-\r
- Note: in this example, messages 3, 4, 7, and 11 had the\r
- \Deleted flag set. See the description of the EXPUNGE\r
- response for further explanation.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 25]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6.4.4. SEARCH Command\r
-\r
- Arguments: optional character set specification\r
- searching criteria (one or more)\r
-\r
- Data: mandatory untagged response: SEARCH\r
-\r
- Result: OK - search completed\r
- NO - search error: can't search that character set or\r
- criteria\r
- BAD - command unknown or arguments invalid\r
-\r
- The SEARCH command searches the mailbox for messages that match\r
- the given searching criteria. Searching criteria consist of one\r
- or more search keys. The untagged SEARCH response from the server\r
- contains a listing of message sequence numbers corresponding to\r
- those messages that match the searching criteria.\r
-\r
- When multiple keys are specified, the result is the intersection\r
- (AND function) of all the messages that match those keys. For\r
- example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers\r
- to all deleted messages from Smith that were placed in the mailbox\r
- since February 1, 1994. A search key may also be a parenthesized\r
- list of one or more search keys (e.g. for use with the OR and NOT\r
- keys).\r
-\r
- Server implementations MAY exclude [MIME-1] body parts with\r
- terminal content types other than TEXT and MESSAGE from\r
- consideration in SEARCH matching.\r
-\r
- The optional character set specification consists of the word\r
- "CHARSET" followed by a registered MIME character set. It\r
- indicates the character set of the strings that appear in the\r
- search criteria. [MIME-2] strings that appear in RFC 822/MIME\r
- message headers, and [MIME-1] content transfer encodings, MUST be\r
- decoded before matching. Except for US-ASCII, it is not required\r
- that any particular character set be supported. If the server\r
- does not support the specified character set, it MUST return a\r
- tagged NO response (not a BAD).\r
-\r
- In all search keys that use strings, a message matches the key if\r
- the string is a substring of the field. The matching is\r
- case-insensitive.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 26]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- The defined search keys are as follows. Refer to the Formal\r
- Syntax section for the precise syntactic definitions of the\r
- arguments.\r
-\r
- <message set> Messages with message sequence numbers\r
- corresponding to the specified message sequence\r
- number set\r
-\r
- ALL All messages in the mailbox; the default initial\r
- key for ANDing.\r
-\r
- ANSWERED Messages with the \Answered flag set.\r
-\r
- BCC <string> Messages that contain the specified string in the\r
- envelope structure's BCC field.\r
-\r
- BEFORE <date> Messages whose internal date is earlier than the\r
- specified date.\r
-\r
- BODY <string> Messages that contain the specified string in the\r
- body of the message.\r
-\r
- CC <string> Messages that contain the specified string in the\r
- envelope structure's CC field.\r
-\r
- DELETED Messages with the \Deleted flag set.\r
-\r
- DRAFT Messages with the \Draft flag set.\r
-\r
- FLAGGED Messages with the \Flagged flag set.\r
-\r
- FROM <string> Messages that contain the specified string in the\r
- envelope structure's FROM field.\r
-\r
- HEADER <field-name> <string>\r
- Messages that have a header with the specified\r
- field-name (as defined in [RFC-822]) and that\r
- contains the specified string in the [RFC-822]\r
- field-body.\r
-\r
- KEYWORD <flag> Messages with the specified keyword set.\r
-\r
- LARGER <n> Messages with an RFC822.SIZE larger than the\r
- specified number of octets.\r
-\r
- NEW Messages that have the \Recent flag set but not the\r
- \Seen flag. This is functionally equivalent to\r
- "(RECENT UNSEEN)".\r
-\r
-\r
-\r
-Crispin [Page 27]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- NOT <search-key>\r
- Messages that do not match the specified search\r
- key.\r
-\r
- OLD Messages that do not have the \Recent flag set.\r
- This is functionally equivalent to "NOT RECENT" (as\r
- opposed to "NOT NEW").\r
-\r
- ON <date> Messages whose internal date is within the\r
- specified date.\r
-\r
- OR <search-key1> <search-key2>\r
- Messages that match either search key.\r
-\r
- RECENT Messages that have the \Recent flag set.\r
-\r
- SEEN Messages that have the \Seen flag set.\r
-\r
- SENTBEFORE <date>\r
- Messages whose [RFC-822] Date: header is earlier\r
- than the specified date.\r
-\r
- SENTON <date> Messages whose [RFC-822] Date: header is within the\r
- specified date.\r
-\r
- SENTSINCE <date>\r
- Messages whose [RFC-822] Date: header is within or\r
- later than the specified date.\r
-\r
- SINCE <date> Messages whose internal date is within or later\r
- than the specified date.\r
-\r
- SMALLER <n> Messages with an RFC822.SIZE smaller than the\r
- specified number of octets.\r
-\r
- SUBJECT <string>\r
- Messages that contain the specified string in the\r
- envelope structure's SUBJECT field.\r
-\r
- TEXT <string> Messages that contain the specified string in the\r
- header or body of the message.\r
-\r
- TO <string> Messages that contain the specified string in the\r
- envelope structure's TO field.\r
-\r
- UID <message set>\r
- Messages with unique identifiers corresponding to\r
- the specified unique identifier set.\r
-\r
-\r
-\r
-Crispin [Page 28]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- UNANSWERED Messages that do not have the \Answered flag set.\r
-\r
- UNDELETED Messages that do not have the \Deleted flag set.\r
-\r
- UNDRAFT Messages that do not have the \Draft flag set.\r
-\r
- UNFLAGGED Messages that do not have the \Flagged flag set.\r
-\r
- UNKEYWORD <flag>\r
- Messages that do not have the specified keyword\r
- set.\r
-\r
- UNSEEN Messages that do not have the \Seen flag set.\r
-\r
-\r
- Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"\r
- S: * SEARCH 2 84 882\r
- S: A282 OK SEARCH completed\r
-\r
-\r
-6.4.5. FETCH Command\r
-\r
- Arguments: message set\r
- message data item names\r
-\r
- Data: untagged responses: FETCH\r
-\r
- Result: OK - fetch completed\r
- NO - fetch error: can't fetch that data\r
- BAD - command unknown or arguments invalid\r
-\r
- The FETCH command retrieves data associated with a message in the\r
- mailbox. The data items to be fetched may be either a single atom\r
- or a parenthesized list. The currently defined data items that\r
- can be fetched are:\r
-\r
- ALL Macro equivalent to: (FLAGS INTERNALDATE\r
- RFC822.SIZE ENVELOPE)\r
-\r
- BODY Non-extensible form of BODYSTRUCTURE.\r
-\r
- BODY[<section>]\r
- The text of a particular body section. The section\r
- specification is a set of one or more part numbers\r
- delimited by periods.\r
-\r
- Single-part messages only have a part 1.\r
-\r
-\r
-\r
-\r
-Crispin [Page 29]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Multipart messages are assigned consecutive part\r
- numbers, as they occur in the message. If a\r
- particular part is of type message or multipart,\r
- its parts must be indicated by a period followed by\r
- the part number within that nested multipart part.\r
- It is not permitted to fetch a multipart part\r
- itself, only its individual members.\r
-\r
- A part of type MESSAGE and subtype RFC822 also has\r
- nested parts. These are the parts of the MESSAGE\r
- part's body. Nested part 0 of a part of type\r
- MESSAGE and subtype RFC822 is the [RFC-822] header\r
- of the message.\r
-\r
- Every message has at least one part.\r
-\r
- Here is an example of a complex message\r
- with its associated section\r
- specifications:\r
-\r
- 0 ([RFC-822] header of the message)\r
- MULTIPART/MIXED\r
- 1 TEXT/PLAIN\r
- 2 APPLICATION/OCTET-STREAM\r
- 3 MESSAGE/RFC822\r
- 3.0 ([RFC-822] header of the message)\r
- 3.1 TEXT/PLAIN\r
- 3.2 APPLICATION/OCTET-STREAM\r
- MULTIPART/MIXED\r
- 4.1 IMAGE/GIF\r
- 4.2 MESSAGE/RFC822\r
- 4.2.0 ([RFC-822] header of the message)\r
- 4.2.1 TEXT/PLAIN\r
- MULTIPART/ALTERNATIVE\r
- 4.2.2.1 TEXT/PLAIN\r
- 4.2.2.2 TEXT/RICHTEXT\r
-\r
- Note that there is no section\r
- specification for the Multi-part parts\r
- (no section 4 or 4.2.2).\r
-\r
- The \Seen flag is implicitly set; if this causes\r
- the flags to change they should be included as part\r
- of the fetch responses.\r
-\r
- BODY.PEEK[<section>]\r
- An alternate form of BODY[section] that does not\r
- implicitly set the \Seen flag.\r
-\r
-\r
-\r
-Crispin [Page 30]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- BODYSTRUCTURE The [MIME-1] body structure of the message. This\r
- is computed by the server by parsing the [MIME-1]\r
- header lines.\r
-\r
- ENVELOPE The envelope structure of the message. This is\r
- computed by the server by parsing the [RFC-822]\r
- header into the component parts, defaulting various\r
- fields as necessary.\r
-\r
- FAST Macro equivalent to: (FLAGS INTERNALDATE\r
- RFC822.SIZE)\r
-\r
- FLAGS The flags that are set for this message.\r
-\r
- FULL Macro equivalent to: (FLAGS INTERNALDATE\r
- RFC822.SIZE ENVELOPE BODY)\r
-\r
- INTERNALDATE The date and time of final delivery of the message\r
- as defined by RFC 821.\r
-\r
- RFC822 The message in [RFC-822] format. The \Seen flag is\r
- implicitly set; if this causes the flags to change\r
- they should be included as part of the fetch\r
- responses. This is the concatenation of\r
- RFC822.HEADER and RFC822.TEXT.\r
-\r
- RFC822.PEEK An alternate form of RFC822 that does not\r
- implicitly set the \Seen flag.\r
-\r
- RFC822.HEADER The [RFC-822] format header of the message as\r
- stored on the server including the delimiting blank\r
- line between the header and the body.\r
-\r
- RFC822.HEADER.LINES <header_list>\r
- All header lines (including continuation lines) of\r
- the [RFC-822] format header of the message with a\r
- field-name (as defined in [RFC-822]) that matches\r
- any of the strings in header_list. The matching is\r
- case-insensitive but otherwise exact. The\r
- delimiting blank line between the header and the\r
- body is always included.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 31]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- RFC822.HEADER.LINES.NOT <header_list>\r
- All header lines (including continuation lines) of\r
- the [RFC-822] format header of the message with a\r
- field-name (as defined in [RFC-822]) that does not\r
- match any of the strings in header_list. The\r
- matching is case-insensitive but otherwise exact.\r
- The delimiting blank line between the header and\r
- the body is always included.\r
-\r
- RFC822.SIZE The number of octets in the message, as expressed\r
- in [RFC-822] format.\r
-\r
- RFC822.TEXT The text body of the message, omitting the\r
- [RFC-822] header. The \Seen flag is implicitly\r
- set; if this causes the flags to change they should\r
- be included as part of the fetch responses.\r
-\r
- RFC822.TEXT.PEEK\r
- An alternate form of RFC822.TEXT that does not\r
- implicitly set the \Seen flag.\r
-\r
- UID The unique identifier for the message.\r
-\r
-\r
- Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))\r
- S: * 2 FETCH ....\r
- S: * 3 FETCH ....\r
- S: * 4 FETCH ....\r
- S: A003 OK FETCH completed\r
-\r
-\r
-6.4.6. PARTIAL Command\r
-\r
- Arguments: message sequence number\r
- message data item name\r
- position of first octet\r
- number of octets\r
-\r
- Data: untagged responses: FETCH\r
-\r
- Result: OK - partial completed\r
- NO - partial error: can't fetch that data\r
- BAD - command unknown or arguments invalid\r
-\r
- The PARTIAL command is equivalent to the associated FETCH command,\r
- with the added functionality that only the specified number of\r
- octets, beginning at the specified starting octet, are returned.\r
- Only a single message can be fetched at a time. The first octet\r
-\r
-\r
-\r
-Crispin [Page 32]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- of a message, and hence the minimum for the starting octet, is\r
- octet 1.\r
-\r
- The following FETCH items are valid data for PARTIAL: RFC822,\r
- RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK\r
- forms of these.\r
-\r
- Any partial fetch that attempts to read beyond the end of the text\r
- is truncated as appropriate. If the starting octet is beyond the\r
- end of the text, an empty string is returned.\r
-\r
- The data are returned with the FETCH response. There is no\r
- indication of the range of the partial data in this response. It\r
- is not possible to stream multiple PARTIAL commands of the same\r
- data item without processing and synchronizing at each step, since\r
- streamed commands may be executed out of order.\r
-\r
- There is no requirement that partial fetches follow any sequence.\r
- For example, if a partial fetch of octets 1 through 10000 breaks\r
- in an awkward place for BASE64 decoding, it is permitted to\r
- continue with a partial fetch of 9987 through 19987, etc.\r
-\r
- The handling of the \Seen flag is the same as in the associated\r
- FETCH command.\r
-\r
- Example: C: A005 PARTIAL 4 RFC822 1 1024\r
- S: * 1 FETCH (RFC822 {1024}\r
- S: Return-Path: <gray@cac.washington.edu>\r
- S: ...\r
- S: ......... FLAGS (\Seen))\r
- S: A005 OK PARTIAL completed\r
-\r
-\r
-6.4.7. STORE Command\r
-\r
- Arguments: message set\r
- message data item name\r
- value for message data item\r
-\r
- Data: untagged responses: FETCH\r
-\r
- Result: OK - store completed\r
- NO - store error: can't store that data\r
- BAD - command unknown or arguments invalid\r
-\r
- The STORE command alters data associated with a message in the\r
- mailbox. Normally, STORE will return the updated value of the\r
- data with an untagged FETCH response. A suffix of ".SILENT" in\r
-\r
-\r
-\r
-Crispin [Page 33]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- the data item name prevents the untagged FETCH, and the server\r
- should assume that the client has determined the updated value\r
- itself or does not care about the updated value.\r
-\r
- The currently defined data items that can be stored are:\r
-\r
- FLAGS <flag list>\r
- Replace the flags for the message with the\r
- argument. The new value of the flags are returned\r
- as if a FETCH of those flags was done.\r
-\r
- FLAGS.SILENT <flag list>\r
- Equivalent to FLAGS, but without returning a new\r
- value.\r
-\r
- +FLAGS <flag list>\r
- Add the argument to the flags for the message. The\r
- new value of the flags are returned as if a FETCH\r
- of those flags was done.\r
-\r
- +FLAGS.SILENT <flag list>\r
- Equivalent to +FLAGS, but without returning a new\r
- value.\r
-\r
- -FLAGS <flag list>\r
- Remove the argument from the flags for the message.\r
- The new value of the flags are returned as if a\r
- FETCH of those flags was done.\r
-\r
- -FLAGS.SILENT <flag list>\r
- Equivalent to -FLAGS, but without returning a new\r
- value.\r
-\r
-\r
- Example: C: A003 STORE 2:4 +FLAGS (\Deleted)\r
- S: * 2 FETCH FLAGS (\Deleted \Seen)\r
- S: * 3 FETCH FLAGS (\Deleted)\r
- S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)\r
- S: A003 OK STORE completed\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 34]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-6.4.8. COPY Command\r
-\r
- Arguments: message set\r
- mailbox name\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - copy completed\r
- NO - copy error: can't copy those messages or to that\r
- name\r
- BAD - command unknown or arguments invalid\r
-\r
- The COPY command copies the specified message(s) to the specified\r
- destination mailbox. The flags and internal date of the\r
- message(s) SHOULD be preserved in the copy.\r
-\r
- If the destination mailbox does not exist, a server SHOULD return\r
- an error. It SHOULD NOT automatically create the mailbox. Unless\r
- it is certain that the destination mailbox can not be created, the\r
- server MUST send the response code "[TRYCREATE]" as the prefix of\r
- the text of the tagged NO response. This gives a hint to the\r
- client that it can attempt a CREATE command and retry the COPY if\r
- the CREATE is successful.\r
-\r
- If the COPY command is unsuccessful for any reason, server\r
- implementations MUST restore the destination mailbox to its state\r
- before the COPY attempt.\r
-\r
- Example: C: A003 COPY 2:4 MEETING\r
- S: A003 OK COPY completed\r
-\r
-\r
-6.4.9. UID Command\r
-\r
- Arguments: command name\r
- command arguments\r
-\r
- Data: untagged responses: FETCH, SEARCH\r
-\r
- Result: OK - UID command completed\r
- NO - UID command error\r
- BAD - command unknown or arguments invalid\r
-\r
- The UID command has two forms. In the first form, it takes as its\r
- arguments a COPY, FETCH, or STORE command with arguments\r
- appropriate for the associated command. However, the numbers in\r
- the message set argument are unique identifiers instead of message\r
- sequence numbers.\r
-\r
-\r
-\r
-Crispin [Page 35]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- In the second form, the UID command takes a SEARCH command with\r
- SEARCH command arguments. The interpretation of the arguments is\r
- the same as with SEARCH; however, the numbers returned in a SEARCH\r
- response for a UID SEARCH command are unique identifiers instead\r
- of message sequence numbers. For example, the command UID SEARCH\r
- 1:100 UID 443:557 returns the unique identifiers corresponding to\r
- the intersection of the message sequence number set 1:100 and the\r
- UID set 443:557.\r
-\r
- A unique identifier of a message is a number, and is guaranteed\r
- not to refer to any other message in the mailbox. Unique\r
- identifiers are assigned in a strictly ascending fashion for each\r
- message added to the mailbox. Unlike message sequence numbers,\r
- unique identifiers persist across sessions. This permits a client\r
- to resynchronize its state from a previous session with the server\r
- (e.g. disconnected or offline access clients); this is discussed\r
- further in [IMAP-DISC].\r
-\r
- Associated with every mailbox is a unique identifier validity\r
- value, which is sent in an UIDVALIDITY response code in an OK\r
- untagged response at message selection time. If unique\r
- identifiers from an earlier session fail to persist to this\r
- session, the unique identifier validity value MUST be greater than\r
- in the earlier session.\r
-\r
- Note: An example of a good value to use for the unique\r
- identifier validity value would be a 32-bit\r
- representation of the creation date/time of the mailbox.\r
- It is alright to use a constant such as 1, but only if\r
- it guaranteed that unique identifers will never be\r
- reused, even in the case of a mailbox being deleted and\r
- a new mailbox by the same name created at some future\r
- time.\r
-\r
-\r
- Message set ranges are permitted; however, there is no guarantee\r
- that unique identifiers be contiguous. A non-existent unique\r
- identifier within a message set range is ignored without any error\r
- message generated.\r
-\r
- The number after the "*" in an untagged FETCH response is always a\r
- message sequence number, not a unique identifier, even for a UID\r
- command response. However, server implementations MUST implicitly\r
- include the UID message data item as part of any FETCH response\r
- caused by a UID command, regardless of whether UID was specified\r
- as a message data item to the FETCH.\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 36]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Example: C: A003 UID FETCH 4827313:4828442 FLAGS\r
- S: * 23 FETCH (FLAGS (\Seen) UID 4827313)\r
- S: * 24 FETCH (FLAGS (\Seen) UID 4827943)\r
- S: * 25 FETCH (FLAGS (\Seen) UID 4828442)\r
- S: A999 UID FETCH completed\r
-\r
-\r
-\r
-6.5. Client Commands - Experimental/Expansion\r
-\r
-\r
-6.5.1. X<atom> Command\r
-\r
- Arguments: implementation defined\r
-\r
- Data: implementation defined\r
-\r
- Result: OK - command completed\r
- NO - failure\r
- BAD - command unknown or arguments invalid\r
-\r
- Any command prefixed with an X is an experimental command.\r
- Commands which are not part of this specification, or a standard\r
- or standards-track revision of this specification, MUST use the X\r
- prefix.\r
-\r
- Any added untagged responses issued by an experimental command\r
- MUST also be prefixed with an X. Server implementations MUST NOT\r
- send any such untagged responses, unless the client requested it\r
- by issuing the associated experimental command.\r
-\r
- Example: C: a441 CAPABILITY\r
- S: * CAPABILITY IMAP4 XPIG-LATIN\r
- S: a441 OK CAPABILITY completed\r
- C: A442 XPIG-LATIN\r
- S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay\r
- S: A442 OK XPIG-LATIN ompleted-cay\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 37]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-7. Server Responses\r
-\r
- Server responses are in three forms: status responses, server data,\r
- and command continuation request.\r
-\r
- Server response data, identified by "Data:" in the response\r
- descriptions below, are described by function, not by syntax. The\r
- precise syntax of server response data is described in the Formal\r
- Syntax section.\r
-\r
- The client MUST be prepared to accept any response at all times.\r
-\r
- Status responses that are tagged indicate the completion result of a\r
- client command, and have a tag matching the command.\r
-\r
- Some status responses, and all server data, are untagged. An\r
- untagged response is indicated by the token "*" instead of a tag.\r
- Untagged status responses indicate server greeting, or server status\r
- that does not indicate the completion of a command. For historical\r
- reasons, untagged server data responses are also called "unsolicited\r
- data", although strictly speaking only unilateral server data is\r
- truly "unsolicited".\r
-\r
- Certain server data MUST be recorded by the client when it is\r
- received; this is noted in the description of that data. Such data\r
- conveys critical information which affects the interpretation of all\r
- subsequent commands and responses (e.g. updates reflecting the\r
- creation or destruction of messags).\r
-\r
- Other server data SHOULD be recorded for later reference; if the\r
- client does not need to record the data, or if recording the data has\r
- no obvious purpose (e.g. a SEARCH response when no SEARCH command is\r
- in progress), the data SHOULD be ignored.\r
-\r
- An example of unilateral untagged responses occurs when the IMAP\r
- connection is in selected state. In selected state, the server\r
- checks the mailbox for new messages as part of the execution of each\r
- command. If new messages are found, the server sends untagged EXISTS\r
- and RECENT responses reflecting the new size of the mailbox. Server\r
- implementations that offer multiple simultaneous access to the same\r
- mailbox should also send appropriate unilateral untagged FETCH and\r
- EXPUNGE responses if another agent changes the state of any message\r
- flags or expunges any messages.\r
-\r
- Command continuation request responses use the token "+" instead of a\r
- tag. These responses are sent by the server to indicate acceptance\r
- of an incomplete client command and readiness for the remainder of\r
- the command.\r
-\r
-\r
-\r
-Crispin [Page 38]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-7.1. Server Responses - Status Responses\r
-\r
- Status responses may include an optional response code. A response\r
- code consists of data inside square brackets in the form of an atom,\r
- possibly followed by a space and arguments. The response code\r
- contains additional information or status codes for client software\r
- beyond the OK/NO/BAD condition, and are defined when there is a\r
- specific action that a client can take based upon the additional\r
- information.\r
-\r
- The currently defined response codes are:\r
-\r
- ALERT The human-readable text contains a special alert\r
- that MUST be presented to the user in a fashion\r
- that calls the user's attention to the message.\r
-\r
- PARSE The human-readable text represents an error in\r
- parsing the [RFC-822] or [MIME-1] headers of a\r
- message in the mailbox.\r
-\r
- PERMANENTFLAGS Followed by a parenthesized list of flags,\r
- indicates which of the known flags that the client\r
- may change permanently. Any flags that are in the\r
- FLAGS untagged response, but not the PERMANENTFLAGS\r
- list, can not be set permanently. If the client\r
- attempts to STORE a flag that is not in the\r
- PERMANENTFLAGS list, the server will either reject\r
- it with a NO reply or store the state for the\r
- remainder of the current session only. The\r
- PERMANENTFLAGS list may also include the special\r
- flag \*, which indicates that it is possible to\r
- create new keywords by attempting to store those\r
- flags in the mailbox.\r
-\r
- READ-ONLY The mailbox is selected read-only, or its access\r
- while selected has changed from read-write to\r
- read-only.\r
-\r
- READ-WRITE The mailbox is selected read-write, or its access\r
- while selected has changed from read-only to\r
- read-write.\r
-\r
- TRYCREATE An APPEND or COPY attempt is failing because the\r
- target mailbox does not exist (as opposed to some\r
- other reason). This is a hint to the client that\r
- the operation may succeed if the mailbox is first\r
- created by the CREATE command.\r
-\r
-\r
-\r
-\r
-Crispin [Page 39]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- UIDVALIDITY Followed by a decimal number, indicates the unique\r
- identifier validity value. See the description of\r
- the UID command for more detail.\r
-\r
- UNSEEN Followed by a decimal number, indicates the number\r
- of the first message without the \Seen flag set.\r
-\r
- Additional response codes defined by particular client or server\r
- implementations should be prefixed with an "X" until they are\r
- added to a revision of this protocol. Client implementations\r
- should ignore response codes that they do not recognize.\r
-\r
-\r
-7.1.1. OK Response\r
-\r
- Data: optional response code\r
- human-readable text\r
-\r
- The OK response indicates an information message from the server.\r
- When tagged, it indicates successful completion of the associated\r
- command. The human-readable text may be presented to the user as\r
- an information message. The untagged form indicates an\r
- information-only message; the nature of the information may be\r
- indicated by a response code.\r
-\r
- The untagged form is also used as one of three possible greetings\r
- at session startup. It indicates that the session is not yet\r
- authenticated and that a LOGIN command is needed.\r
-\r
- Example: S: * OK IMAP4 server ready\r
- C: A001 LOGIN fred blurdybloop\r
- S: * OK [ALERT] System shutdown in 10 minutes\r
- S: A001 OK LOGIN Completed\r
-\r
-\r
-7.1.2. NO Response\r
-\r
- Data: optional response code\r
- human-readable text\r
-\r
- The NO response indicates an operational error message from the\r
- server. When tagged, it indicates unsuccessful completion of the\r
- associated command. The untagged form indicates a warning; the\r
- command may still complete successfully. The human-readable text\r
- describes the condition.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 40]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Example: C: A222 COPY 1:2 owatagusiam\r
- S: * NO Disk is 98% full, please delete unnecessary data\r
- S: A222 OK COPY completed\r
- C: A222 COPY 3:200 blurdybloop\r
- S: * NO Disk is 98% full, please delete unnecessary data\r
- S: * NO Disk is 99% full, please delete unnecessary data\r
- S: A222 NO COPY failed: disk is full\r
-\r
-\r
-7.1.3. BAD Response\r
-\r
- Data: optional response code\r
- human-readable text\r
-\r
- The BAD response indicates an error message from the server. When\r
- tagged, it reports a protocol-level error in the client's command;\r
- the tag indicates the command that caused the error. The untagged\r
- form indicates a protocol-level error for which the associated\r
- command can not be determined; it may also indicate an internal\r
- server failure. The human-readable text describes the condition.\r
-\r
- Example: C: ...very long command line...\r
- S: * BAD Command line too long\r
- C: ...empty line...\r
- S: * BAD Empty command line\r
- C: A443 EXPUNGE\r
- S: * BAD Disk crash, attempting salvage to a new disk!\r
- S: * OK Salvage successful, no data lost\r
- S: A443 OK Expunge completed\r
-\r
-\r
-7.1.4. PREAUTH Response\r
-\r
- Data: optional response code\r
- human-readable text\r
-\r
- The PREAUTH response is always untagged, and is one of three\r
- possible greetings at session startup. It indicates that the\r
- session has already been authenticated by external means and thus\r
- no LOGIN command is needed.\r
-\r
- Example: S: * PREAUTH IMAP4 server ready and logged in as Smith\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 41]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-7.1.5. BYE Response\r
-\r
- Data: optional response code\r
- human-readable text\r
-\r
- The BYE response is always untagged, and indicates that the server\r
- is about to close the connection. The human-readable text may be\r
- displayed to the user in a status report by the client. The BYE\r
- response may be sent as part of a normal logout sequence, or as a\r
- panic shutdown announcement by the server. It is also used by\r
- some server implementations as an announcement of an inactivity\r
- autologout.\r
-\r
- This response is also used as one of three possible greetings at\r
- session startup. It indicates that the server is not willing to\r
- accept a session from this client.\r
-\r
- Example: S: * BYE Autologout; idle for too long\r
-\r
-\r
-\r
-7.2. Server Responses - Server and Mailbox Status\r
-\r
- These responses are always untagged. This is how server data are\r
- transmitted from the server to the client, often as a result of a\r
- command with the same name.\r
-\r
-7.2.1. CAPABILITY Response\r
-\r
- Data: capability listing\r
-\r
- The CAPABILITY response occurs as a result of a CAPABILITY\r
- command. The capability listing contains a space-separated\r
- listing of capability names that the server supports. The first\r
- name in the capability listing MUST be the atom "IMAP4".\r
-\r
- A capability name other than IMAP4 indicates that the server\r
- supports an extension, revision, or amendment to the IMAP4\r
- protocol. Server responses MUST conform to this document until\r
- the client issues a command that uses the associated capability.\r
-\r
- Capability names MUST either begin with "X" or be standard or\r
- standards-track IMAP4 extensions, revisions, or amendments\r
- registered with IANA. A server MUST NOT offer unregistered or\r
- non-standard capability names, unless such names are prefixed with\r
- an "X".\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 42]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Client implementations SHOULD NOT require any capability name\r
- other than "IMAP4", and MUST ignore any unknown capability names.\r
-\r
- Example: S: * CAPABILITY IMAP4 XPIG-LATIN\r
-\r
-\r
-7.2.2. LIST Response\r
-\r
- Data: name attributes\r
- hierarchy delimiter\r
- name\r
-\r
- The LIST response occurs as a result of a LIST command. It\r
- returns a single name that matches the LIST specification. There\r
- may be multiple LIST responses for a single LIST command.\r
-\r
- Four name attributes are defined:\r
-\r
- \Noinferiors It is not possible for any child levels of\r
- hierarchy to exist under this name; no child levels\r
- exist now and none can be created in the future.\r
-\r
- \Noselect It is not possible to use this name as a selectable\r
- mailbox.\r
-\r
- \Marked The mailbox has been marked "interesting" by the\r
- server; the mailbox probably contains messages that\r
- have been added since the last time the mailbox was\r
- selected.\r
-\r
- \Unmarked The mailbox does not contain any additional\r
- messages since the last time the mailbox was\r
- selected.\r
-\r
- If it is not feasible for the server to determine whether the\r
- mailbox is "interesting" or not, or if the name is a \Noselect\r
- name, the server should not send either \Marked or \Unmarked.\r
-\r
- The hierarchy delimiter is a character used to delimit levels of\r
- hierarchy in a mailbox name. A client may use it to create child\r
- mailboxes, and to search higher or lower levels of naming\r
- hierarchy. All children of a top-level hierarchy node must use\r
- the same separator character. A NIL hierarchy delimiter means\r
- that no hierarchy exists; the name is a "flat" name.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 43]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- The name represents an unambiguous left-to-right hierarchy, and\r
- MUST be valid for use as a reference in LIST and LSUB commands.\r
- Unless \Noselect is indicated, the name must also be valid as an\r
- argument for commands, such as SELECT, that accept mailbox names.\r
-\r
- Example: S: * LIST (\Noselect) "/" ~/Mail/foo\r
-\r
-\r
-7.2.3. LSUB Response\r
-\r
- Data: name attributes\r
- hierarchy delimiter\r
- name\r
-\r
- The LSUB response occurs as a result of an LSUB command. It\r
- returns a single name that matches the LSUB specification. There\r
- may be multiple LSUB responses for a single LSUB command. The\r
- data is identical in format to the LIST response.\r
-\r
- Example: S: * LSUB () "." #news.comp.mail.misc\r
-\r
-\r
-7.2.4. SEARCH Response\r
-\r
- Data: zero or more numbers\r
-\r
- The SEARCH response occurs as a result of a SEARCH or UID SEARCH\r
- command. The number(s) refer to those messages that match the\r
- search criteria. For SEARCH, these are message sequence numbers;\r
- for UID SEARCH, these are unique identifiers. Each number is\r
- delimited by a space.\r
-\r
- Example: S: * SEARCH 2 3 6\r
-\r
-\r
-7.2.5. FLAGS Response\r
-\r
- Data: flag parenthesized list\r
-\r
- The FLAGS response occurs as a result of a SELECT or EXAMINE\r
- command. The flag parenthesized list identifies the flags (at a\r
- minimum, the system-defined flags) that are applicable for this\r
- mailbox. Flags other than the system flags may also exist,\r
- depending on server implementation.\r
-\r
- The update from the FLAGS response MUST be recorded by the client.\r
-\r
- Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)\r
-\r
-\r
-\r
-Crispin [Page 44]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-7.3. Server Responses - Message Status\r
-\r
- These responses are always untagged. This is how message data are\r
- transmitted from the server to the client, often as a result of a\r
- command with the same name. Immediately following the "*" token is a\r
- number that represents either a message sequence number or a message\r
- count.\r
-\r
-7.3.1. EXISTS Response\r
-\r
- Data: none\r
-\r
- The EXISTS response reports the number of messages in the mailbox.\r
- This response occurs as a result of a SELECT or EXAMINE command,\r
- and if the size of the mailbox changes (e.g. new mail).\r
-\r
- The update from the EXISTS response MUST be recorded by the\r
- client.\r
-\r
- Example: S: * 23 EXISTS\r
-\r
-\r
-7.3.2. RECENT Response\r
-\r
- Data: none\r
-\r
- The RECENT response reports the number of messages that have\r
- arrived since the previous time a SELECT command was done on this\r
- mailbox. This response occurs as a result of a SELECT or EXAMINE\r
- command, and if the size of the mailbox changes (e.g. new mail).\r
-\r
- The update from the RECENT response MUST be recorded by the\r
- client.\r
-\r
- Example: S: * 5 RECENT\r
-\r
-\r
-7.3.3. EXPUNGE Response\r
-\r
- Data: none\r
-\r
- The EXPUNGE response reports that the specified message sequence\r
- number has been permanently removed from the mailbox. The message\r
- sequence number for each successive message in the mailbox is\r
- immediately decremented by 1, and this decrement is reflected in\r
- message sequence numbers in subsequent responses (including other\r
- untagged EXPUNGE responses).\r
-\r
-\r
-\r
-\r
-Crispin [Page 45]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- As a result of the immediate decrement rule, message sequence\r
- numbers that appear in a set of successive EXPUNGE responses\r
- depend upon whether the messages are removed starting from lower\r
- numbers to higher numbers, or from higher numbers to lower\r
- numbers. For example, if the last 5 messages in a 9-message\r
- mailbox are expunged; a "lower to higher" server will send five\r
- untagged EXPUNGE responses for message sequence number 5, whereas\r
- a "higher to lower server" will send successive untagged EXPUNGE\r
- responses for message sequence numbers 9, 8, 7, 6, and 5.\r
-\r
- An EXPUNGE response MUST NOT be sent when no command is in\r
- progress; nor while responding to a FETCH, STORE, or SEARCH\r
- command. This rule is necessary to prevent a loss of\r
- synchronization of message sequence numbers between client and\r
- server.\r
-\r
- The update from the EXPUNGE response MUST be recorded by the\r
- client.\r
-\r
- Example: S: * 44 EXPUNGE\r
-\r
-\r
-7.3.4. FETCH Response\r
-\r
- Data: message data\r
-\r
- The FETCH response returns data about a message to the client.\r
- The data are pairs of data item names and their values in\r
- parentheses. This response occurs as the result of a FETCH or\r
- STORE command, as well as by unilateral server decision (e.g. flag\r
- updates).\r
-\r
- The current data items are:\r
-\r
- BODY A form of BODYSTRUCTURE without extension data.\r
-\r
- BODY[section] A string expressing the body contents of the\r
- specified section. The string should be\r
- interpreted by the client according to the content\r
- transfer encoding, body type, and subtype.\r
-\r
- 8-bit textual data is permitted if a character set\r
- identifier is part of the body parameter\r
- parenthesized list for this section.\r
-\r
- Non-textual data such as binary data must be\r
- transfer encoded into a textual form such as BASE64\r
- prior to being sent to the client. To derive the\r
-\r
-\r
-\r
-Crispin [Page 46]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- original binary data, the client must decode the\r
- transfer encoded string.\r
-\r
- BODYSTRUCTURE A parenthesized list that describes the body\r
- structure of a message. This is computed by the\r
- server by parsing the [RFC-822] header and body\r
- into the component parts, defaulting various fields\r
- as necessary.\r
-\r
- Multiple parts are indicated by parenthesis\r
- nesting. Instead of a body type as the first\r
- element of the parenthesized list there is a nested\r
- body. The second element of the parenthesized list\r
- is the multipart subtype (mixed, digest, parallel,\r
- alternative, etc.).\r
-\r
- Extension data follows the multipart subtype.\r
- Extension data is never returned with the BODY\r
- fetch, but may be returned with a BODYSTRUCTURE\r
- fetch. Extension data, if present, must be in the\r
- defined order.\r
-\r
- The extension data of a multipart body part are in\r
- the following order:\r
-\r
- body parameter parenthesized list\r
- A parenthesized list of attribute/value pairs\r
- [e.g. (foo bar baz rag) where "bar" is the value\r
- of "foo" and "rag" is the value of "baz"] as\r
- defined in [MIME-1].\r
-\r
- Any following extension data are not yet defined in\r
- this version of the protocol. Such extension data\r
- may consist of zero or more NILs, strings, numbers,\r
- or potentially nested parenthesized lists of such\r
- data. Client implementations that do a\r
- BODYSTRUCTURE fetch MUST be prepared to accept such\r
- extension data. Server implementations MUST NOT\r
- send such extension data until it has been defined\r
- by a revision of this protocol.\r
-\r
- The basic fields of a non-multipart body part are\r
- in the following order:\r
-\r
- body type\r
- A string giving the content type name as defined\r
- in [MIME-1].\r
-\r
-\r
-\r
-\r
-Crispin [Page 47]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- body subtype\r
- A string giving the content subtype name as\r
- defined in [MIME-1].\r
-\r
- body parameter parenthesized list\r
- A parenthesized list of attribute/value pairs\r
- [e.g. (foo bar baz rag) where "bar" is the value\r
- of "foo" and "rag" is the value of "baz"] as\r
- defined in [MIME-1].\r
-\r
- body id\r
- A string giving the content id as defined in\r
- [MIME-1].\r
-\r
- body description\r
- A string giving the content description as\r
- defined in [MIME-1].\r
-\r
- body encoding\r
- A string giving the content transfer encoding as\r
- defined in [MIME-1].\r
-\r
- body size\r
- A number giving the size of the body in octets.\r
- Note that this size is the size in its transfer\r
- encoding and not the resulting size after any\r
- decoding.\r
-\r
- A body type of type MESSAGE and subtype RFC822\r
- contains, immediately after the basic fields, the\r
- envelope structure, body structure, and size in\r
- text lines of the encapsulated message.\r
-\r
- A body type of type TEXT contains, immediately\r
- after the basic fields, the size of the body in\r
- text lines. Note that this size is the size in its\r
- transfer encoding and not the resulting size after\r
- any decoding.\r
-\r
- Extension data follows the basic fields and the\r
- type-specific fields listed above. Extension data\r
- is never returned with the BODY fetch, but may be\r
- returned with a BODYSTRUCTURE fetch. Extension\r
- data, if present, must be in the defined order.\r
-\r
- The extension data of a non-multipart body part are\r
- in the following order:\r
-\r
-\r
-\r
-\r
-Crispin [Page 48]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- body MD5\r
- A string giving the content MD5 value as defined\r
- in [MIME-1].\r
-\r
- Any following extension data are not yet defined in\r
- this version of the protocol, and would be as\r
- described above under multipart extension data.\r
-\r
- ENVELOPE A parenthesized list that describes the envelope\r
- structure of a message. This is computed by the\r
- server by parsing the [RFC-822] header into the\r
- component parts, defaulting various fields as\r
- necessary.\r
-\r
- The fields of the envelope structure are in the\r
- following order: date, subject, from, sender,\r
- reply-to, to, cc, bcc, in-reply-to, and message-id.\r
- The date, subject, in-reply-to, and message-id\r
- fields are strings. The from, sender, reply-to,\r
- to, cc, and bcc fields are parenthesized lists of\r
- address structures.\r
-\r
- An address structure is a parenthesized list that\r
- describes an electronic mail address. The fields\r
- of an address structure are in the following order:\r
- personal name, [SMTP] at-domain-list (source\r
- route), mailbox name, and host name.\r
-\r
- [RFC-822] group syntax is indicated by a special\r
- form of address structure in which the host name\r
- field is NIL. If the mailbox name field is also\r
- NIL, this is an end of group marker (semi-colon in\r
- RFC 822 syntax). If the mailbox name field is\r
- non-NIL, this is a start of group marker, and the\r
- mailbox name field holds the group name phrase.\r
-\r
- Any field of an envelope or address structure that\r
- is not applicable is presented as NIL. Note that\r
- the server must default the reply-to and sender\r
- fields from the from field; a client is not\r
- expected to know to do this.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 49]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- FLAGS A parenthesized list of flags that are set for this\r
- message. This may include keywords as well as the\r
- following system flags:\r
-\r
- \Seen Message has been read\r
-\r
- \Answered Message has been answered\r
-\r
- \Flagged Message is "flagged" for urgent/special\r
- attention\r
-\r
- \Deleted Message is "deleted" for removal by\r
- later EXPUNGE\r
-\r
- \Draft Message has not completed composition\r
- (marked as a draft).\r
-\r
- as well as the following special flag, which may be\r
- fetched but not stored:\r
-\r
- \Recent Message has arrived since the previous\r
- time this mailbox was selected.\r
-\r
- INTERNALDATE A string containing the date and time of final\r
- delivery of the message as defined by [SMTP].\r
-\r
- RFC822 A string expressing the message in [RFC-822]\r
- format. The header portion of the message must be\r
- 7-bit. 8-bit characters are permitted only in the\r
- non-header portion of the message only if there are\r
- [MIME-1] data in the message that identify the\r
- character set of the message.\r
-\r
- RFC822.HEADER A string expressing the [RFC-822] format header of\r
- the message, including the delimiting blank line\r
- between the header and the body. The entire string\r
- must be 7-bit; 8-bit characters are not permitted\r
- in headers. RFC822.HEADER is used to return data\r
- for the RFC822.HEADER, RFC822.HEADER.LINES, and\r
- RFC822.HEADER.LINES.NOT FETCH data items. Note\r
- that a blank line is always included regardless of\r
- header line restrictions.\r
-\r
- RFC822.SIZE A number expressing the number of octets in the\r
- message in [RFC-822] format.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 50]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- RFC822.TEXT A string expressing the text body of the message,\r
- omitting the [RFC-822] header. 8-bit characters\r
- are permitted only if there are [MIME-1] data in\r
- the message that identify the character set of the\r
- message.\r
-\r
- UID A number expressing the unique identifier of the\r
- message.\r
-\r
-\r
- Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)\r
-\r
-\r
-7.3.5. Obsolete Responses\r
-\r
- In addition to the responses listed in here, client implementations\r
- MUST accept and implement the obsolete responses described in\r
- Appendix B.\r
-\r
-\r
-\r
-7.4. Server Responses - Command Continuation Request\r
-\r
- The command completion request response is indicated by a "+" token\r
- instead of a tag. This form of response indicates that the server is\r
- ready to accept the continuation of a command from the client. The\r
- remainder of this response is a line of text.\r
-\r
- This response is used in the AUTHORIZATION command to transmit server\r
- data to the client, and request additional client data. This\r
- response is also used if an argument to any command is a literal.\r
-\r
- The client is not permitted to send the octets of the literal unless\r
- the server indicates that it expects it. This permits the server to\r
- process commands and reject errors on a line-by-line basis. The\r
- remainder of the command, including the CRLF that terminates a\r
- command, follows the octets of the literal. If there are any\r
- additional command arguments the literal octets are followed by a\r
- space and those arguments.\r
-\r
- Example: C: A001 LOGIN {11}\r
- S: + Ready for additional command text\r
- C: FRED FOOBAR {7}\r
- S: + Ready for additional command text\r
- C: fat man\r
- S: A001 OK LOGIN completed\r
- C: A044 BLURDYBLOOP {102856}\r
- S: A044 BAD No such command as "BLURDYBLOOP"\r
-\r
-\r
-\r
-Crispin [Page 51]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-8. Sample IMAP4 session\r
-\r
- The following is a transcript of an IMAP4 session. A long line in\r
- this sample is broken for editorial clarity.\r
-\r
- S: * OK IMAP4 Service Ready\r
- C: a001 login mrc secret\r
- S: a001 OK LOGIN completed\r
- C: a002 select inbox\r
- S: * 18 EXISTS\r
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)\r
- S: * 2 RECENT\r
- S: * OK [UNSEEN 17] Message 17 is the first unseen message\r
- S: * OK [UIDVALIDITY 3857529045] UIDs valid\r
- S: a002 OK [READ-WRITE] SELECT completed\r
- C: a003 fetch 12 full\r
- S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"\r
- RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"\r
- "IMAP4 WG mtg summary and minutes"\r
- (("Terry Gray" NIL "gray" "cac.washington.edu"))\r
- (("Terry Gray" NIL "gray" "cac.washington.edu"))\r
- (("Terry Gray" NIL "gray" "cac.washington.edu"))\r
- ((NIL NIL "imap" "cac.washington.edu"))\r
- ((NIL NIL "minutes" "CNRI.Reston.VA.US")\r
- ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL\r
- "<B27397-0100000@cac.washington.edu>")\r
- BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))\r
- S: a003 OK FETCH completed\r
- C: a004 fetch 12 rfc822.header\r
- S: * 12 FETCH (RFC822.HEADER {346}\r
- S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)\r
- S: From: Terry Gray <gray@cac.washington.edu>\r
- S: Subject: IMAP4 WG mtg summary and minutes\r
- S: To: imap@cac.washington.edu\r
- S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>\r
- S: Message-Id: <B27397-0100000@cac.washington.edu>\r
- S: MIME-Version: 1.0\r
- S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII\r
- S:\r
- S: )\r
- S: a004 OK FETCH completed\r
- C: a005 store 12 +flags \deleted\r
- S: * 12 FETCH (FLAGS (\Seen \Deleted))\r
- S: a005 OK +FLAGS completed\r
- C: a006 logout\r
- S: * BYE IMAP4 server terminating connection\r
- S: a006 OK LOGOUT completed\r
-\r
-\r
-\r
-\r
-Crispin [Page 52]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-9. Formal Syntax\r
-\r
- The following syntax specification uses the augmented Backus-Naur\r
- Form (BNF) notation as specified in [RFC-822] with one exception; the\r
- delimiter used with the "#" construct is a single space (SPACE) and\r
- not a comma.\r
-\r
- Except as noted otherwise, all alphabetic characters are\r
- case-insensitive. The use of upper or lower case characters to\r
- define token strings is for editorial clarity only. Implementations\r
- MUST accept these strings in a case-insensitive fashion.\r
-\r
- Syntax marked as obsolete may be encountered with implementations\r
- written for an earlier version of this protocol (e.g. IMAP2). New\r
- implementations SHOULD accept obsolete syntax as input, but MUST NOT\r
- otherwise use such syntax.\r
-\r
- address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox\r
- SPACE addr_host ")"\r
-\r
- addr_adl ::= nstring\r
-\r
- addr_host ::= nstring\r
- ;; NIL indicates [RFC-822] group syntax\r
-\r
- addr_mailbox ::= nstring\r
- ;; NIL indicates end of [RFC-822] group; if\r
- ;; non-NIL and addr_host is NIL, holds\r
- ;; [RFC-822] group name\r
-\r
- addr_name ::= nstring\r
-\r
- alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /\r
- "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /\r
- "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /\r
- "Y" / "Z" /\r
- "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /\r
- "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /\r
- "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /\r
- "y" / "z" /\r
- ;; Case-sensitive\r
-\r
- append ::= "APPEND" SPACE mailbox [SPACE flag_list]\r
- [SPACE date_time] SPACE literal\r
-\r
- astring ::= atom / string\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 53]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- atom ::= 1*ATOM_CHAR\r
-\r
- ATOM_CHAR ::= <any CHAR except atom_specials>\r
-\r
- atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /\r
- quoted_specials\r
-\r
- authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)\r
-\r
- auth_type ::= atom\r
-\r
- base64 ::= *(4base64_char) [base64_terminal]\r
-\r
- base64_char ::= alpha / digit / "+" / "/"\r
-\r
- base64_terminal ::= (2base64_char "==") / (3base64_char "=")\r
-\r
- body ::= "(" body_type_1part / body_type_mpart ")"\r
-\r
- body_extension ::= nstring / number / "(" 1#body_extension ")"\r
- ;; Future expansion. Client implementations\r
- ;; MUST accept body_extension fields. Server\r
- ;; implementations MUST NOT generate\r
- ;; body_extension fields except as defined by\r
- ;; future standard or standards-track\r
- ;; revisions of this specification.\r
-\r
- body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension]\r
- ;; MUST NOT be returned on non-extensible\r
- ;; "BODY" fetch\r
-\r
- body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]]\r
- ;; MUST NOT be returned on non-extensible\r
- ;; "BODY" fetch\r
-\r
- body_fields ::= body_fld_param SPACE body_fld_id SPACE\r
- body_fld_desc SPACE body_fld_enc SPACE\r
- body_fld_octets\r
-\r
- body_fld_desc ::= nstring\r
-\r
- body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/\r
- "QUOTED-PRINTABLE") <">) / string\r
-\r
- body_fld_id ::= nstring\r
-\r
- body_fld_lines ::= number\r
-\r
-\r
-\r
-\r
-Crispin [Page 54]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- body_fld_md5 ::= nstring\r
-\r
- body_fld_octets ::= number\r
-\r
- body_fld_param ::= "(" 1#(string string) ")" / nil\r
-\r
- body_fld_subtyp ::= string\r
-\r
- body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)\r
- [SPACE body_ext_1part]\r
-\r
- body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /\r
- "MESSAGE" / "VIDEO") <">) / string) SPACE\r
- body_fld_subtyp SPACE body_fields\r
- ;; MESSAGE subtype MUST NOT be "RFC822"\r
-\r
- body_type_mpart ::= 1*body SPACE body_fld_subtyp\r
- [SPACE body_ext_mpart]\r
-\r
- body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE\r
- body_fields SPACE envelope SPACE body SPACE\r
- body_fld_lines\r
-\r
- body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE\r
- body_fields SPACE body_fld_lines\r
-\r
- capability ::= atom\r
- ;; Must begin with "X" or be registered with\r
- ;; IANA as standard or standards-track\r
-\r
- capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]\r
-\r
- CHAR ::= <any 7-bit US-ASCII character except NUL,\r
- 0x01 - 0x7f>\r
-\r
- CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff>\r
-\r
- command ::= tag SPACE (command_any / command_auth /\r
- command_nonauth / command_select) CRLF\r
- ;; Modal based on state\r
-\r
- command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command\r
- ;; Valid in all states\r
-\r
- command_auth ::= append / create / delete / examine / find / list /\r
- lsub / rename / select / subscribe / unsubscribe /\r
- ;; Valid only in Authenticated or Selected state\r
-\r
-\r
-\r
-\r
-Crispin [Page 55]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- command_nonauth ::= login / authenticate\r
- ;; Valid only when in Non-Authenticated state\r
-\r
- command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /\r
- copy / fetch / partial / store / uid / search\r
- ;; Valid only when in Selected state\r
-\r
- continue_req ::= "+" SPACE (resp_text / base64)\r
-\r
- copy ::= "COPY" SPACE set SPACE mailbox\r
-\r
- CR ::= <ASCII CR, carriage return, 0x0C>\r
-\r
- create ::= "CREATE" SPACE mailbox\r
- ;; Use of INBOX gives a NO error\r
-\r
- CRLF ::= CR LF\r
-\r
- CTL ::= <any ASCII control character and DEL,\r
- 0x00 - 0x1f, 0x7f>\r
-\r
- date ::= date_text / <"> date_text <">\r
-\r
- date_day ::= 1*2digit\r
- ;; Day of month\r
-\r
- date_day_fixed ::= (SPACE digit) / 2digit\r
- ;; Fixed-format version of date_day\r
-\r
- date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /\r
- "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"\r
-\r
- date_text ::= date_day "-" date_month "-" (date_year /\r
- date_year_old)\r
-\r
- date_year ::= 4digit\r
-\r
- date_year_old ::= 2digit\r
- ;; OBSOLETE, (year - 1900)\r
-\r
- date_time ::= <"> (date_time_new / date_time_old) <">\r
-\r
- date_time_new ::= date_day_fixed "-" date_month "-" date_year\r
- SPACE time SPACE zone\r
-\r
- date_time_old ::= date_day_fixed "-" date_month "-" date_year_old\r
- SPACE time "-" zone_old\r
- ;; OBSOLETE\r
-\r
-\r
-\r
-Crispin [Page 56]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- delete ::= "DELETE" SPACE mailbox\r
- ;; Use of INBOX gives a NO error\r
-\r
- digit ::= "0" / digit_nz\r
-\r
- digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /\r
- "9"\r
-\r
- envelope ::= "(" env_date SPACE env_subject SPACE env_from\r
- SPACE env_sender SPACE env_reply-to SPACE env_to\r
- SPACE env_cc SPACE env_bcc SPACE env_in-reply-to\r
- SPACE env_message-id ")"\r
-\r
- env_bcc ::= "(" 1*address ")" / nil\r
-\r
- env_cc ::= "(" 1*address ")" / nil\r
-\r
- env_date ::= nstring\r
-\r
- env_from ::= "(" 1*address ")" / nil\r
-\r
- env_in-reply-to ::= nstring\r
-\r
- env_message-id ::= nstring\r
-\r
- env_reply-to ::= "(" 1*address ")" / nil\r
-\r
- env_sender ::= "(" 1*address ")" / nil\r
-\r
- env_subject ::= nstring\r
-\r
- env_to ::= "(" 1*address ")" / nil\r
-\r
- examine ::= "EXAMINE" SPACE mailbox\r
-\r
- fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /\r
- "FAST" / fetch_att / "(" 1#fetch_att ")")\r
-\r
- fetch_att ::= "BODY" / "BODYSTRUCTURE" /\r
- "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /\r
- "FLAGS" / "INTERNALDATE" / "UID" /\r
- "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /\r
- (".HEADER" [".LINES" [".NOT"] SPACE header_list])\r
-\r
- find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE\r
- list_mailbox\r
- ;; OBSOLETE\r
-\r
-\r
-\r
-\r
-Crispin [Page 57]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- flag ::= "\Answered" / "\Flagged" / "\Deleted" /\r
- "\Seen" / "\Draft" / flag_keyword /\r
- flag_extension\r
-\r
- flag_extension ::= "\" atom\r
- ;; Future expansion. Client implementations\r
- ;; MUST accept flag_extension flags. Server\r
- ;; implementations MUST NOT generate\r
- ;; flag_extension flags except as defined by\r
- ;; future standard or standards-track\r
- ;; revisions of this specification.\r
-\r
- flag_keyword ::= atom\r
-\r
- flag_list ::= "(" #flag ")"\r
-\r
- greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF\r
-\r
- header_line ::= astring\r
-\r
- header_list ::= "(" 1#header_line ")"\r
-\r
- LF ::= <ASCII LF, line feed, 0x0A>\r
-\r
- list ::= "LIST" SPACE mailbox SPACE list_mailbox\r
-\r
- list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string\r
-\r
- list_wildcards ::= "%" / "*"\r
-\r
- literal ::= "{" number "}" CRLF *CHAR8\r
- ;; Number represents the number of CHAR8 octets\r
-\r
- login ::= "LOGIN" SPACE userid SPACE password\r
-\r
- lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox\r
-\r
- mailbox ::= "INBOX" / astring\r
- ;; INBOX is case-insensitive; other names may be\r
- ;; case-sensitive depending on implementation.\r
-\r
- mailbox_data ::= "FLAGS" SPACE flag_list /\r
- "LIST" SPACE mailbox_list /\r
- "LSUB" SPACE mailbox_list /\r
- "MAILBOX" SPACE text /\r
- "SEARCH" [SPACE 1#nz_number] /\r
- number SPACE "EXISTS" / number SPACE "RECENT"\r
-\r
-\r
-\r
-\r
-Crispin [Page 58]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /\r
- "\Noselect" / "\Unmarked" / flag_extension) ")"\r
- SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox\r
-\r
- message_data ::= nz_number SPACE ("EXPUNGE" /\r
- ("FETCH" SPACE msg_fetch) / msg_obsolete)\r
-\r
- msg_fetch ::= "(" 1#("BODY" SPACE body /\r
- "BODYSTRUCTURE" SPACE body /\r
- "BODY[" section "]" SPACE nstring /\r
- "ENVELOPE" SPACE envelope /\r
- "FLAGS" SPACE "(" #(flag / "\Recent") ")" /\r
- "INTERNALDATE" SPACE date_time /\r
- "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /\r
- "RFC822.SIZE" SPACE number /\r
- "UID" SPACE uniqueid) ")"\r
-\r
- msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch)\r
- ;; OBSOLETE untagged data responses\r
-\r
- nil ::= "NIL"\r
-\r
- nstring ::= string / nil\r
-\r
- number ::= 1*digit\r
- ;; Unsigned 32-bit integer\r
- ;; (0 <= n < 4,294,967,296)\r
-\r
- nz_number ::= digit_nz *digit\r
- ;; Non-zero unsigned 32-bit integer\r
- ;; (0 < n < 4,294,967,296)\r
-\r
- partial ::= "PARTIAL" SPACE nz_number SPACE\r
- ("BODY" [".PEEK"] "[" section "]" /\r
- "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")\r
- SPACE number SPACE number\r
-\r
- password ::= astring\r
-\r
- quoted ::= <"> *QUOTED_CHAR <">\r
-\r
- QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> /\r
- "\" quoted_specials\r
-\r
- quoted_specials ::= <"> / "\"\r
-\r
- rename ::= "RENAME" SPACE mailbox SPACE mailbox\r
- ;; Use of INBOX as a destination gives a NO error\r
-\r
-\r
-\r
-Crispin [Page 59]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- response ::= *response_data response_done\r
-\r
- response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /\r
- mailbox_data / message_data / capability_data)\r
- CRLF\r
-\r
- response_done ::= response_tagged / response_fatal\r
-\r
- response_fatal ::= "*" SPACE resp_cond_bye CRLF\r
-\r
- response_tagged ::= tag SPACE resp_cond_state CRLF\r
-\r
- resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text\r
- ;; Authentication condition\r
-\r
- resp_cond_bye ::= "BYE" SPACE resp_text\r
- ;; Server will disconnect condition\r
-\r
- resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text\r
- ;; Status condition\r
-\r
- resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)\r
-\r
- resp_text_code ::= "ALERT" / "PARSE" /\r
- "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /\r
- "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /\r
- "UIDVALIDITY" SPACE nz_number /\r
- "UNSEEN" SPACE nz_number /\r
- atom [SPACE 1*<any TEXT_CHAR except "]">]\r
-\r
- search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]\r
- search_criteria\r
- ;; Character set must be registered with IANA\r
- ;; as a MIME character set\r
-\r
- search_criteria ::= 1#search_key\r
-\r
- search_key ::= search_new / search_old\r
-\r
- search_new ::= "DRAFT" /\r
- "HEADER" SPACE header_line SPACE astring /\r
- "LARGER" SPACE number / "NOT" SPACE search_key /\r
- "OR" SPACE search_key SPACE search_key /\r
- "SENTBEFORE" SPACE date / "SENTON" SPACE date /\r
- "SENTSINCE" SPACE date / "SMALLER" SPACE number /\r
- "UID" SPACE set / "UNDRAFT" / set /\r
- "(" search_criteria ")"\r
- ;; New in IMAP4\r
-\r
-\r
-\r
-Crispin [Page 60]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /\r
- "BEFORE" SPACE date / "BODY" SPACE astring /\r
- "CC" SPACE astring / "DELETED" / "FLAGGED" /\r
- "FROM" SPACE astring /\r
- "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /\r
- "ON" SPACE date / "RECENT" / "SEEN" /\r
- "SINCE" SPACE date / "SUBJECT" SPACE astring /\r
- "TEXT" SPACE astring / "TO" SPACE astring /\r
- "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /\r
- "UNKEYWORD" SPACE flag_keyword / "UNSEEN"\r
- ;; Defined in [IMAP2]\r
-\r
- section ::= "0" / nz_number ["." section]\r
-\r
- select ::= "SELECT" SPACE mailbox\r
-\r
- sequence_num ::= nz_number / "*"\r
- ;; * is the largest number in use. For message\r
- ;; sequence numbers, it is the number of messages\r
- ;; in the mailbox. For unique identifiers, it is\r
- ;; the unique identifier of the last message in\r
- ;; the mailbox.\r
-\r
- set ::= sequence_num / (sequence_num ":" sequence_num) /\r
- (set "," set)\r
- ;; Identifies a set of messages. For message\r
- ;; sequence numbers, these are consecutive\r
- ;; numbers from 1 to the number of messages in\r
- ;; the mailbox\r
- ;; Comma delimits individual numbers, colon\r
- ;; delimits between two numbers inclusive.\r
- ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,\r
- ;; 14,15 for a mailbox with 15 messages.\r
-\r
- SPACE ::= <ASCII SP, space, 0x20>\r
-\r
- store ::= "STORE" SPACE set SPACE store_att_flags\r
-\r
- store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE\r
- (flag_list / #flag)\r
-\r
- string ::= quoted / literal\r
-\r
- subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs\r
-\r
- subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox\r
- ;;OBSOLETE\r
-\r
-\r
-\r
-\r
-Crispin [Page 61]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- tag ::= 1*<any ATOM_CHAR except "+">\r
-\r
- text ::= 1*TEXT_CHAR\r
-\r
- text_mime2 ::= "=?" <charset> "?" <encoding> "?"\r
- <encoded-text> "?="\r
- ;; Syntax defined in [MIME-2]\r
-\r
- TEXT_CHAR ::= <any CHAR except CR and LF>\r
-\r
- time ::= 2digit ":" 2digit ":" 2digit\r
- ;; Hours minutes seconds\r
-\r
- uid ::= "UID" SPACE (copy / fetch / search / store)\r
- ;; Unique identifiers used instead of message\r
- ;; sequence numbers\r
-\r
- uniqueid ::= nz_number\r
- ;; Strictly ascending\r
-\r
- unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs\r
-\r
- unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox\r
- ;;OBSOLETE\r
-\r
- userid ::= astring\r
-\r
- x_command ::= "X" atom <experimental command arguments>\r
-\r
- zone ::= ("+" / "-") 4digit\r
- ;; Signed four-digit value of hhmm representing\r
- ;; hours and minutes west of Greenwich (that is,\r
- ;; (the amount that the given time differs from\r
- ;; Universal Time). Subtracting the timezone\r
- ;; from the given time will give the UT form.\r
- ;; The Universal Time zone is "+0000".\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 62]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- zone_old ::= "UT" / "GMT" / "Z" / ;; +0000\r
- "AST" / "EDT" / ;; -0400\r
- "EST" / "CDT" / ;; -0500\r
- "CST" / "MDT" / ;; -0600\r
- "MST" / "PDT" / ;; -0700\r
- "PST" / "YDT" / ;; -0800\r
- "YST" / "HDT" / ;; -0900\r
- "HST" / "BDT" / ;; -1000\r
- "BST" / ;; -1100\r
- "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6\r
- "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12\r
- "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6\r
- "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12\r
- ;; OBSOLETE\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 63]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-10. Author's Note\r
-\r
- This document is a revision or rewrite of earlier documents, and\r
- supercedes the protocol specification in those documents: IMAP4\r
- Internet drafts, the IMAP2bis Internet drafts, unpublished\r
- IMAP2bis.TXT document, RFC 1176, and RFC 1064.\r
-\r
-\r
-11. Security Considerations\r
-\r
- IMAP4 protocol transactions, including electronic mail data, are sent\r
- in the clear over the network unless the optional privacy protection\r
- is negotiated in the AUTHENTICATE command.\r
-\r
- A server error message for an AUTHENTICATE command which fails due to\r
- invalid credentials should not detail why the credentials are\r
- invalid.\r
-\r
- Use of the LOGIN command sends passwords in the clear. This can be\r
- avoided by using the AUTHENTICATE command instead.\r
-\r
- A server error message for a failing LOGIN command should not specify\r
- that the user name, as opposed to the password, is invalid.\r
-\r
- Additional security considerations are discussed in the section\r
- discussing the AUTHENTICATE and LOGIN commands.\r
-\r
-\r
-12. Author's Address\r
-\r
- Mark R. Crispin\r
- Networks and Distributed Computing, JE-30\r
- University of Washington\r
- Seattle, WA 98195\r
-\r
- Phone: (206) 543-5762\r
-\r
- EMail: MRC@CAC.Washington.EDU\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 64]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-Appendices\r
-\r
-A. Obsolete Commands\r
-\r
- The following commands are OBSOLETE. It is NOT required to support\r
- any of these commands in new server implementations. These commands\r
- are documented here for the benefit of implementors who may wish to\r
- support them for compatibility with old client implementations.\r
-\r
- The section headings of these commands are intended to correspond\r
- with where they would be located in the main document if they were\r
- not obsoleted.\r
-\r
-\r
-A.6.3.OBS.1. FIND ALL.MAILBOXES Command\r
-\r
- Arguments: mailbox name with possible wildcards\r
-\r
- Data: untagged responses: MAILBOX\r
-\r
- Result: OK - find completed\r
- NO - find failure: can't list that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The FIND ALL.MAILBOXES command returns a subset of names from the\r
- complete set of all names available to the user. It returns zero\r
- or more untagged MAILBOX replies. The mailbox argument to FIND\r
- ALL.MAILBOXES is similar to that for LIST with an empty reference,\r
- except that the characters "%" and "?" match a single character.\r
-\r
- Example: C: A002 FIND ALL.MAILBOXES *\r
- S: * MAILBOX blurdybloop\r
- S: * MAILBOX INBOX\r
- S: A002 OK FIND ALL.MAILBOXES completed\r
-\r
-\r
-A.6.3.OBS.2. FIND MAILBOXES Command\r
-\r
- Arguments: mailbox name with possible wildcards\r
-\r
- Data: untagged responses: MAILBOX\r
-\r
- Result: OK - find completed\r
- NO - find failure: can't list that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The FIND MAILBOXES command returns a subset of names from the set\r
- of names that the user has declared as being "active" or\r
-\r
-\r
-\r
-Crispin [Page 65]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- "subscribed". It returns zero or more untagged MAILBOX replies.\r
- The mailbox argument to FIND MAILBOXES is similar to that for LSUB\r
- with an empty reference, except that the characters "%" and "?"\r
- match a single character.\r
-\r
- Example: C: A002 FIND MAILBOXES *\r
- S: * MAILBOX blurdybloop\r
- S: * MAILBOX INBOX\r
- S: A002 OK FIND MAILBOXES completed\r
-\r
-\r
-A.6.3.OBS.3. SUBSCRIBE MAILBOX Command\r
-\r
- Arguments: mailbox name\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - subscribe completed\r
- NO - subscribe failure: can't subscribe to that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The SUBSCRIBE MAILBOX command is identical in effect to the\r
- SUBSCRIBE command. A server which implements this command must be\r
- able to distinguish between a SUBSCRIBE MAILBOX command and a\r
- SUBSCRIBE command with a mailbox name argument of "MAILBOX".\r
-\r
- Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime\r
- S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime\r
- completed\r
- C: A003 SUBSCRIBE MAILBOX\r
- S: A003 OK SUBSCRIBE to MAILBOX completed\r
-\r
-\r
-A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command\r
-\r
- Arguments: mailbox name\r
-\r
- Data: no specific data for this command\r
-\r
- Result: OK - unsubscribe completed\r
- NO - unsubscribe failure: can't unsubscribe that name\r
- BAD - command unknown or arguments invalid\r
-\r
- The UNSUBSCRIBE MAILBOX command is identical in effect to the\r
- UNSUBSCRIBE command. A server which implements this command must\r
- be able to distinguish between a UNSUBSCRIBE MAILBOX command and\r
- an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".\r
-\r
-\r
-\r
-\r
-Crispin [Page 66]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
- Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime\r
- S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime\r
- completed\r
- C: A003 UNSUBSCRIBE MAILBOX\r
- S: A003 OK UNSUBSCRIBE from MAILBOX completed\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 67]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-B. Obsolete Responses\r
-\r
- The following responses are OBSOLETE. Except as noted below, these\r
- responses MUST NOT be transmitted by new server implementations.\r
-\r
- The section headings of these responses are intended to correspond\r
- with where they would be located in the main document if they were\r
- not obsoleted.\r
-\r
-\r
-B.7.2.OBS.1. MAILBOX Response\r
-\r
- Data: name\r
-\r
- The MAILBOX response MUST NOT be transmitted by server\r
- implementations except in response to the obsolete FIND MAILBOXES\r
- and FIND ALL.MAILBOXES commands. Client implementations that do\r
- not use these commands MAY ignore this response. It is documented\r
- here for the benefit of implementors who may wish to support it\r
- for compatibility with old client implementations.\r
-\r
- This response occurs as a result of the FIND MAILBOXES and FIND\r
- ALL.MAILBOXES commands. It returns a single name that matches the\r
- FIND specification. There are no attributes or hierarchy\r
- delimiter.\r
-\r
- Example: S: * MAILBOX blurdybloop\r
-\r
-\r
-B.7.3.OBS.1. COPY Response\r
-\r
- Data: none\r
-\r
- The COPY response MUST NOT be transmitted by new server\r
- implementations. Client implementations MUST ignore the COPY\r
- response. It is documented here for the benefit of client\r
- implementors who may encounter this response from old server\r
- implementations.\r
-\r
- In some experimental versions of this protocol, this response was\r
- returned in response to a COPY command to indicate on a\r
- per-message basis that the message was copied successfully.\r
-\r
- Example: S: * 44 COPY\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 68]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-B.7.3.OBS.2. STORE Response\r
-\r
- Data: message data\r
-\r
- The STORE response MUST NOT be transmitted by new server\r
- implementations. Client implementations MUST treat the STORE\r
- response as equivalent to the FETCH response. It is documented\r
- here for the benefit of client implementors who may encounter this\r
- response from old server implementations.\r
-\r
- In some experimental versions of this protocol, this response was\r
- returned instead of FETCH in response to a STORE command to report\r
- the new value of the flags.\r
-\r
- Example: S: * 69 STORE (FLAGS (\Deleted))\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 69]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-C. References\r
-\r
-\r
- [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.\r
- Carnegie-Mellon University, December 1994.\r
-\r
- [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and\r
- IMAP2bis", RFC 1732, University of Washington, December 1994.\r
-\r
- [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected\r
- IMAP4 Clients", Work in Progress.\r
-\r
- [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in\r
- IMAP4", RFC 1733, University of Washington, December 1994.\r
-\r
- [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work\r
- in Progress.\r
-\r
- [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",\r
- RFC 1176, University of Washington, August 1990.\r
-\r
- [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in\r
- Progress.\r
-\r
- [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet\r
- Mail Extensions) Part One: Mechanisms for Specifying and Describing\r
- the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,\r
- September 1993.\r
-\r
- [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)\r
- Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,\r
- University of Tennessee, September 1993.\r
-\r
- [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text\r
- Messages", STD 11, RFC 822, University of Delaware, August 1982.\r
-\r
- [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,\r
- RFC 821, USC/Information Sciences Institute, August 1982.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 70]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-E. IMAP4 Keyword Index\r
-\r
-\r
- +FLAGS <flag list> (store command data item) ............... 34\r
- +FLAGS.SILENT <flag list> (store command data item) ........ 34\r
- -FLAGS <flag list> (store command data item) ............... 34\r
- -FLAGS.SILENT <flag list> (store command data item) ........ 34\r
- ALERT (response code) ...................................... 39\r
- ALL (fetch item) ........................................... 29\r
- ALL (search key) ........................................... 27\r
- ANSWERED (search key) ...................................... 27\r
- APPEND (command) ........................................... 22\r
- AUTHENTICATE (command) ..................................... 12\r
- BAD (response) ............................................. 41\r
- BCC <string> (search key) .................................. 27\r
- BEFORE <date> (search key) ................................. 27\r
- BODY (fetch item) .......................................... 29\r
- BODY (fetch result) ........................................ 46\r
- BODY <string> (search key) ................................. 27\r
- BODY.PEEK[<section>] (fetch item) .......................... 30\r
- BODYSTRUCTURE (fetch item) ................................. 31\r
- BODYSTRUCTURE (fetch result) ............................... 47\r
- BODY[<section>] (fetch item) ............................... 29\r
- BODY[section] (fetch result) ............................... 46\r
- BYE (response) ............................................. 41\r
- CAPABILITY (command) ....................................... 10\r
- CAPABILITY (response) ...................................... 42\r
- CC <string> (search key) ................................... 27\r
- CHECK (command) ............................................ 23\r
- CLOSE (command) ............................................ 24\r
- COPY (command) ............................................. 34\r
- COPY (response) ............................................ 68\r
- CREATE (command) ........................................... 17\r
- DELETE (command) ........................................... 18\r
- DELETED (search key) ....................................... 27\r
- DRAFT (search key) ......................................... 27\r
- ENVELOPE (fetch item) ...................................... 31\r
- ENVELOPE (fetch result) .................................... 49\r
- EXAMINE (command) .......................................... 16\r
- EXISTS (response) .......................................... 45\r
- EXPUNGE (command) .......................................... 25\r
- EXPUNGE (response) ......................................... 45\r
- FAST (fetch item) .......................................... 31\r
- FETCH (command) ............................................ 29\r
- FETCH (response) ........................................... 46\r
- FIND ALL.MAILBOXES (command) ............................... 65\r
- FIND MAILBOXES (command) ................................... 65\r
- FLAGGED (search key) ....................................... 27\r
- FLAGS (fetch item) ......................................... 31\r
-\r
-\r
-\r
-Crispin [Page 71]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-\r
- FLAGS (fetch result) ....................................... 50\r
- FLAGS (response) ........................................... 44\r
- FLAGS <flag list> (store command data item) ................ 34\r
- FLAGS.SILENT <flag list> (store command data item) ......... 34\r
- FROM <string> (search key) ................................. 27\r
- FULL (fetch item) .......................................... 31\r
- HEADER <field-name> <string> (search key) .................. 27\r
- INTERNALDATE (fetch item) .................................. 31\r
- INTERNALDATE (fetch result) ................................ 50\r
- KEYWORD <flag> (search key) ................................ 27\r
- LARGER <n> (search key) .................................... 27\r
- LIST (command) ............................................. 20\r
- LIST (response) ............................................ 43\r
- LOGIN (command) ............................................ 14\r
- LOGOUT (command) ........................................... 11\r
- LSUB (command) ............................................. 22\r
- LSUB (response) ............................................ 44\r
- MAILBOX (response) ......................................... 68\r
- NEW (search key) ........................................... 27\r
- NO (response) .............................................. 40\r
- NOOP (command) ............................................. 11\r
- NOT <search-key> (search key) .............................. 28\r
- OK (response) .............................................. 40\r
- OLD (search key) ........................................... 28\r
- ON <date> (search key) ..................................... 28\r
- OR <search-key1> <search-key2> (search key) ................ 28\r
- PARSE (response code) ...................................... 39\r
- PARTIAL (command) .......................................... 32\r
- PERMANENTFLAGS (response code) ............................. 39\r
- PREAUTH (response) ......................................... 41\r
- READ-ONLY (response code) .................................. 39\r
- READ-WRITE (response code) ................................. 39\r
- RECENT (response) .......................................... 45\r
- RECENT (search key) ........................................ 28\r
- RENAME (command) ........................................... 18\r
- RFC822 (fetch item) ........................................ 31\r
- RFC822 (fetch result) ...................................... 50\r
- RFC822.HEADER (fetch item) ................................. 31\r
- RFC822.HEADER (fetch result) ............................... 50\r
- RFC822.HEADER.LINES <header_list> (fetch item) ............. 31\r
- RFC822.HEADER.LINES.NOT <header_list> (fetch item) ......... 32\r
- RFC822.PEEK (fetch item) ................................... 31\r
- RFC822.SIZE (fetch item) ................................... 32\r
- RFC822.SIZE (fetch result) ................................. 50\r
- RFC822.TEXT (fetch item) ................................... 32\r
- RFC822.TEXT (fetch result) ................................. 51\r
- RFC822.TEXT.PEEK (fetch item) .............................. 32\r
- SEARCH (command) ........................................... 25\r
-\r
-\r
-\r
-Crispin [Page 72]\r
-\f\r
-RFC 1730 IMAP4 December 1994\r
-\r
-\r
-\r
- SEARCH (response) .......................................... 44\r
- SEEN (search key) .......................................... 28\r
- SELECT (command) ........................................... 15\r
- SENTBEFORE <date> (search key) ............................. 28\r
- SENTON <date> (search key) ................................. 28\r
- SENTSINCE <date> (search key) .............................. 28\r
- SINCE <date> (search key) .................................. 28\r
- SMALLER <n> (search key) ................................... 28\r
- STORE (command) ............................................ 33\r
- STORE (response) ........................................... 69\r
- SUBJECT <string> (search key) .............................. 28\r
- SUBSCRIBE (command) ........................................ 19\r
- SUBSCRIBE MAILBOX (command) ................................ 66\r
- TEXT <string> (search key) ................................. 28\r
- TO <string> (search key) ................................... 28\r
- TRYCREATE (response code) .................................. 39\r
- UID (command) .............................................. 35\r
- UID (fetch item) ........................................... 32\r
- UID (fetch result) ......................................... 51\r
- UID <message set> (search key) ............................. 28\r
- UIDVALIDITY (response code) ................................ 40\r
- UNANSWERED (search key) .................................... 29\r
- UNDELETED (search key) ..................................... 29\r
- UNDRAFT (search key) ....................................... 29\r
- UNFLAGGED (search key) ..................................... 29\r
- UNKEYWORD <flag> (search key) .............................. 29\r
- UNSEEN (response code) ..................................... 40\r
- UNSEEN (search key) ........................................ 29\r
- UNSUBSCRIBE (command) ...................................... 19\r
- UNSUBSCRIBE MAILBOX (command) .............................. 66\r
- X<atom> (command) .......................................... 37\r
- \Answered (system flag) .................................... 50\r
- \Deleted (system flag) ..................................... 50\r
- \Draft (system flag) ....................................... 50\r
- \Flagged (system flag) ..................................... 50\r
- \Marked (mailbox name attribute) ........................... 43\r
- \Noinferiors (mailbox name attribute) ...................... 43\r
- \Noselect (mailbox name attribute) ......................... 43\r
- \Recent (system flag) ...................................... 50\r
- \Seen (system flag) ........................................ 50\r
- \Unmarked (mailbox name attribute) ......................... 43\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Crispin [Page 73]\r
-\f\r
+++ /dev/null
-\r
-\r
-\r
-\r
-\r
-\r
-Network Working Group J. Myers\r
-Request for Comments: 1731 Carnegie Mellon\r
-Category: Standards Track December 1994\r
-\r
-\r
- IMAP4 Authentication Mechanisms\r
-\r
-Status of this Memo\r
-\r
- This document specifies an Internet standards track protocol for the\r
- Internet community, and requests discussion and suggestions for\r
- improvements. Please refer to the current edition of the "Internet\r
- Official Protocol Standards" (STD 1) for the standardization state\r
- and status of this protocol. Distribution of this memo is unlimited.\r
-\r
-\r
-1. Introduction\r
-\r
- The Internet Message Access Protocol, Version 4 [IMAP4] contains the\r
- AUTHENTICATE command, for identifying and authenticating a user to an\r
- IMAP4 server and for optionally negotiating a protection mechanism\r
- for subsequent protocol interactions. This document describes\r
- several authentication mechanisms for use by the IMAP4 AUTHENTICATE\r
- command.\r
-\r
-\r
-2. Kerberos version 4 authentication mechanism\r
-\r
- The authentication type associated with Kerberos version 4 is\r
- "KERBEROS_V4".\r
-\r
- The data encoded in the first ready response contains a random 32-bit\r
- number in network byte order. The client should respond with a\r
- Kerberos ticket and an authenticator for the principal\r
- "imap.hostname@realm", where "hostname" is the first component of the\r
- host name of the server with all letters in lower case and where\r
- "realm" is the Kerberos realm of the server. The encrypted checksum\r
- field included within the Kerberos authenticator should contain the\r
- server provided 32-bit number in network byte order.\r
-\r
- Upon decrypting and verifying the ticket and authenticator, the\r
- server should verify that the contained checksum field equals the\r
- original server provided random 32-bit number. Should the\r
- verification be successful, the server must add one to the checksum\r
- and construct 8 octets of data, with the first four octets containing\r
- the incremented checksum in network byte order, the fifth octet\r
- containing a bit-mask specifying the protection mechanisms supported\r
- by the server, and the sixth through eighth octets containing, in\r
-\r
-\r
-\r
-Myers [Page 1]\r
-\f\r
-RFC 1731 IMAP4 Authentication Mechanisms December 1994\r
-\r
-\r
- network byte order, the maximum cipher-text buffer size the server is\r
- able to receive. The server must encrypt the 8 octets of data in the\r
- session key and issue that encrypted data in a second ready response.\r
- The client should consider the server authenticated if the first four\r
- octets the un-encrypted data is equal to one plus the checksum it\r
- previously sent.\r
-\r
- The client must construct data with the first four octets containing\r
- the original server-issued checksum in network byte order, the fifth\r
- octet containing the bit-mask specifying the selected protection\r
- mechanism, the sixth through eighth octets containing in network byte\r
- order the maximum cipher-text buffer size the client is able to\r
- receive, and the following octets containing a user name string. The\r
- client must then append from one to eight octets so that the length\r
- of the data is a multiple of eight octets. The client must then PCBC\r
- encrypt the data with the session key and respond to the second ready\r
- response with the encrypted data. The server decrypts the data and\r
- verifies the contained checksum. The username field identifies the\r
- user for whom subsequent IMAP operations are to be performed; the\r
- server must verify that the principal identified in the Kerberos\r
- ticket is authorized to connect as that user. After these\r
- verifications, the authentication process is complete.\r
-\r
- The protection mechanisms and their corresponding bit-masks are as\r
- follows:\r
-\r
- 1 No protection mechanism\r
- 2 Integrity (krb_mk_safe) protection\r
- 4 Privacy (krb_mk_priv) protection\r
-\r
-\r
- EXAMPLE: The following are two Kerberos version 4 login scenarios\r
- (note that the line breaks in the sample authenticators are for\r
- editorial clarity and are not in real authenticators)\r
-\r
- S: * OK IMAP4 Server\r
- C: A001 AUTHENTICATE KERBEROS_V4\r
- S: + AmFYig==\r
- C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT\r
- +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd\r
- WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh\r
- S: + or//EoAADZI=\r
- C: DiAF5A4gA+oOIALuBkAAmw==\r
- S: A001 OK Kerberos V4 authentication successful\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Myers [Page 2]\r
-\f\r
-RFC 1731 IMAP4 Authentication Mechanisms December 1994\r
-\r
-\r
- S: * OK IMAP4 Server\r
- C: A001 AUTHENTICATE KERBEROS_V4\r
- S: + gcfgCA==\r
- C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT\r
- +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd\r
- WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh\r
- S: A001 NO Kerberos V4 authentication failed\r
-\r
-\r
-3. GSSAPI authentication mechanism\r
-\r
- The authentication type associated with all mechanisms employing the\r
- GSSAPI [RFC1508] is "GSSAPI".\r
-\r
- The first ready response issued by the server contains no data. The\r
- client should call GSS_Init_sec_context, passing in 0 for\r
- input_context_handle (initially) and a targ_name equal to output_name\r
- from GSS_Import_Name called with input_name_type of NULL and\r
- input_name_string of "SERVICE:imap@hostname" where "hostname" is the\r
- fully qualified host name of the server with all letters in lower\r
- case. The client must then respond with the resulting output_token.\r
- If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client\r
- should expect the server to issue a token in a subsequent ready\r
- response. The client must pass the token to another call to\r
- GSS_Init_sec_context.\r
-\r
- If GSS_Init_sec_context returns GSS_COMPLETE, then the client should\r
- respond with any resulting output_token. If there is no\r
- output_token, the client should respond with no data. The client\r
- should then expect the server to issue a token in a subsequent ready\r
- response. The client should pass this token to GSS_Unseal and\r
- interpret the first octet of resulting cleartext as a bit-mask\r
- specifying the protection mechanisms supported by the server and the\r
- second through fourth octets as the maximum size output_message to\r
- send to the server. The client should construct data, with the first\r
- octet containing the bit-mask specifying the selected protection\r
- mechanism, the second through fourth octets containing in network\r
- byte order the maximum size output_message the client is able to\r
- receive, and the remaining octets containing a user name string. The\r
- client must pass the data to GSS_Seal with conf_flag set to FALSE,\r
- and respond with the generated output_message. The client can then\r
- consider the server authenticated.\r
-\r
- The server must issue a ready response with no data and pass the\r
- resulting client supplied token to GSS_Accept_sec_context as\r
- input_token, setting acceptor_cred_handle to NULL (for "use default\r
- credentials"), and 0 for input_context_handle (initially). If\r
- GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should\r
-\r
-\r
-\r
-Myers [Page 3]\r
-\f\r
-RFC 1731 IMAP4 Authentication Mechanisms December 1994\r
-\r
-\r
- return the generated output_token to the client in a ready response\r
- and pass the resulting client supplied token to another call to\r
- GSS_Accept_sec_context.\r
-\r
- If GSS_Accept_sec_context returns GSS_COMPLETE, then if an\r
- output_token is returned, the server should return it to the client\r
- in a ready response and expect a reply from the client with no data.\r
- Whether or not an output_token was returned, the server then should\r
- then construct 4 octets of data, with the first octet containing a\r
- bit-mask specifying the protection mechanisms supported by the server\r
- and the second through fourth octets containing in network byte order\r
- the maximum size output_token the server is able to receive. The\r
- server must then pass the plaintext to GSS_Seal with conf_flag set to\r
- FALSE and issue the generated output_message to the client in a ready\r
- response. The server must then pass the resulting client supplied\r
- token to GSS_Unseal and interpret the first octet of resulting\r
- cleartext as the bit-mask for the selected protection mechanism, the\r
- second through fourth octets as the maximum size output_message to\r
- send to the client, and the remaining octets as the user name. Upon\r
- verifying the src_name is authorized to authenticate as the user\r
- name, The server should then consider the client authenticated.\r
-\r
- The protection mechanisms and their corresponding bit-masks are as\r
- follows:\r
-\r
- 1 No protection mechanism\r
- 2 Integrity protection.\r
- Sender calls GSS_Seal with conf_flag set to FALSE\r
- 4 Privacy protection.\r
- Sender calls GSS_Seal with conf_flag set to TRUE\r
-\r
-\r
-4. S/Key authentication mechanism\r
-\r
- The authentication type associated with S/Key [SKEY] is "SKEY".\r
-\r
- The first ready response issued by the server contains no data. The\r
- client responds with the user name string.\r
-\r
- The data encoded in the second ready response contains the decimal\r
- sequence number followed by a single space and the seed string for\r
- the indicated user. The client responds with the one-time-password,\r
- as either a 64-bit value in network byte order or encoded in the "six\r
- English words" format.\r
-\r
- Upon successful verification of the one-time-password, the server\r
- should consider the client authenticated.\r
-\r
-\r
-\r
-\r
-Myers [Page 4]\r
-\f\r
-RFC 1731 IMAP4 Authentication Mechanisms December 1994\r
-\r
-\r
- S/Key authentication does not provide for any protection mechanisms.\r
-\r
-\r
- EXAMPLE: The following are two S/Key login scenarios.\r
-\r
- S: * OK IMAP4 Server\r
- C: A001 AUTHENTICATE SKEY\r
- S: +\r
- C: bW9yZ2Fu\r
- S: + OTUgUWE1ODMwOA==\r
- C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==\r
- S: A001 OK S/Key authentication successful\r
-\r
-\r
- S: * OK IMAP4 Server\r
- C: A001 AUTHENTICATE SKEY\r
- S: +\r
- C: c21pdGg=\r
- S: + OTUgUWE1ODMwOA==\r
- C: BsAY3g4gBNo=\r
- S: A001 NO S/Key authentication failed\r
-\r
-\r
-5. References\r
-\r
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",\r
- RFC 1730, University of Washington, December 1994.\r
-\r
- [RFC1508] Linn, J., "Generic Security Service Application Program\r
- Interface", RFC 1508, Geer Zolot Associates, September 1993.\r
-\r
- [SKEY] Haller, Neil M. "The S/Key One-Time Password System",\r
- Bellcore, Morristown, New Jersey, October 1993,\r
- thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Myers [Page 5]\r
-\f\r
-RFC 1731 IMAP4 Authentication Mechanisms December 1994\r
-\r
-\r
-6. Security Considerations\r
-\r
- Security issues are discussed throughout this memo.\r
-\r
-\r
-7. Author's Address\r
-\r
- John G. Myers\r
- Carnegie-Mellon University\r
- 5000 Forbes Ave.\r
- Pittsburgh PA, 15213-3890\r
-\r
- EMail: jgm+@cmu.edu\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Myers [Page 6]\r
-\f\r
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-\r
-\r
-\r
-\r
-\r
-\r
-Network Working Group J. Klensin, WG Chair\r
-Request For Comments: 1870 MCI\r
-STD: 10 N. Freed, Editor\r
-Obsoletes: 1653 Innosoft International, Inc.\r
-Category: Standards Track K. Moore\r
- University of Tennessee\r
- November 1995\r
-\r
-\r
- SMTP Service Extension\r
- for Message Size Declaration\r
-\r
-Status of this Memo\r
-\r
- This document specifies an Internet standards track protocol for the\r
- Internet community, and requests discussion and suggestions for\r
- improvements. Please refer to the current edition of the "Internet\r
- Official Protocol Standards" (STD 1) for the standardization state\r
- and status of this protocol. Distribution of this memo is unlimited.\r
-\r
-1. Abstract\r
-\r
- This memo defines an extension to the SMTP service whereby an SMTP\r
- client and server may interact to give the server an opportunity to\r
- decline to accept a message (perhaps temporarily) based on the\r
- client's estimate of the message size.\r
-\r
-2. Introduction\r
-\r
- The MIME extensions to the Internet message protocol provide for the\r
- transmission of many kinds of data which were previously unsupported\r
- in Internet mail. One expected result of the use of MIME is that\r
- SMTP will be expected to carry a much wider range of message sizes\r
- than was previously the case. This has an impact on the amount of\r
- resources (e.g. disk space) required by a system acting as a server.\r
-\r
- This memo uses the mechanism defined in [5] to define extensions to\r
- the SMTP service whereby a client ("sender-SMTP") may declare the\r
- size of a particular message to a server ("receiver-SMTP"), after\r
- which the server may indicate to the client that it is or is not\r
- willing to accept the message based on the declared message size and\r
- whereby a server ("receiver-SMTP") may declare the maximum message\r
- size it is willing to accept to a client ("sender-SMTP").\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 1]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
-3. Framework for the Size Declaration Extension\r
-\r
- The following service extension is therefore defined:\r
-\r
- (1) the name of the SMTP service extension is "Message Size\r
- Declaration";\r
-\r
- (2) the EHLO keyword value associated with this extension is "SIZE";\r
-\r
- (3) one optional parameter is allowed with this EHLO keyword value, a\r
- decimal number indicating the fixed maximum message size in bytes\r
- that the server will accept. The syntax of the parameter is as\r
- follows, using the augmented BNF notation of [2]:\r
-\r
- size-param ::= [1*DIGIT]\r
-\r
- A parameter value of 0 (zero) indicates that no fixed maximum\r
- message size is in force. If the parameter is omitted no\r
- information is conveyed about the server's fixed maximum message\r
- size;\r
-\r
- (4) one optional parameter using the keyword "SIZE" is added to the\r
- MAIL FROM command. The value associated with this parameter is a\r
- decimal number indicating the size of the message that is to be\r
- transmitted. The syntax of the value is as follows, using the\r
- augmented BNF notation of [2]:\r
-\r
- size-value ::= 1*20DIGIT\r
-\r
- (5) the maximum length of a MAIL FROM command line is increased by 26\r
- characters by the possible addition of the SIZE keyword and\r
- value;\r
-\r
- (6) no additional SMTP verbs are defined by this extension.\r
-\r
- The remainder of this memo specifies how support for the extension\r
- affects the behavior of an SMTP client and server.\r
-\r
-4. The Message Size Declaration service extension\r
-\r
- An SMTP server may have a fixed upper limit on message size. Any\r
- attempt by a client to transfer a message which is larger than this\r
- fixed upper limit will fail. In addition, a server normally has\r
- limited space with which to store incoming messages. Transfer of a\r
- message may therefore also fail due to a lack of storage space, but\r
- might succeed at a later time.\r
-\r
-\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 2]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
- A client using the unextended SMTP protocol defined in [1], can only\r
- be informed of such failures after transmitting the entire message to\r
- the server (which discards the transferred message). If, however,\r
- both client and server support the Message Size Declaration service\r
- extension, such conditions may be detected before any transfer is\r
- attempted.\r
-\r
- An SMTP client wishing to relay a large content may issue the EHLO\r
- command to start an SMTP session, to determine if the server supports\r
- any of several service extensions. If the server responds with code\r
- 250 to the EHLO command, and the response includes the EHLO keyword\r
- value SIZE, then the Message Size Declaration extension is supported.\r
-\r
- If a numeric parameter follows the SIZE keyword value of the EHLO\r
- response, it indicates the size of the largest message that the\r
- server is willing to accept. Any attempt by a client to transfer a\r
- message which is larger than this limit will be rejected with a\r
- permanent failure (552) reply code.\r
-\r
- A server that supports the Message Size Declaration extension will\r
- accept the extended version of the MAIL command described below.\r
- When supported by the server, a client may use the extended MAIL\r
- command (instead of the MAIL command as defined in [1]) to declare an\r
- estimate of the size of a message it wishes to transfer. The server\r
- may then return an appropriate error code if it determines that an\r
- attempt to transfer a message of that size would fail.\r
-\r
-5. Definitions\r
-\r
- The message size is defined as the number of octets, including CR-LF\r
- pairs, but not the SMTP DATA command's terminating dot or doubled\r
- quoting dots, to be transmitted by the SMTP client after receiving\r
- reply code 354 to the DATA command.\r
-\r
- The fixed maximum message size is defined as the message size of the\r
- largest message that a server is ever willing to accept. An attempt\r
- to transfer any message larger than the fixed maximum message size\r
- will always fail. The fixed maximum message size may be an\r
- implementation artifact of the SMTP server, or it may be chosen by\r
- the administrator of the server.\r
-\r
- The declared message size is defined as a client's estimate of the\r
- message size for a particular message.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 3]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
-6. The extended MAIL command\r
-\r
- The extended MAIL command is issued by a client when it wishes to\r
- inform a server of the size of the message to be sent. The extended\r
- MAIL command is identical to the MAIL command as defined in [1],\r
- except that a SIZE parameter appears after the address.\r
-\r
- The complete syntax of this extended command is defined in [5]. The\r
- esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by\r
- the syntax for size-value shown above.\r
-\r
- The value associated with the SIZE parameter is a decimal\r
- representation of the declared message size in octets. This number\r
- should include the message header, body, and the CR-LF sequences\r
- between lines, but not the SMTP DATA command's terminating dot or\r
- doubled quoting dots. Only one SIZE parameter may be specified in a\r
- single MAIL command.\r
-\r
- Ideally, the declared message size is equal to the true message size.\r
- However, since exact computation of the message size may be\r
- infeasable, the client may use a heuristically-derived estimate.\r
- Such heuristics should be chosen so that the declared message size is\r
- usually larger than the actual message size. (This has the effect of\r
- making the counting or non-counting of SMTP DATA dots largely an\r
- academic point.)\r
-\r
- NOTE: Servers MUST NOT use the SIZE parameter to determine end of\r
- content in the DATA command.\r
-\r
-6.1 Server action on receipt of the extended MAIL command\r
-\r
- Upon receipt of an extended MAIL command containing a SIZE parameter,\r
- a server should determine whether the declared message size exceeds\r
- its fixed maximum message size. If the declared message size is\r
- smaller than the fixed maximum message size, the server may also wish\r
- to determine whether sufficient resources are available to buffer a\r
- message of the declared message size and to maintain it in stable\r
- storage, until the message can be delivered or relayed to each of its\r
- recipients.\r
-\r
- A server may respond to the extended MAIL command with any of the\r
- error codes defined in [1] for the MAIL command. In addition, one of\r
- the following error codes may be returned:\r
-\r
- (1) If the server currently lacks sufficient resources to accept a\r
- message of the indicated size, but may be able to accept the\r
- message at a later time, it responds with code "452 insufficient\r
- system storage".\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 4]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
- (2) If the indicated size is larger than the server's fixed maximum\r
- message size, the server responds with code "552 message size\r
- exceeds fixed maximium message size".\r
-\r
- A server is permitted, but not required, to accept a message which\r
- is, in fact, larger than declared in the extended MAIL command, such\r
- as might occur if the client employed a size-estimation heuristic\r
- which was inaccurate.\r
-\r
-6.2 Client action on receiving response to extended MAIL command\r
-\r
- The client, upon receiving the server's response to the extended MAIL\r
- command, acts as follows:\r
-\r
- (1) If the code "452 insufficient system storage" is returned, the\r
- client should next send either a RSET command (if it wishes to\r
- attempt to send other messages) or a QUIT command. The client\r
- should then repeat the attempt to send the message to the server\r
- at a later time.\r
-\r
- (2) If the code "552 message exceeds fixed maximum message size" is\r
- received, the client should immediately send either a RSET command\r
- (if it wishes to attempt to send additional messages), or a QUIT\r
- command. The client should then declare the message undeliverable\r
- and return appropriate notification to the sender (if a sender\r
- address was present in the MAIL command).\r
-\r
- A successful (250) reply code in response to the extended MAIL\r
- command does not constitute an absolute guarantee that the message\r
- transfer will succeed. SMTP clients using the extended MAIL command\r
- must still be prepared to handle both temporary and permanent error\r
- reply codes (including codes 452 and 552), either immediately after\r
- issuing the DATA command, or after transfer of the message.\r
-\r
-6.3 Messages larger than the declared size.\r
-\r
- Once a server has agreed (via the extended MAIL command) to accept a\r
- message of a particular size, it should not return a 552 reply code\r
- after the transfer phase of the DATA command, unless the actual size\r
- of the message transferred is greater than the declared message size.\r
- A server may also choose to accept a message which is somewhat larger\r
- than the declared message size.\r
-\r
- A client is permitted to declare a message to be smaller than its\r
- actual size. However, in this case, a successful (250) reply code is\r
- no assurance that the server will accept the message or has\r
- sufficient resources to do so. The server may reject such a message\r
- after its DATA transfer.\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 5]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
-6.4 Per-recipient rejection based on message size.\r
-\r
- A server that implements this extension may return a 452 or 552 reply\r
- code in response to a RCPT command, based on its unwillingness to\r
- accept a message of the declared size for a particular recipient.\r
-\r
- (1) If a 452 code is returned, the client may requeue the message for\r
- later delivery to the same recipient.\r
-\r
- (2) If a 552 code is returned, the client may not requeue the message\r
- for later delivery to the same recipient.\r
-\r
-7. Minimal usage\r
-\r
- A "minimal" client may use this extension to simply compare its\r
- (perhaps estimated) size of the message that it wishes to relay, with\r
- the server's fixed maximum message size (from the parameter to the\r
- SIZE keyword in the EHLO response), to determine whether the server\r
- will ever accept the message. Such an implementation need not\r
- declare message sizes via the extended MAIL command. However,\r
- neither will it be able to discover temporary limits on message size\r
- due to server resource limitations, nor per-recipient limitations on\r
- message size.\r
-\r
- A minimal server that employs this service extension may simply use\r
- the SIZE keyword value to inform the client of the size of the\r
- largest message it will accept, or to inform the client that there is\r
- no fixed limit on message size. Such a server must accept the\r
- extended MAIL command and return a 552 reply code if the client's\r
- declared size exceeds its fixed size limit (if any), but it need not\r
- detect "temporary" limitations on message size.\r
-\r
- The numeric parameter to the EHLO SIZE keyword is optional. If the\r
- parameter is omitted entirely it indicates that the server does not\r
- advertise a fixed maximum message size. A server that returns the\r
- SIZE keyword with no parameter in response to the EHLO command may\r
- not issue a positive (250) response to an extended MAIL command\r
- containing a SIZE specification without first checking to see if\r
- sufficient resources are available to transfer a message of the\r
- declared size, and to retain it in stable storage until it can be\r
- relayed or delivered to its recipients. If possible, the server\r
- should actually reserve sufficient storage space to transfer the\r
- message.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 6]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
-8. Example\r
-\r
- The following example illustrates the use of size declaration with\r
- some permanent and temporary failures.\r
-\r
- S: <wait for connection on TCP port 25>\r
- C: <open connection to server>\r
- S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)\r
- C: EHLO ymir.claremont.edu\r
- S: 250-sigurd.innosoft.com\r
- S: 250-EXPN\r
- S: 250-HELP\r
- S: 250 SIZE 1000000\r
- C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000\r
- S: 250 Address Ok.\r
- C: RCPT TO:<ned@innosoft.com>\r
- S: 250 ned@innosoft.com OK; can accomodate 500000 byte message\r
- C: RCPT TO:<ned@ymir.claremont.edu>\r
- S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU\r
- C: RCPT TO:<ned@hmcvax.claremont.edu>\r
- S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU\r
- C: DATA\r
- S: 354 Send message, ending in CRLF.CRLF.\r
- ...\r
- C: .\r
- S: 250 Some recipients OK\r
- C: QUIT\r
- S: 221 Goodbye\r
-\r
-9. Security Considerations\r
-\r
- The size declaration extensions described in this memo can\r
- conceivably be used to facilitate crude service denial attacks.\r
- Specifically, both the information contained in the SIZE parameter\r
- and use of the extended MAIL command make it somewhat quicker and\r
- easier to devise an efficacious service denial attack. However,\r
- unless implementations are very weak, these extensions do not create\r
- any vulnerability that has not always existed with SMTP. In addition,\r
- no issues are addressed involving trusted systems and possible\r
- release of information via the mechanisms described in this RFC.\r
-\r
-10. Acknowledgements\r
-\r
- This document was derived from an earlier Working Group work in\r
- progess contribution. Jim Conklin, Dave Crocker, Neil Katin, Eliot\r
- Lear, Marshall T. Rose, and Einar Stefferud provided extensive\r
- comments in response to earlier works in progress of both this and\r
- the previous memo.\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 7]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
-11. References\r
-\r
- [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,\r
- USC/Information Sciences Institute, August 1982.\r
-\r
- [2] Crocker, D., "Standard for the Format of ARPA Internet Text\r
- Messages", STD 11, RFC 822, UDEL, August 1982.\r
-\r
- [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail\r
- Extensions", RFC 1521, Bellcore, Innosoft, September 1993.\r
-\r
- [4] Moore, K., "Representation of Non-ASCII Text in Internet Message\r
- Headers", RFC 1522, University of Tennessee, September 1993.\r
-\r
- [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,\r
- "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft\r
- International, Inc., Dover Beach Consulting, Inc., Network\r
- Management Associates, Inc., Brandenburg Consulting, November\r
- 1995.\r
-\r
- [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC\r
- 974, BBN, January 1986.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 8]\r
-\f\r
-RFC 1870 SMTP Size Declaration November 1995\r
-\r
-\r
-12. Chair, Editor, and Author Addresses\r
-\r
- John Klensin, WG Chair\r
- MCI\r
- 2100 Reston Parkway\r
- Reston, VA 22091\r
-\r
- Phone: +1 703 715-7361\r
- Fax: +1 703 715-7436\r
- EMail: klensin@mci.net\r
-\r
-\r
- Ned Freed, Editor\r
- Innosoft International, Inc.\r
- 1050 East Garvey Avenue South\r
- West Covina, CA 91790\r
- USA\r
-\r
- Phone: +1 818 919 3600\r
- Fax: +1 818 919 3614\r
- EMail: ned@innosoft.com\r
-\r
-\r
- Keith Moore\r
- Computer Science Dept.\r
- University of Tennessee\r
- 107 Ayres Hall\r
- Knoxville, TN 37996-1301\r
- USA\r
-\r
- EMail: moore@cs.utk.edu\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Klensin, et al Standards Track [Page 9]\r
-\f\r
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-\r
-\r
-\r
-\r
-\r
-\r
-Network Working Group B. Leiba\r
-Request for Comments: 2177 IBM T.J. Watson Research Center\r
-Category: Standards Track June 1997\r
-\r
-\r
- IMAP4 IDLE command\r
-\r
-Status of this Memo\r
-\r
- This document specifies an Internet standards track protocol for the\r
- Internet community, and requests discussion and suggestions for\r
- improvements. Please refer to the current edition of the "Internet\r
- Official Protocol Standards" (STD 1) for the standardization state\r
- and status of this protocol. Distribution of this memo is unlimited.\r
-\r
-1. Abstract\r
-\r
- The Internet Message Access Protocol [IMAP4] requires a client to\r
- poll the server for changes to the selected mailbox (new mail,\r
- deletions). It's often more desirable to have the server transmit\r
- updates to the client in real time. This allows a user to see new\r
- mail immediately. It also helps some real-time applications based on\r
- IMAP, which might otherwise need to poll extremely often (such as\r
- every few seconds). (While the spec actually does allow a server to\r
- push EXISTS responses aysynchronously, a client can't expect this\r
- behaviour and must poll.)\r
-\r
- This document specifies the syntax of an IDLE command, which will\r
- allow a client to tell the server that it's ready to accept such\r
- real-time updates.\r
-\r
-2. Conventions Used in this Document\r
-\r
- In examples, "C:" and "S:" indicate lines sent by the client and\r
- server respectively.\r
-\r
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"\r
- in this document are to be interpreted as described in RFC 2060\r
- [IMAP4].\r
-\r
-3. Specification\r
-\r
- IDLE Command\r
-\r
- Arguments: none\r
-\r
- Responses: continuation data will be requested; the client sends\r
- the continuation data "DONE" to end the command\r
-\r
-\r
-\r
-Leiba Standards Track [Page 1]\r
-\f\r
-RFC 2177 IMAP4 IDLE command June 1997\r
-\r
-\r
-\r
- Result: OK - IDLE completed after client sent "DONE"\r
- NO - failure: the server will not allow the IDLE\r
- command at this time\r
- BAD - command unknown or arguments invalid\r
-\r
- The IDLE command may be used with any IMAP4 server implementation\r
- that returns "IDLE" as one of the supported capabilities to the\r
- CAPABILITY command. If the server does not advertise the IDLE\r
- capability, the client MUST NOT use the IDLE command and must poll\r
- for mailbox updates. In particular, the client MUST continue to be\r
- able to accept unsolicited untagged responses to ANY command, as\r
- specified in the base IMAP specification.\r
-\r
- The IDLE command is sent from the client to the server when the\r
- client is ready to accept unsolicited mailbox update messages. The\r
- server requests a response to the IDLE command using the continuation\r
- ("+") response. The IDLE command remains active until the client\r
- responds to the continuation, and as long as an IDLE command is\r
- active, the server is now free to send untagged EXISTS, EXPUNGE, and\r
- other messages at any time.\r
-\r
- The IDLE command is terminated by the receipt of a "DONE"\r
- continuation from the client; such response satisfies the server's\r
- continuation request. At that point, the server MAY send any\r
- remaining queued untagged responses and then MUST immediately send\r
- the tagged response to the IDLE command and prepare to process other\r
- commands. As in the base specification, the processing of any new\r
- command may cause the sending of unsolicited untagged responses,\r
- subject to the ambiguity limitations. The client MUST NOT send a\r
- command while the server is waiting for the DONE, since the server\r
- will not be able to distinguish a command from a continuation.\r
-\r
- The server MAY consider a client inactive if it has an IDLE command\r
- running, and if such a server has an inactivity timeout it MAY log\r
- the client off implicitly at the end of its timeout period. Because\r
- of that, clients using IDLE are advised to terminate the IDLE and\r
- re-issue it at least every 29 minutes to avoid being logged off.\r
- This still allows a client to receive immediate mailbox updates even\r
- though it need only "poll" at half hour intervals.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Standards Track [Page 2]\r
-\f\r
-RFC 2177 IMAP4 IDLE command June 1997\r
-\r
-\r
- Example: C: A001 SELECT INBOX\r
- S: * FLAGS (Deleted Seen)\r
- S: * 3 EXISTS\r
- S: * 0 RECENT\r
- S: * OK [UIDVALIDITY 1]\r
- S: A001 OK SELECT completed\r
- C: A002 IDLE\r
- S: + idling\r
- ...time passes; new mail arrives...\r
- S: * 4 EXISTS\r
- C: DONE\r
- S: A002 OK IDLE terminated\r
- ...another client expunges message 2 now...\r
- C: A003 FETCH 4 ALL\r
- S: * 4 FETCH (...)\r
- S: A003 OK FETCH completed\r
- C: A004 IDLE\r
- S: * 2 EXPUNGE\r
- S: * 3 EXISTS\r
- S: + idling\r
- ...time passes; another client expunges message 3...\r
- S: * 3 EXPUNGE\r
- S: * 2 EXISTS\r
- ...time passes; new mail arrives...\r
- S: * 3 EXISTS\r
- C: DONE\r
- S: A004 OK IDLE terminated\r
- C: A005 FETCH 3 ALL\r
- S: * 3 FETCH (...)\r
- S: A005 OK FETCH completed\r
- C: A006 IDLE\r
-\r
-4. Formal Syntax\r
-\r
- The following syntax specification uses the augmented Backus-Naur\r
- Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].\r
- Non-terminals referenced but not defined below are as defined by\r
- [IMAP4].\r
-\r
- command_auth ::= append / create / delete / examine / list / lsub /\r
- rename / select / status / subscribe / unsubscribe\r
- / idle\r
- ;; Valid only in Authenticated or Selected state\r
-\r
- idle ::= "IDLE" CRLF "DONE"\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Standards Track [Page 3]\r
-\f\r
-RFC 2177 IMAP4 IDLE command June 1997\r
-\r
-\r
-5. References\r
-\r
- [IMAP4] Crispin, M., "Internet Message Access Protocol - Version\r
- 4rev1", RFC 2060, December 1996.\r
-\r
-6. Security Considerations\r
-\r
- There are no known security issues with this extension.\r
-\r
-7. Author's Address\r
-\r
- Barry Leiba\r
- IBM T.J. Watson Research Center\r
- 30 Saw Mill River Road\r
- Hawthorne, NY 10532\r
-\r
- Email: leiba@watson.ibm.com\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Standards Track [Page 4]\r
-\f\r
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-\r
-\r
-\r
-\r
-\r
-\r
-Network Working Group R. Gellens\r
-Request for Comments: 2449 Qualcomm\r
-Updates: 1939 C. Newman\r
-Category: Standards Track Innosoft\r
- L. Lundblade\r
- Qualcomm\r
- November 1998\r
-\r
-\r
- POP3 Extension Mechanism\r
-\r
-Status of this Memo\r
-\r
- This document specifies an Internet standards track protocol for the\r
- Internet community, and requests discussion and suggestions for\r
- improvements. Please refer to the current edition of the "Internet\r
- Official Protocol Standards" (STD 1) for the standardization state\r
- and status of this protocol. Distribution of this memo is unlimited.\r
-\r
-Copyright Notice\r
-\r
- Copyright (C) The Internet Society (1998). All Rights Reserved.\r
-\r
-IESG Note\r
-\r
- This extension to the POP3 protocol is to be used by a server to\r
- express policy descisions taken by the server administrator. It is\r
- not an endorsement of implementations of further POP3 extensions\r
- generally. It is the general view that the POP3 protocol should stay\r
- simple, and for the simple purpose of downloading email from a mail\r
- server. If more complicated operations are needed, the IMAP protocol\r
- [RFC 2060] should be used. The first paragraph of section 7 should\r
- be read very carefully.\r
-\r
-Table of Contents\r
-\r
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2\r
- 2. Conventions Used in this Document . . . . . . . . . . . . . 3\r
- 3. General Command and Response Grammar . . . . . . . . . . . . 3\r
- 4. Parameter and Response Lengths . . . . . . . . . . . . . . 4\r
- 5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4\r
- 6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5\r
- 6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6\r
- 6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6\r
- 6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7\r
- 6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8\r
- 6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8\r
- 6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 1]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- 6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10\r
- 6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13\r
- 6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13\r
- 7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14\r
- 8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14\r
- 8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15\r
- 8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15\r
- 8.1.2. The IN-USE response code . . . . . . . . . . . . . 16\r
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16\r
- 10. Security Considerations . . . . . . . . . . . . . . . . . . 17\r
- 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17\r
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . 17\r
- 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18\r
- 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19\r
-\r
-1. Introduction\r
-\r
- The Post Office Protocol version 3 [POP3] is very widely used.\r
- However, while it includes some optional commands (and some useful\r
- protocol extensions have been published), it lacks a mechanism for\r
- advertising support for these extensions or for behavior variations.\r
-\r
- Currently these optional features and extensions can only be detected\r
- by probing, if at all. This is at best inefficient, and possibly\r
- worse. As a result, some clients have manual configuration options\r
- for POP3 server capabilities.\r
-\r
- Because one of the most important characteristics of POP3 is its\r
- simplicity, it is desirable that extensions be few in number (see\r
- section 7). However, some extensions are necessary (such as ones\r
- that provide improved security [POP-AUTH]), while others are very\r
- desirable in certain situations. In addition, a means for\r
- discovering server behavior is needed.\r
-\r
- This memo updates RFC 1939 [POP3] to define a mechanism to announce\r
- support for optional commands, extensions, and unconditional server\r
- behavior. Included is an initial set of currently deployed\r
- capabilities which vary between server implementations, and several\r
- new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE\r
- and IMPLEMENTATION). This document also extends POP3 error messages\r
- so that machine parsable codes can be provided to the client. An\r
- initial set of response codes is included. In addition, an [ABNF]\r
- specification of POP3 commands and responses is defined.\r
-\r
- Public comments should be sent to the IETF POP3 Extensions mailing\r
- list, <ietf-pop3ext@imc.org>. To subscribe, send a message\r
- containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 2]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
-2. Conventions Used in this Document\r
-\r
- The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",\r
- and "MAY" in this document are to be interpreted as described in "Key\r
- words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].\r
-\r
- In examples, "C:" and "S:" indicate lines sent by the client and\r
- server respectively.\r
-\r
-3. General Command and Response Grammar\r
-\r
- The general form of POP3 commands and responses is described using\r
- [ABNF]:\r
-\r
- POP3 commands:\r
-\r
- command = keyword *(SP param) CRLF ;255 octets maximum\r
- keyword = 3*4VCHAR\r
- param = 1*VCHAR\r
-\r
- POP3 responses:\r
-\r
- response = greeting / single-line / capa-resp / multi-line\r
- capa-resp = single-line *capability "." CRLF\r
- capa-tag = 1*cchar\r
- capability = capa-tag *(SP param) CRLF ;512 octets maximum\r
- cchar = %x21-2D / %x2F-7F\r
- ;printable ASCII, excluding "."\r
- dot-stuffed = *CHAR CRLF ;must be dot-stuffed\r
- gchar = %x21-3B / %x3D-7F\r
- ;printable ASCII, excluding "<"\r
- greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF\r
- ;512 octets maximum\r
- multi-line = single-line *dot-stuffed "." CRLF\r
- rchar = %x21-2E / %x30-5C / %x5E-7F\r
- ;printable ASCII, excluding "/" and "]"\r
- resp-code = "[" resp-level *("/" resp-level) "]"\r
- resp-level = 1*rchar\r
- schar = %x21-5A / %x5C-7F\r
- ;printable ASCII, excluding "["\r
- single-line = status [SP text] CRLF ;512 octets maximum\r
- status = "+OK" / "-ERR"\r
- text = *schar / resp-code *CHAR\r
- timestamp = "<" *VCHAR ">"\r
- ;MUST conform to RFC-822 msg-id\r
-\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 3]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
-4. Parameter and Response Lengths\r
-\r
- This specification increases the length restrictions on commands and\r
- parameters imposed by RFC 1939.\r
-\r
- The maximum length of a command is increased from 47 characters (4\r
- character command, single space, 40 character argument, CRLF) to 255\r
- octets, including the terminating CRLF.\r
-\r
- Servers which support the CAPA command MUST support commands up to\r
- 255 octets. Servers MUST also support the largest maximum command\r
- length specified by any supported capability.\r
-\r
- The maximum length of the first line of a command response (including\r
- the initial greeting) is unchanged at 512 octets (including the\r
- terminating CRLF).\r
-\r
-5. The CAPA Command\r
-\r
- The POP3 CAPA command returns a list of capabilities supported by the\r
- POP3 server. It is available in both the AUTHORIZATION and\r
- TRANSACTION states.\r
-\r
- A capability description MUST document in which states the capability\r
- is announced, and in which states the commands are valid.\r
-\r
- Capabilities available in the AUTHORIZATION state MUST be announced\r
- in both states.\r
-\r
- If a capability is announced in both states, but the argument might\r
- differ after authentication, this possibility MUST be stated in the\r
- capability description.\r
-\r
- (These requirements allow a client to issue only one CAPA command if\r
- it does not use any TRANSACTION-only capabilities, or any\r
- capabilities whose values may differ after authentication.)\r
-\r
- If the authentication step negotiates an integrity protection layer,\r
- the client SHOULD reissue the CAPA command after authenticating, to\r
- check for active down-negotiation attacks.\r
-\r
- Each capability may enable additional protocol commands, additional\r
- parameters and responses for existing commands, or describe an aspect\r
- of server behavior. These details are specified in the description\r
- of the capability.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 4]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- Section 3 describes the CAPA response using [ABNF]. When a\r
- capability response describes an optional command, the <capa-tag>\r
- SHOULD be identical to the command keyword. CAPA response tags are\r
- case-insensitive.\r
-\r
- CAPA\r
-\r
- Arguments:\r
- none\r
-\r
- Restrictions:\r
- none\r
-\r
- Discussion:\r
- An -ERR response indicates the capability command is not\r
- implemented and the client will have to probe for\r
- capabilities as before.\r
-\r
- An +OK response is followed by a list of capabilities, one\r
- per line. Each capability name MAY be followed by a single\r
- space and a space-separated list of parameters. Each\r
- capability line is limited to 512 octets (including the\r
- CRLF). The capability list is terminated by a line\r
- containing a termination octet (".") and a CRLF pair.\r
-\r
- Possible Responses:\r
- +OK -ERR\r
-\r
- Examples:\r
- C: CAPA\r
- S: +OK Capability list follows\r
- S: TOP\r
- S: USER\r
- S: SASL CRAM-MD5 KERBEROS_V4\r
- S: RESP-CODES\r
- S: LOGIN-DELAY 900\r
- S: PIPELINING\r
- S: EXPIRE 60\r
- S: UIDL\r
- S: IMPLEMENTATION Shlemazle-Plotz-v302\r
- S: .\r
-\r
-6. Initial Set of Capabilities\r
-\r
- This section defines an initial set of POP3 capabilities. These\r
- include the optional POP3 commands, already published POP3\r
- extensions, and behavior variations between POP3 servers which can\r
- impact clients.\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 5]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- Note that there is no APOP capability, even though APOP is an\r
- optional command in [POP3]. Clients discover server support of APOP\r
- by the presence in the greeting banner of an initial challenge\r
- enclosed in angle brackets ("<>"). Therefore, an APOP capability\r
- would introduce two ways for a server to announce the same thing.\r
-\r
-6.1. TOP capability\r
-\r
- CAPA tag:\r
- TOP\r
-\r
- Arguments:\r
- none\r
-\r
- Added commands:\r
- TOP\r
-\r
- Standard commands affected:\r
- none\r
-\r
- Announced states / possible differences:\r
- both / no\r
-\r
- Commands valid in states:\r
- TRANSACTION\r
-\r
- Specification reference:\r
- [POP3]\r
-\r
- Discussion:\r
- The TOP capability indicates the optional TOP command is\r
- available.\r
-\r
-6.2. USER capability\r
-\r
- CAPA tag:\r
- USER\r
-\r
- Arguments:\r
- none\r
-\r
- Added commands:\r
- USER PASS\r
-\r
- Standard commands affected:\r
- none\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 6]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- Announced states / possible differences:\r
- both / no\r
-\r
- Commands valid in states:\r
- AUTHENTICATION\r
-\r
- Specification reference:\r
- [POP3]\r
-\r
- Discussion:\r
- The USER capability indicates that the USER and PASS commands\r
- are supported, although they may not be available to all users.\r
-\r
-6.3. SASL capability\r
-\r
- CAPA tag:\r
- SASL\r
-\r
- Arguments:\r
- Supported SASL mechanisms\r
-\r
- Added commands:\r
- AUTH\r
-\r
- Standard commands affected:\r
- none\r
-\r
- Announced states / possible differences:\r
- both / no\r
-\r
- Commands valid in states:\r
- AUTHENTICATION\r
-\r
- Specification reference:\r
- [POP-AUTH, SASL]\r
-\r
- Discussion:\r
- The POP3 AUTH command [POP-AUTH] permits the use of [SASL]\r
- authentication mechanisms with POP3. The SASL capability\r
- indicates that the AUTH command is available and that it supports\r
- an optional base64 encoded second argument for an initial client\r
- response as described in the SASL specification. The argument to\r
- the SASL capability is a space separated list of SASL mechanisms\r
- which are supported.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 7]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
-6.4. RESP-CODES capability\r
-\r
- CAPA tag:\r
- RESP-CODES\r
-\r
- Arguments:\r
- none\r
-\r
- Added commands:\r
- none\r
-\r
- Standard commands affected:\r
- none\r
-\r
- Announced states / possible differences:\r
- both / no\r
-\r
- Commands valid in states:\r
- n/a\r
-\r
- Specification reference:\r
- this document\r
-\r
- Discussion:\r
- The RESP-CODES capability indicates that any response text issued\r
- by this server which begins with an open square bracket ("[") is\r
- an extended response code (see section 8).\r
-\r
-6.5. LOGIN-DELAY capability\r
-\r
- CAPA tag:\r
- LOGIN-DELAY\r
-\r
- Arguments:\r
- minimum seconds between logins; optionally followed by USER in\r
- AUTHENTICATION state.\r
-\r
- Added commands:\r
- none\r
-\r
- Standard commands affected:\r
- USER PASS APOP AUTH\r
-\r
- Announced states / possible differences:\r
- both / yes\r
-\r
- Commands valid in states:\r
- n/a\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 8]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- Specification reference:\r
- this document\r
-\r
- Discussion:\r
- POP3 clients often login frequently to check for new mail.\r
- Unfortunately, the process of creating a connection,\r
- authenticating the user, and opening the user's maildrop can be\r
- very resource intensive on the server. A number of deployed POP3\r
- servers try to reduce server load by requiring a delay between\r
- logins. The LOGIN-DELAY capability includes an integer argument\r
- which indicates the number of seconds after an "+OK" response to\r
- a PASS, APOP, or AUTH command before another authentication will\r
- be accepted. Clients which permit the user to configure a mail\r
- check interval SHOULD use this capability to determine the\r
- minimum permissible interval. Servers which advertise LOGIN-\r
- DELAY SHOULD enforce it.\r
-\r
- If the minimum login delay period could differ per user (that is,\r
- the LOGIN-DELAY argument might change after authentication), the\r
- server MUST announce in AUTHENTICATION state the largest value\r
- which could be set for any user. This might be the largest value\r
- currently in use for any user (so only one value per server), or\r
- even the largest value which the server permits to be set for any\r
- user. The server SHOULD append the token "USER" to the LOGIN-\r
- DELAY parameter in AUTHENTICATION state, to inform the client\r
- that a more accurate value is available after authentication.\r
- The server SHOULD announce the more accurate value in TRANSACTION\r
- state. (The "USER" token allows the client to decide if a second\r
- CAPA command is needed or not.)\r
-\r
- Servers enforce LOGIN-DELAY by rejecting an authentication\r
- command with or without the LOGIN-DELAY error response. See\r
- section 8.1.1 for more information.\r
-\r
-6.6. PIPELINING capability\r
-\r
- CAPA tag:\r
- PIPELINING\r
-\r
- Arguments:\r
- none\r
-\r
- Added commands:\r
- none\r
-\r
- Standard commands affected:\r
- all\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 9]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- Announced states / possible differences:\r
- both / no\r
-\r
- Commands valid in states:\r
- n/a\r
-\r
- Specification reference:\r
- this document\r
-\r
- Discussion:\r
- The PIPELINING capability indicates the server is capable of\r
- accepting multiple commands at a time; the client does not have\r
- to wait for the response to a command before issuing a subsequent\r
- command. If a server supports PIPELINING, it MUST process each\r
- command in turn. If a client uses PIPELINING, it MUST keep track\r
- of which commands it has outstanding, and match server responses\r
- to commands in order. If either the client or server uses\r
- blocking writes, it MUST not exceed the window size of the\r
- underlying transport layer.\r
-\r
- Some POP3 clients have an option to indicate the server supports\r
- "Overlapped POP3 commands." This capability removes the need to\r
- configure this at the client.\r
-\r
- This is roughly synonymous with the ESMTP PIPELINING extension\r
- [PIPELINING], however, since SMTP [SMTP] tends to have short\r
- commands and responses, the benefit is in grouping multiple\r
- commands and sending them as a unit. While there are cases of\r
- this in POP (for example, USER and PASS could be batched,\r
- multiple RETR and/or DELE commands could be sent as a group),\r
- because POP has short commands and sometimes lengthy responses,\r
- there is also an advantage is sending new commands while still\r
- receiving the response to an earlier command (for example,\r
- sending RETR and/or DELE commands while processing a UIDL reply).\r
-\r
-6.7. EXPIRE capability\r
-\r
- CAPA tag:\r
- EXPIRE\r
-\r
- Arguments:\r
- server-guaranteed minimum retention days, or NEVER; optionally\r
- followed by USER in AUTHENTICATION state\r
-\r
- Added commands:\r
- none\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 10]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- Standard commands affected:\r
- none\r
-\r
- Announced states / possible differences:\r
- both / yes\r
-\r
- Commands valid in states:\r
- n/a\r
-\r
- Specification reference:\r
- this document\r
-\r
- Discussion:\r
- While POP3 allows clients to leave messages on the server, RFC\r
- 1939 [POP3] warns about the problems that may arise from this,\r
- and allows servers to delete messages based on site policy.\r
-\r
- The EXPIRE capability avoids the problems mentioned in RFC 1939,\r
- by allowing the server to inform the client as to the policy in\r
- effect. The argument to the EXPIRE capability indicates the\r
- minimum server retention period, in days, for messages on the\r
- server.\r
-\r
- EXPIRE 0 indicates the client is not permitted to leave mail on\r
- the server; when the session enters the UPDATE state the server\r
- MAY assume an implicit DELE for each message which was downloaded\r
- with RETR.\r
-\r
- EXPIRE NEVER asserts that the server does not delete messages.\r
-\r
- The concept of a "retention period" is intentionally vague.\r
- Servers may start counting days to expiration when a message is\r
- added to a maildrop, when a client becomes aware of the existence\r
- of a message through the LIST or UIDL commands, when a message\r
- has been acted upon in some way (for example, TOP or RETR), or at\r
- some other event. The EXPIRE capability cannot provide a precise\r
- indication as to exactly when any specific message will expire.\r
- The capability is intended to make it easier for clients to\r
- behave in ways which conform to site policy and user wishes. For\r
- example, a client might display a warning for attempts to\r
- configure a "leave mail on server" period which is greater than\r
- or equal to some percentage of the value announced by the server.\r
-\r
- If a site uses any automatic deletion policy, it SHOULD use the\r
- EXPIRE capability to announce this.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 11]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- The EXPIRE capability, with a parameter other than 0 or NEVER, is\r
- intended to let the client know that the server does permit mail\r
- to be left on the server, and to present a value which is the\r
- smallest which might be in force.\r
-\r
- Sites which permit users to retain messages indefinitely SHOULD\r
- announce this with the EXPIRE NEVER response.\r
-\r
- If the expiration policy differs per user (that is, the EXPIRE\r
- argument might change after authentication), the server MUST\r
- announce in AUTHENTICATION state the smallest value which could\r
- be set for any user. This might be the smallest value currently\r
- in use for any user (so only one value per server), or even the\r
- smallest value which the server permits to be set for any user.\r
- The server SHOULD append the token "USER" to the EXPIRE parameter\r
- in AUTHENTICATION state, to inform the client that a more\r
- accurate value is available after authentication. The server\r
- SHOULD announce the more accurate value in TRANSACTION state.\r
- (The "USER" token allows the client to decide if a second CAPA\r
- command is needed or not.)\r
-\r
- A site may have a message expiration policy which treats messages\r
- differently depending on which user actions have been performed,\r
- or based on other factors. For example, a site might delete\r
- unseen messages after 60 days, and completely- or partially-seen\r
- messages after 15 days.\r
-\r
- The announced EXPIRE value is the smallest retention period which\r
- is or might be used by any category or condition of the current\r
- site policy, for any user (in AUTHENTICATION state) or the\r
- specific user (in TRANSACTION state). That is, EXPIRE informs\r
- the client of the minimum number of days messages may remain on\r
- the server under any circumstances.\r
-\r
- Examples:\r
- EXPIRE 5 USER\r
- EXPIRE 30\r
- EXPIRE NEVER\r
- EXPIRE 0\r
-\r
- The first example indicates the server might delete messages\r
- after five days, but the period differs per user, and so a more\r
- accurate value can be obtained by issuing a second CAPA command\r
- in TRANSACTION state. The second example indicates the server\r
- could delete messages after 30 days. In the third example, the\r
- server announces it does not delete messages. The fourth example\r
- specifies that the site does not permit messages to be left on\r
- the server.\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 12]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
-6.8. UIDL capability\r
-\r
- CAPA tag:\r
- UIDL\r
-\r
- Arguments:\r
- none\r
-\r
- Added commands:\r
- UIDL\r
-\r
- Standard commands affected:\r
- none\r
-\r
- Announced states / possible differences:\r
- both / no\r
-\r
- Commands valid in states:\r
- TRANSACTION\r
-\r
- Specification reference:\r
- [POP3]\r
-\r
- Discussion:\r
- The UIDL capability indicates that the optional UIDL command is\r
- supported.\r
-\r
-6.9. IMPLEMENTATION capability\r
-\r
- CAPA tag:\r
- IMPLEMENTATION\r
-\r
- Arguments:\r
- string giving server implementation information\r
-\r
- Added commands:\r
- none\r
-\r
- Standard commands affected:\r
- none\r
-\r
- Announced states / possible differences:\r
- both (optionally TRANSACTION only) / no\r
-\r
- Commands valid in states:\r
- n/a\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 13]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- Specification reference:\r
- this document\r
-\r
- Discussion:\r
- It is often useful to identify an implementation of a particular\r
- server (for example, when logging). This is commonly done in the\r
- welcome banner, but one must guess if a string is an\r
- implementation ID or not.\r
-\r
- The argument to the IMPLEMENTATION capability consists of one or\r
- more tokens which identify the server. (Note that since CAPA\r
- response tag arguments are space-separated, it may be convenient\r
- for the IMPLEMENTATION capability argument to not contain spaces,\r
- so that it is a single token.)\r
-\r
- Normally, servers announce IMPLEMENTATION in both states.\r
- However, a server MAY chose to do so only in TRANSACTION state.\r
-\r
- A server MAY include the implementation identification both in\r
- the welcome banner and in the IMPLEMENTATION capability.\r
-\r
- Clients MUST NOT modify their behavior based on the server\r
- implementation. Instead the server and client should agree on a\r
- private extension.\r
-\r
-7. Future Extensions to POP3\r
-\r
- Future extensions to POP3 are in general discouraged, as POP3's\r
- usefulness lies in its simplicity. POP3 is intended as a download-\r
- and-delete protocol; mail access capabilities are available in IMAP\r
- [IMAP4]. Extensions which provide support for additional mailboxes,\r
- allow uploading of messages to the server, or which deviate from\r
- POP's download-and-delete model are strongly discouraged and unlikely\r
- to be permitted on the IETF standards track.\r
-\r
- Clients MUST NOT require the presence of any extension for basic\r
- functionality, with the exception of the authentication commands\r
- (APOP, AUTH [section 6.3] and USER/PASS).\r
-\r
- Section 9 specifies how additional capabilities are defined.\r
-\r
-8. Extended POP3 Response Codes\r
-\r
- Unextended POP3 is only capable of indicating success or failure to\r
- most commands. Unfortunately, clients often need to know more\r
- information about the cause of a failure in order to gracefully\r
- recover. This is especially important in response to a failed login\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 14]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- (there are widely-deployed clients which attempt to decode the error\r
- text of a PASS command result, to try and distinguish between "unable\r
- to get maildrop lock" and "bad login").\r
-\r
- This specification amends the POP3 standard to permit an optional\r
- response code, enclosed in square brackets, at the beginning of the\r
- human readable text portion of an "+OK" or "-ERR" response. Clients\r
- supporting this extension MAY remove any information enclosed in\r
- square brackets prior to displaying human readable text to the user.\r
- Immediately following the open square bracket "[" character is a\r
- response code which is interpreted in a case-insensitive fashion by\r
- the client.\r
-\r
- The response code is hierarchical, with a "/" separating levels of\r
- detail about the error. Clients MUST ignore unknown hierarchical\r
- detail about the response code. This is important, as it could be\r
- necessary to provide further detail for response codes in the future.\r
-\r
- Section 3 describes response codes using [ABNF].\r
-\r
- If a server supports extended response codes, it indicates this by\r
- including the RESP-CODES capability in the CAPA response.\r
-\r
- Examples:\r
- C: APOP mrose c4c9334bac560ecc979e58001b3e22fb\r
- S: -ERR [IN-USE] Do you have another POP session running?\r
-\r
-8.1. Initial POP3 response codes\r
-\r
- This specification defines two POP3 response codes which can be used\r
- to determine the reason for a failed login. Section 9 specifies how\r
- additional response codes are defined.\r
-\r
-8.1.1. The LOGIN-DELAY response code\r
-\r
- This occurs on an -ERR response to an AUTH, USER (see note), PASS or\r
- APOP command and indicates that the user has logged in recently and\r
- will not be allowed to login again until the login delay period has\r
- expired.\r
-\r
- NOTE: Returning the LOGIN-DELAY response code to the USER command\r
- avoids the work of authenticating the user but reveals to the client\r
- that the specified user exists. Unless the server is operating in an\r
- environment where user names are not secret (for example, many\r
- popular email clients advertise the POP server and user name in an\r
- outgoing mail header), or where server access is restricted, or the\r
- server can verify that the connection is to the same user, it is\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 15]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- strongly recommended that the server not issue this response code to\r
- the USER command. The server still saves the cost of opening the\r
- maildrop, which in some environments is the most expensive step.\r
-\r
-8.1.2. The IN-USE response code\r
-\r
- This occurs on an -ERR response to an AUTH, APOP, or PASS command.\r
- It indicates the authentication was successful, but the user's\r
- maildrop is currently in use (probably by another POP3 client).\r
-\r
-9. IANA Considerations\r
-\r
- This document requests that IANA maintain two new registries: POP3\r
- capabilities and POP3 response codes.\r
-\r
- New POP3 capabilities MUST be defined in a standards track or IESG\r
- approved experimental RFC, and MUST NOT begin with the letter "X".\r
-\r
- New POP3 capabilities MUST include the following information:\r
- CAPA tag\r
- Arguments\r
- Added commands\r
- Standard commands affected\r
- Announced states / possible differences\r
- Commands valid in states\r
- Specification reference\r
- Discussion\r
-\r
- In addition, new limits for POP3 command and response lengths may\r
- need to be included.\r
-\r
- New POP3 response codes MUST be defined in an RFC or other permanent\r
- and readily available reference, in sufficient detail so that\r
- interoperability between independent implementations is possible.\r
- (This is the "Specification Required" policy described in [IANA]).\r
-\r
- New POP3 response code specifications MUST include the following\r
- information: the complete response code, for which responses (+OK\r
- or -ERR) and commands it is valid, and a definition of its meaning and\r
- expected client behavior.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 16]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
-10. Security Considerations\r
-\r
- A capability list can reveal information about the server's\r
- authentication mechanisms which can be used to determine if certain\r
- attacks will be successful. However, allowing clients to\r
- automatically detect availability of stronger mechanisms and alter\r
- their configurations to use them can improve overall security at a\r
- site.\r
-\r
- Section 8.1 discusses the security issues related to use of the\r
- LOGIN-DELAY response code with the USER command.\r
-\r
-11. Acknowledgments\r
-\r
- This document has been revised in part based on comments and\r
- discussions which took place on and off the IETF POP3 Extensions\r
- mailing list. The help of those who took the time to review this\r
- memo and make suggestions is appreciated, especially that of Alexey\r
- Melnikov, Harald Alvestrand, and Mike Gahrns.\r
-\r
-12. References\r
-\r
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax\r
- Specifications: ABNF", RFC 2234, November 1997.\r
-\r
- [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an\r
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,\r
- October 1998.\r
-\r
- [IMAP4] Crispin, M., "Internet Message Access Protocol --\r
- Version 4rev1", RFC 2060, December 1996.\r
-\r
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate\r
- Requirement Levels", BCP 14, RFC 2119, March 1997.\r
-\r
- [PIPELINING] Freed, N., "SMTP Service Extension for Command\r
- Pipelining", RFC 2197, September 1997.\r
-\r
- [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version\r
- 3", STD 53, RFC 1939, May 1996.\r
-\r
- [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,\r
- December 1994.\r
-\r
- [SASL] Myers, J., "Simple Authentication and Security Layer\r
- (SASL)", RFC 2222, October 1997.\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 17]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
- [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC\r
- 821, August 1982.\r
-\r
-13. Authors' Addresses\r
-\r
- Randall Gellens\r
- QUALCOMM Incorporated\r
- 6455 Lusk Blvd.\r
- San Diego, CA 92121-2779\r
- USA\r
-\r
- Phone: +1 619 651 5115\r
- Fax: +1 619 845 7268\r
- EMail: randy@qualcomm.com\r
-\r
-\r
- Chris Newman\r
- Innosoft International, Inc.\r
- 1050 Lakes Drive\r
- West Covina, CA 91790\r
- USA\r
-\r
- EMail: chris.newman@innosoft.com\r
-\r
-\r
- Laurence Lundblade\r
- QUALCOMM Incorporated\r
- 6455 Lusk Blvd.\r
- San Diego, Ca, 92121-2779\r
- USA\r
-\r
- Phone: +1 619 658 3584\r
- Fax: +1 619 845 7268\r
- EMail: lgl@qualcomm.com\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 18]\r
-\f\r
-RFC 2449 POP3 Extension Mechanism November 1998\r
-\r
-\r
-14. Full Copyright Statement\r
-\r
- Copyright (C) The Internet Society (1998). All Rights Reserved.\r
-\r
- This document and translations of it may be copied and furnished to\r
- others, and derivative works that comment on or otherwise explain it\r
- or assist in its implementation may be prepared, copied, published\r
- and distributed, in whole or in part, without restriction of any\r
- kind, provided that the above copyright notice and this paragraph are\r
- included on all such copies and derivative works. However, this\r
- document itself may not be modified in any way, such as by removing\r
- the copyright notice or references to the Internet Society or other\r
- Internet organizations, except as needed for the purpose of\r
- developing Internet standards in which case the procedures for\r
- copyrights defined in the Internet Standards process must be\r
- followed, or as required to translate it into languages other than\r
- English.\r
-\r
- The limited permissions granted above are perpetual and will not be\r
- revoked by the Internet Society or its successors or assigns.\r
-\r
- This document and the information contained herein is provided on an\r
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Gellens, et. al. Standards Track [Page 19]\r
-\f\r
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-\r
-\r
-\r
-\r
-\r
-\r
-Network Working Group B. Leiba\r
-Request for Comments: 2683 IBM T.J. Watson Research Center\r
-Category: Informational September 1999\r
-\r
-\r
- IMAP4 Implementation Recommendations\r
-\r
-Status of this Memo\r
-\r
- This memo provides information for the Internet community. It does\r
- not specify an Internet standard of any kind. Distribution of this\r
- memo is unlimited.\r
-\r
-Copyright Notice\r
-\r
- Copyright (C) The Internet Society (1999). All Rights Reserved.\r
-\r
-1. Abstract\r
-\r
- The IMAP4 specification [RFC-2060] describes a rich protocol for use\r
- in building clients and servers for storage, retrieval, and\r
- manipulation of electronic mail. Because the protocol is so rich and\r
- has so many implementation choices, there are often trade-offs that\r
- must be made and issues that must be considered when designing such\r
- clients and servers. This document attempts to outline these issues\r
- and to make recommendations in order to make the end products as\r
- interoperable as possible.\r
-\r
-2. Conventions used in this document\r
-\r
- In examples, "C:" indicates lines sent by a client that is connected\r
- to a server. "S:" indicates lines sent by the server to the client.\r
-\r
- The words "must", "must not", "should", "should not", and "may" are\r
- used with specific meaning in this document; since their meaning is\r
- somewhat different from that specified in RFC 2119, we do not put\r
- them in all caps here. Their meaning is as follows:\r
-\r
- must -- This word means that the action described is necessary\r
- to ensure interoperability. The recommendation should\r
- not be ignored.\r
- must not -- This phrase means that the action described will be\r
- almost certain to hurt interoperability. The\r
- recommendation should not be ignored.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 1]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- should -- This word means that the action described is strongly\r
- recommended and will enhance interoperability or\r
- usability. The recommendation should not be ignored\r
- without careful consideration.\r
- should not -- This phrase means that the action described is strongly\r
- recommended against, and might hurt interoperability or\r
- usability. The recommendation should not be ignored\r
- without careful consideration.\r
- may -- This word means that the action described is an\r
- acceptable implementation choice. No specific\r
- recommendation is implied; this word is used to point\r
- out a choice that might not be obvious, or to let\r
- implementors know what choices have been made by\r
- existing implementations.\r
-\r
-3. Interoperability Issues and Recommendations\r
-\r
-3.1. Accessibility\r
-\r
- This section describes the issues related to access to servers and\r
- server resources. Concerns here include data sharing and maintenance\r
- of client/server connections.\r
-\r
-3.1.1. Multiple Accesses of the Same Mailbox\r
-\r
- One strong point of IMAP4 is that, unlike POP3, it allows for\r
- multiple simultaneous access to a single mailbox. A user can, thus,\r
- read mail from a client at home while the client in the office is\r
- still connected; or the help desk staff can all work out of the same\r
- inbox, all seeing the same pool of questions. An important point\r
- about this capability, though is that NO SERVER IS GUARANTEED TO\r
- SUPPORT THIS. If you are selecting an IMAP server and this facility\r
- is important to you, be sure that the server you choose to install,\r
- in the configuration you choose to use, supports it.\r
-\r
- If you are designing a client, you must not assume that you can\r
- access the same mailbox more than once at a time. That means\r
-\r
- 1. you must handle gracefully the failure of a SELECT command if the\r
- server refuses the second SELECT,\r
- 2. you must handle reasonably the severing of your connection (see\r
- "Severed Connections", below) if the server chooses to allow the\r
- second SELECT by forcing the first off,\r
- 3. you must avoid making multiple connections to the same mailbox in\r
- your own client (for load balancing or other such reasons), and\r
- 4. you must avoid using the STATUS command on a mailbox that you have\r
- selected (with some server implementations the STATUS command has\r
- the same problems with multiple access as do the SELECT and\r
-\r
-\r
-\r
-Leiba Informational [Page 2]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- EXAMINE commands).\r
-\r
- A further note about STATUS: The STATUS command is sometimes used to\r
- check a non-selected mailbox for new mail. This mechanism must not\r
- be used to check for new mail in the selected mailbox; section 5.2 of\r
- [RFC-2060] specifically forbids this in its last paragraph. Further,\r
- since STATUS takes a mailbox name it is an independent operation, not\r
- operating on the selected mailbox. Because of this, the information\r
- it returns is not necessarily in synchronization with the selected\r
- mailbox state.\r
-\r
-3.1.2. Severed Connections\r
-\r
- The client/server connection may be severed for one of three reasons:\r
- the client severs the connection, the server severs the connection,\r
- or the connection is severed by outside forces beyond the control of\r
- the client and the server (a telephone line drops, for example).\r
- Clients and servers must both deal with these situations.\r
-\r
- When the client wants to sever a connection, it's usually because it\r
- has finished the work it needed to do on that connection. The client\r
- should send a LOGOUT command, wait for the tagged response, and then\r
- close the socket. But note that, while this is what's intended in\r
- the protocol design, there isn't universal agreement here. Some\r
- contend that sending the LOGOUT and waiting for the two responses\r
- (untagged BYE and tagged OK) is wasteful and unnecessary, and that\r
- the client can simply close the socket. The server should interpret\r
- the closed socket as a log out by the client. The counterargument is\r
- that it's useful from the standpoint of cleanup, problem\r
- determination, and the like, to have an explicit client log out,\r
- because otherwise there is no way for the server to tell the\r
- difference between "closed socket because of log out" and "closed\r
- socket because communication was disrupted". If there is a\r
- client/server interaction problem, a client which routinely\r
- terminates a session by breaking the connection without a LOGOUT will\r
- make it much more difficult to determine the problem.\r
-\r
- Because of this disagreement, server designers must be aware that\r
- some clients might close the socket without sending a LOGOUT. In any\r
- case, whether or not a LOGOUT was sent, the server should not\r
- implicitly expunge any messages from the selected mailbox. If a\r
- client wants the server to do so, it must send a CLOSE or EXPUNGE\r
- command explicitly.\r
-\r
- When the server wants to sever a connection it's usually due to an\r
- inactivity timeout or is because a situation has arisen that has\r
- changed the state of the mail store in a way that the server can not\r
- communicate to the client. The server should send an untagged BYE\r
-\r
-\r
-\r
-Leiba Informational [Page 3]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- response to the client and then close the socket. Sending an\r
- untagged BYE response before severing allows the server to send a\r
- human-readable explanation of the problem to the client, which the\r
- client may then log, display to the user, or both (see section 7.1.5\r
- of [RFC-2060]).\r
-\r
- Regarding inactivity timeouts, there is some controversy. Unlike\r
- POP, for which the design is for a client to connect, retrieve mail,\r
- and log out, IMAP's design encourages long-lived (and mostly\r
- inactive) client/server sessions. As the number of users grows, this\r
- can use up a lot of server resources, especially with clients that\r
- are designed to maintain sessions for mailboxes that the user has\r
- finished accessing. To alleviate this, a server may implement an\r
- inactivity timeout, unilaterally closing a session (after first\r
- sending an untagged BYE, as noted above). Some server operators have\r
- reported dramatic improvements in server performance after doing\r
- this. As specified in [RFC-2060], if such a timeout is done it must\r
- not be until at least 30 minutes of inactivity. The reason for this\r
- specification is to prevent clients from sending commands (such as\r
- NOOP) to the server at frequent intervals simply to avert a too-early\r
- timeout. If the client knows that the server may not time out the\r
- session for at least 30 minutes, then the client need not poll at\r
- intervals more frequent than, say, 25 minutes.\r
-\r
-3.2. Scaling\r
-\r
- IMAP4 has many features that allow for scalability, as mail stores\r
- become larger and more numerous. Large numbers of users, mailboxes,\r
- and messages, and very large messages require thought to handle\r
- efficiently. This document will not address the administrative\r
- issues involved in large numbers of users, but we will look at the\r
- other items.\r
-\r
-3.2.1. Flood Control\r
-\r
- There are three situations when a client can make a request that will\r
- result in a very large response - too large for the client reasonably\r
- to deal with: there are a great many mailboxes available, there are a\r
- great many messages in the selected mailbox, or there is a very large\r
- message part. The danger here is that the end user will be stuck\r
- waiting while the server sends (and the client processes) an enormous\r
- response. In all of these cases there are things a client can do to\r
- reduce that danger.\r
-\r
- There is also the case where a client can flood a server, by sending\r
- an arbitratily long command. We'll discuss that issue, too, in this\r
- section.\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 4]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
-3.2.1.1. Listing Mailboxes\r
-\r
- Some servers present Usenet newsgroups to IMAP users. Newsgroups,\r
- and other such hierarchical mailbox structures, can be very numerous\r
- but may have only a few entries at the top level of hierarchy. Also,\r
- some servers are built against mail stores that can, unbeknownst to\r
- the server, have circular hierarchies - that is, it's possible for\r
- "a/b/c/d" to resolve to the same file structure as "a", which would\r
- then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy\r
- will never end. The LIST response in this case will be unlimited.\r
-\r
- Clients that will have trouble with this are those that use\r
-\r
- C: 001 LIST "" *\r
-\r
- to determine the mailbox list. Because of this, clients should not\r
- use an unqualified "*" that way in the LIST command. A safer\r
- approach is to list each level of hierarchy individually, allowing\r
- the user to traverse the tree one limb at a time, thus:\r
-\r
- C: 001 LIST "" %\r
- S: * LIST () "/" Banana\r
- S: * LIST ...etc...\r
- S: 001 OK done\r
-\r
- and then\r
-\r
- C: 002 LIST "" Banana/%\r
- S: * LIST () "/" Banana/Apple\r
- S: * LIST ...etc...\r
- S: 002 OK done\r
-\r
- Using this technique the client's user interface can give the user\r
- full flexibility without choking on the voluminous reply to "LIST *".\r
-\r
- Of course, it is still possible that the reply to\r
-\r
- C: 005 LIST "" alt.fan.celebrity.%\r
-\r
- may be thousands of entries long, and there is, unfortunately,\r
- nothing the client can do to protect itself from that. This has not\r
- yet been a notable problem.\r
-\r
- Servers that may export circular hierarchies (any server that\r
- directly presents a UNIX file system, for instance) should limit the\r
- hierarchy depth to prevent unlimited LIST responses. A suggested\r
- depth limit is 20 hierarchy levels.\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 5]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
-3.2.1.2. Fetching the List of Messages\r
-\r
- When a client selects a mailbox, it is given a count, in the untagged\r
- EXISTS response, of the messages in the mailbox. This number can be\r
- very large. In such a case it might be unwise to use\r
-\r
- C: 004 FETCH 1:* ALL\r
-\r
- to populate the user's view of the mailbox. One good method to avoid\r
- problems with this is to batch the requests, thus:\r
-\r
- C: 004 FETCH 1:50 ALL\r
- S: * 1 FETCH ...etc...\r
- S: 004 OK done\r
- C: 005 FETCH 51:100 ALL\r
- S: * 51 FETCH ...etc...\r
- S: 005 OK done\r
- C: 006 FETCH 101:150 ALL\r
- ...etc...\r
-\r
- Using this method, another command, such as "FETCH 6 BODY[1]" can be\r
- inserted as necessary, and the client will not have its access to the\r
- server blocked by a storm of FETCH replies. (Such a method could be\r
- reversed to fetch the LAST 50 messages first, then the 50 prior to\r
- that, and so on.)\r
-\r
- As a smart extension of this, a well designed client, prepared for\r
- very large mailboxes, will not automatically fetch data for all\r
- messages AT ALL. Rather, the client will populate the user's view\r
- only as the user sees it, possibly pre-fetching selected information,\r
- and only fetching other information as the user scrolls to it. For\r
- example, to select only those messages beginning with the first\r
- unseen one:\r
-\r
- C: 003 SELECT INBOX\r
- S: * 10000 EXISTS\r
- S: * 80 RECENT\r
- S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)\r
- S: * OK [UIDVALIDITY 824708485] UID validity status\r
- S: * OK [UNSEEN 9921] First unseen message\r
- S: 003 OK [READ-WRITE] SELECT completed\r
- C: 004 FETCH 9921:* ALL\r
- ... etc...\r
-\r
- If the server does not return an OK [UNSEEN] response, the client may\r
- use SEARCH UNSEEN to obtain that value.\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 6]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- This mechanism is good as a default presentation method, but only\r
- works well if the default message order is acceptable. A client may\r
- want to present various sort orders to the user (by subject, by date\r
- sent, by sender, and so on) and in that case (lacking a SORT\r
- extension on the server side) the client WILL have to retrieve all\r
- message descriptors. A client that provides this service should not\r
- do it by default and should inform the user of the costs of choosing\r
- this option for large mailboxes.\r
-\r
-3.2.1.3. Fetching a Large Body Part\r
-\r
- The issue here is similar to the one for a list of messages. In the\r
- BODYSTRUCTURE response the client knows the size, in bytes, of the\r
- body part it plans to fetch. Suppose this is a 70 MB video clip. The\r
- client can use partial fetches to retrieve the body part in pieces,\r
- avoiding the problem of an uninterruptible 70 MB literal coming back\r
- from the server:\r
-\r
- C: 022 FETCH 3 BODY[1]<0.20000>\r
- S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}\r
- S: ...data...)\r
- S: 022 OK done\r
- C: 023 FETCH 3 BODY[1]<20001.20000>\r
- S: * 3 FETCH (BODY[1]<20001> {20000}\r
- S: ...data...)\r
- S: 023 OK done\r
- C: 024 FETCH 3 BODY[1]<40001.20000>\r
- ...etc...\r
-\r
-3.2.1.4. BODYSTRUCTURE vs. Entire Messages\r
-\r
- Because FETCH BODYSTRUCTURE is necessary in order to determine the\r
- number of body parts, and, thus, whether a message has "attachments",\r
- clients often use FETCH FULL as their normal method of populating the\r
- user's view of a mailbox. The benefit is that the client can display\r
- a paperclip icon or some such indication along with the normal\r
- message summary. However, this comes at a significant cost with some\r
- server configurations. The parsing needed to generate the FETCH\r
- BODYSTRUCTURE response may be time-consuming compared with that\r
- needed for FETCH ENVELOPE. The client developer should consider this\r
- issue when deciding whether the ability to add a paperclip icon is\r
- worth the tradeoff in performance, especially with large mailboxes.\r
-\r
- Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]\r
- (or the equivalent FETCH RFC822) to retrieve the entire message.\r
- They then do the MIME parsing in the client. This may give the\r
- client slightly more flexibility in some areas (access, for instance,\r
- to header fields that aren't returned in the BODYSTRUCTURE and\r
-\r
-\r
-\r
-Leiba Informational [Page 7]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- ENVELOPE responses), but it can cause severe performance problems by\r
- forcing the transfer of all body parts when the user might only want\r
- to see some of them - a user logged on by modem and reading a small\r
- text message with a large ZIP file attached may prefer to read the\r
- text only and save the ZIP file for later. Therefore, a client\r
- should not normally retrieve entire messages and should retrieve\r
- message body parts selectively.\r
-\r
-3.2.1.5. Long Command Lines\r
-\r
- A client can wind up building a very long command line in an effort to\r
- try to be efficient about requesting information from a server. This\r
- can typically happen when a client builds a message set from selected\r
- messages and doesn't recognise that contiguous blocks of messages may\r
- be group in a range. Suppose a user selects all 10,000 messages in a\r
- large mailbox and then unselects message 287. The client could build\r
- that message set as "1:286,288:10000", but a client that doesn't\r
- handle that might try to enumerate each message individually and build\r
- "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command\r
- results in a command line that's almost 49,000 octets long, and,\r
- clearly, one can construct a command line that's even longer.\r
-\r
- A client should limit the length of the command lines it generates to\r
- approximately 1000 octets (including all quoted strings but not\r
- including literals). If the client is unable to group things into\r
- ranges so that the command line is within that length, it should\r
- split the request into multiple commands. The client should use\r
- literals instead of long quoted strings, in order to keep the command\r
- length down.\r
-\r
- For its part, a server should allow for a command line of at least\r
- 8000 octets. This provides plenty of leeway for accepting reasonable\r
- length commands from clients. The server should send a BAD response\r
- to a command that does not end within the server's maximum accepted\r
- command length.\r
-\r
-3.2.2. Subscriptions\r
-\r
- The client isn't the only entity that can get flooded: the end user,\r
- too, may need some flood control. The IMAP4 protocol provides such\r
- control in the form of subscriptions. Most servers support the\r
- SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to\r
- narrow down a large list of available mailboxes by subscribing to the\r
- ones that they usually want to see. Clients, with this in mind,\r
- should give the user a way to see only subscribed mailboxes. A\r
- client that never uses the LSUB command takes a significant usability\r
- feature away from the user. Of course, the client would not want to\r
- hide the LIST command completely; the user needs to have a way to\r
-\r
-\r
-\r
-Leiba Informational [Page 8]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- choose between LIST and LSUB. The usual way to do this is to provide\r
- a setting like "show which mailboxes?: [] all [] subscribed only".\r
-\r
-3.2.3. Searching\r
-\r
- IMAP SEARCH commands can become particularly troublesome (that is,\r
- slow) on mailboxes containing a large number of messages. So let's\r
- put a few things in perspective in that regard.\r
-\r
- The flag searches should be fast. The flag searches (ALL, [UN]SEEN,\r
- [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)\r
- are known to be used by clients for the client's own use (for\r
- instance, some clients use "SEARCH UNSEEN" to find unseen mail and\r
- "SEARCH DELETED" to warn the user before expunging messages).\r
-\r
- Other searches, particularly the text searches (HEADER, TEXT, BODY)\r
- are initiated by the user, rather than by the client itself, and\r
- somewhat slower performance can be tolerated, since the user is aware\r
- that the search is being done (and is probably aware that it might be\r
- time-consuming). A smart server might use dynamic indexing to speed\r
- commonly used text searches.\r
-\r
- The client may allow other commands to be sent to the server while a\r
- SEARCH is in progress, but at the time of this writing there is\r
- little or no server support for parallel processing of multiple\r
- commands in the same session (and see "Multiple Accesses of the Same\r
- Mailbox" above for a description of the dangers of trying to work\r
- around this by doing your SEARCH in another session).\r
-\r
- Another word about text searches: some servers, built on database\r
- back-ends with indexed search capabilities, may return search results\r
- that do not match the IMAP spec's "case-insensitive substring"\r
- requirements. While these servers are in violation of the protocol,\r
- there is little harm in the violation as long as the search results\r
- are used only in response to a user's request. Still, developers of\r
- such servers should be aware that they ARE violating the protocol,\r
- should think carefully about that behaviour, and must be certain that\r
- their servers respond accurately to the flag searches for the reasons\r
- outlined above.\r
-\r
- In addition, servers should support CHARSET UTF-8 [UTF-8] in\r
- searches.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 9]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
-3.3 Avoiding Invalid Requests\r
-\r
- IMAP4 provides ways for a server to tell a client in advance what is\r
- and isn't permitted in some circumstances. Clients should use these\r
- features to avoid sending requests that a well designed client would\r
- know to be invalid. This section explains this in more detail.\r
-\r
-3.3.1. The CAPABILITY Command\r
-\r
- All IMAP4 clients should use the CAPABILITY command to determine what\r
- version of IMAP and what optional features a server supports. The\r
- client should not send IMAP4rev1 commands and arguments to a server\r
- that does not advertize IMAP4rev1 in its CAPABILITY response.\r
- Similarly, the client should not send IMAP4 commands that no longer\r
- exist in IMAP4rev1 to a server that does not advertize IMAP4 in its\r
- CAPABILITY response. An IMAP4rev1 server is NOT required to support\r
- obsolete IMAP4 or IMAP2bis commands (though some do; do not let this\r
- fact lull you into thinking that it's valid to send such commands to\r
- an IMAP4rev1 server).\r
-\r
- A client should not send commands to probe for the existance of\r
- certain extensions. All standard and standards-track extensions\r
- include CAPABILITY tokens indicating their presense. All private and\r
- experimental extensions should do the same, and clients that take\r
- advantage of them should use the CAPABILITY response to determine\r
- whether they may be used or not.\r
-\r
-3.3.2. Don't Do What the Server Says You Can't\r
-\r
- In many cases, the server, in response to a command, will tell the\r
- client something about what can and can't be done with a particular\r
- mailbox. The client should pay attention to this information and\r
- should not try to do things that it's been told it can't do.\r
-\r
- Examples:\r
-\r
- * Do not try to SELECT a mailbox that has the \Noselect flag set.\r
- * Do not try to CREATE a sub-mailbox in a mailbox that has the\r
- \Noinferiors flag set.\r
- * Do not respond to a failing COPY or APPEND command by trying to\r
- CREATE the target mailbox if the server does not respond with a\r
- [TRYCREATE] response code.\r
- * Do not try to expunge a mailbox that has been selected with the\r
- [READ-ONLY] response code.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 10]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
-3.4. Miscellaneous Protocol Considerations\r
-\r
- We describe here a number of important protocol-related issues, the\r
- misunderstanding of which has caused significant interoperability\r
- problems in IMAP4 implementations. One general item is that every\r
- implementer should be certain to take note of and to understand\r
- section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec\r
- [RFC-2060].\r
-\r
-3.4.1. Well Formed Protocol\r
-\r
- We cannot stress enough the importance of adhering strictly to the\r
- protocol grammar. The specification of the protocol is quite rigid;\r
- do not assume that you can insert blank space for "readability" if\r
- none is called for. Keep in mind that there are parsers out there\r
- that will crash if there are protocol errors. There are clients that\r
- will report every parser burp to the user. And in any case,\r
- information that cannot be parsed is information that is lost. Be\r
- careful in your protocol generation. And see "A Word About Testing",\r
- below.\r
-\r
- In particular, note that the string in the INTERNALDATE response is\r
- NOT an RFC-822 date string - that is, it is not in the same format as\r
- the first string in the ENVELOPE response. Since most clients will,\r
- in fact, accept an RFC-822 date string in the INTERNALDATE response,\r
- it's easy to miss this in your interoperability testing. But it will\r
- cause a problem with some client, so be sure to generate the correct\r
- string for this field.\r
-\r
-3.4.2. Special Characters\r
-\r
- Certain characters, currently the double-quote and the backslash, may\r
- not be sent as-is inside a quoted string. These characters must be\r
- preceded by the escape character if they are in a quoted string, or\r
- else the string must be sent as a literal. Both clients and servers\r
- must handle this, both on output (they must send these characters\r
- properly) and on input (they must be able to receive escaped\r
- characters in quoted strings). Example:\r
-\r
- C: 001 LIST "" %\r
- S: * LIST () "" INBOX\r
- S: * LIST () "\\" TEST\r
- S: * LIST () "\\" {12}\r
- S: "My" mailbox\r
- S: 001 OK done\r
- C: 002 LIST "" "\"My\" mailbox\\%"\r
- S: * LIST () "\\" {17}\r
- S: "My" mailbox\Junk\r
-\r
-\r
-\r
-Leiba Informational [Page 11]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- S: 002 OK done\r
-\r
- Note that in the example the server sent the hierarchy delimiter as\r
- an escaped character in the quoted string and sent the mailbox name\r
- containing imbedded double-quotes as a literal. The client used only\r
- quoted strings, escaping both the backslash and the double-quote\r
- characters.\r
-\r
- The CR and LF characters may be sent ONLY in literals; they are not\r
- allowed, even if escaped, inside quoted strings.\r
-\r
- And while we're talking about special characters: the IMAP spec, in\r
- the section titled "Mailbox International Naming Convention",\r
- describes how to encode mailbox names in modified UTF-7 [UTF-7 and\r
- RFC-2060]. Implementations must adhere to this in order to be\r
- interoperable in the international market, and servers should\r
- validate mailbox names sent by client and reject names that do not\r
- conform.\r
-\r
- As to special characters in userids and passwords: clients must not\r
- restrict what a user may type in for a userid or a password. The\r
- formal grammar specifies that these are "astrings", and an astring\r
- can be a literal. A literal, in turn can contain any 8-bit\r
- character, and clients must allow users to enter all 8-bit characters\r
- here, and must pass them, unchanged, to the server (being careful to\r
- send them as literals when necessary). In particular, some server\r
- configurations use "@" in user names, and some clients do not allow\r
- that character to be entered; this creates a severe interoperability\r
- problem.\r
-\r
-3.4.3. UIDs and UIDVALIDITY\r
-\r
- Servers that support existing back-end mail stores often have no good\r
- place to save UIDs for messages. Often the existing mail store will\r
- not have the concept of UIDs in the sense that IMAP has: strictly\r
- increasing, never re-issued, 32-bit integers. Some servers solve\r
- this by storing the UIDs in a place that's accessible to end users,\r
- allowing for the possibility that the users will delete them. Others\r
- solve it by re-assigning UIDs every time a mailbox is selected.\r
-\r
- The server should maintain UIDs permanently for all messages if it\r
- can. If that's not possible, the server must change the UIDVALIDITY\r
- value for the mailbox whenever any of the UIDs may have become\r
- invalid. Clients must recognize that the UIDVALIDITY has changed and\r
- must respond to that condition by throwing away any information that\r
- they have saved about UIDs in that mailbox. There have been many\r
- problems in this area when clients have failed to do this; in the\r
- worst case it will result in loss of mail when a client deletes the\r
-\r
-\r
-\r
-Leiba Informational [Page 12]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- wrong piece of mail by using a stale UID.\r
-\r
- It seems to be a common misunderstanding that "the UIDVALIDITY and\r
- the UID, taken together, form a 64-bit identifier that uniquely\r
- identifies a message on a server". This is absolutely NOT TRUE.\r
- There is no assurance that the UIDVALIDITY values of two mailboxes be\r
- different, so the UIDVALIDITY in no way identifies a mailbox. The\r
- ONLY purpose of UIDVALIDITY is, as its name indicates, to give the\r
- client a way to check the validity of the UIDs it has cached. While\r
- it is a valid implementation choice to put these values together to\r
- make a 64-bit identifier for the message, the important concept here\r
- is that UIDs are not unique between mailboxes; they are only unique\r
- WITHIN a given mailbox.\r
-\r
- Some server implementations have attempted to make UIDs unique across\r
- the entire server. This is inadvisable, in that it limits the life\r
- of UIDs unnecessarily. The UID is a 32-bit number and will run out\r
- in reasonably finite time if it's global across the server. If you\r
- assign UIDs sequentially in one mailbox, you will not have to start\r
- re-using them until you have had, at one time or another, 2**32\r
- different messages in that mailbox. In the global case, you will\r
- have to reuse them once you have had, at one time or another, 2**32\r
- different messages in the entire mail store. Suppose your server has\r
- around 8000 users registered (2**13). That gives an average of 2**19\r
- UIDs per user. Suppose each user gets 32 messages (2**5) per day.\r
- That gives you 2**14 days (16000+ days = about 45 years) before you\r
- run out. That may seem like enough, but multiply the usage just a\r
- little (a lot of spam, a lot of mailing list subscriptions, more\r
- users) and you limit yourself too much.\r
-\r
- What's worse is that if you have to wrap the UIDs, and, thus, you\r
- have to change UIDVALIDITY and invalidate the UIDs in the mailbox,\r
- you have to do it for EVERY mailbox in the system, since they all\r
- share the same UID pool. If you assign UIDs per mailbox and you have\r
- a problem, you only have to kill the UIDs for that one mailbox.\r
-\r
- Under extreme circumstances (and this is extreme, indeed), the server\r
- may have to invalidate UIDs while a mailbox is in use by a client -\r
- that is, the UIDs that the client knows about in its active mailbox\r
- are no longer valid. In that case, the server must immediately\r
- change the UIDVALIDITY and must communicate this to the client. The\r
- server may do this by sending an unsolicited UIDVALIDITY message, in\r
- the same form as in response to the SELECT command. Clients must be\r
- prepared to handle such a message and the possibly coincident failure\r
- of the command in process. For example:\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 13]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- C: 032 UID STORE 382 +Flags.silent \Deleted\r
- S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!\r
- S: 032 NO UID command rejected because UIDVALIDITY changed!\r
- C: ...invalidates local information and re-fetches...\r
- C: 033 FETCH 1:* UID\r
- ...etc...\r
-\r
- At the time of the writing of this document, the only server known to\r
- do this does so only under the following condition: the client\r
- selects INBOX, but there is not yet a physical INBOX file created.\r
- Nonetheless, the SELECT succeeds, exporting an empty INBOX with a\r
- temporary UIDVALIDITY of 1. While the INBOX remains selected, mail\r
- is delivered to the user, which creates the real INBOX file and\r
- assigns a permanent UIDVALIDITY (that is likely not to be 1). The\r
- server reports the change of UIDVALIDITY, but as there were no\r
- messages before, so no UIDs have actually changed, all the client\r
- must do is accept the change in UIDVALIDITY.\r
-\r
- Alternatively, a server may force the client to re-select the\r
- mailbox, at which time it will obtain a new UIDVALIDITY value. To do\r
- this, the server closes this client session (see "Severed\r
- Connections" above) and the client then reconnects and gets back in\r
- synch. Clients must be prepared for either of these behaviours.\r
-\r
- We do not know of, nor do we anticipate the future existance of, a\r
- server that changes UIDVALIDITY while there are existing messages,\r
- but clients must be prepared to handle this eventuality.\r
-\r
-3.4.4. FETCH Responses\r
-\r
- When a client asks for certain information in a FETCH command, the\r
- server may return the requested information in any order, not\r
- necessarily in the order that it was requested. Further, the server\r
- may return the information in separate FETCH responses and may also\r
- return information that was not explicitly requested (to reflect to\r
- the client changes in the state of the subject message). Some\r
- examples:\r
-\r
- C: 001 FETCH 1 UID FLAGS INTERNALDATE\r
- S: * 5 FETCH (FLAGS (\Deleted))\r
- S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)\r
- S: 001 OK done\r
-\r
- (In this case, the responses are in a different order. Also, the\r
- server returned a flag update for message 5, which wasn't part of the\r
- client's request.)\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 14]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- C: 002 FETCH 2 UID FLAGS INTERNALDATE\r
- S: * 2 FETCH (INTERNALDATE "...")\r
- S: * 2 FETCH (UID 399)\r
- S: * 2 FETCH (FLAGS ())\r
- S: 002 OK done\r
-\r
- (In this case, the responses are in a different order and were\r
- returned in separate responses.)\r
-\r
- C: 003 FETCH 2 BODY[1]\r
- S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}\r
- S: Hello world!\r
- S: )\r
- S: 003 OK done\r
-\r
- (In this case, the FLAGS response was added by the server, since\r
- fetching the body part caused the server to set the \Seen flag.)\r
-\r
- Because of this characteristic a client must be ready to receive any\r
- FETCH response at any time and should use that information to update\r
- its local information about the message to which the FETCH response\r
- refers. A client must not assume that any FETCH responses will come\r
- in any particular order, or even that any will come at all. If after\r
- receiving the tagged response for a FETCH command the client finds\r
- that it did not get all of the information requested, the client\r
- should send a NOOP command to the server to ensure that the server\r
- has an opportunity to send any pending EXPUNGE responses to the\r
- client (see [RFC-2180]).\r
-\r
-3.4.5. RFC822.SIZE\r
-\r
- Some back-end mail stores keep the mail in a canonical form, rather\r
- than retaining the original MIME format of the messages. This means\r
- that the server must reassemble the message to produce a MIME stream\r
- when a client does a fetch such as RFC822 or BODY[], requesting the\r
- entire message. It also may mean that the server has no convenient\r
- way to know the RFC822.SIZE of the message. Often, such a server\r
- will actually have to build the MIME stream to compute the size, only\r
- to throw the stream away and report the size to the client.\r
-\r
- When this is the case, some servers have chosen to estimate the size,\r
- rather than to compute it precisely. Such an estimate allows the\r
- client to display an approximate size to the user and to use the\r
- estimate in flood control considerations (q.v.), but requires that\r
- the client not use the size for things such as allocation of buffers,\r
- because those buffers might then be too small to hold the actual MIME\r
- stream. Instead, a client should use the size that's returned in the\r
- literal when you fetch the data.\r
-\r
-\r
-\r
-Leiba Informational [Page 15]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- The protocol requires that the RFC822.SIZE value returned by the\r
- server be EXACT. Estimating the size is a protocol violation, and\r
- server designers must be aware that, despite the performance savings\r
- they might realize in using an estimate, this practice will cause\r
- some clients to fail in various ways. If possible, the server should\r
- compute the RFC822.SIZE for a particular message once, and then save\r
- it for later retrieval. If that's not possible, the server must\r
- compute the value exactly every time. Incorrect estimates do cause\r
- severe interoperability problems with some clients.\r
-\r
-3.4.6. Expunged Messages\r
-\r
- If the server allows multiple connections to the same mailbox, it is\r
- often possible for messages to be expunged in one client unbeknownst\r
- to another client. Since the server is not allowed to tell the\r
- client about these expunged messages in response to a FETCH command,\r
- the server may have to deal with the issue of how to return\r
- information about an expunged message. There was extensive\r
- discussion about this issue, and the results of that discussion are\r
- summarized in [RFC-2180]. See that reference for a detailed\r
- explanation and for recommendations.\r
-\r
-3.4.7. The Namespace Issue\r
-\r
- Namespaces are a very muddy area in IMAP4 implementation right now\r
- (see [NAMESPACE] for a proposal to clear the water a bit). Until the\r
- issue is resolved, the important thing for client developers to\r
- understand is that some servers provide access through IMAP to more\r
- than just the user's personal mailboxes, and, in fact, the user's\r
- personal mailboxes may be "hidden" somewhere in the user's default\r
- hierarchy. The client, therefore, should provide a setting wherein\r
- the user can specify a prefix to be used when accessing mailboxes. If\r
- the user's mailboxes are all in "~/mail/", for instance, then the\r
- user can put that string in the prefix. The client would then put\r
- the prefix in front of any name pattern in the LIST and LSUB\r
- commands:\r
-\r
- C: 001 LIST "" ~/mail/%\r
-\r
- (See also "Reference Names in the LIST Command" below.)\r
-\r
-3.4.8. Creating Special-Use Mailboxes\r
-\r
- It may seem at first that this is part of the namespace issue; it is\r
- not, and is only indirectly related to it. A number of clients like\r
- to create special-use mailboxes with particular names. Most\r
- commonly, clients with a "trash folder" model of message deletion\r
- want to create a mailbox with the name "Trash" or "Deleted". Some\r
-\r
-\r
-\r
-Leiba Informational [Page 16]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a\r
- "Sent Mail" mailbox. And so on. There are two major\r
- interoperability problems with this practice:\r
-\r
- 1. different clients may use different names for mailboxes with\r
- similar functions (such as "Trash" and "Deleted"), or may manage\r
- the same mailboxes in different ways, causing problems if a user\r
- switches between clients and\r
- 2. there is no guarantee that the server will allow the creation of\r
- the desired mailbox.\r
-\r
- The client developer is, therefore, well advised to consider\r
- carefully the creation of any special-use mailboxes on the server,\r
- and, further, the client must not require such mailbox creation -\r
- that is, if you do decide to do this, you must handle gracefully the\r
- failure of the CREATE command and behave reasonably when your\r
- special-use mailboxes do not exist and can not be created.\r
-\r
- In addition, the client developer should provide a convenient way for\r
- the user to select the names for any special-use mailboxes, allowing\r
- the user to make these names the same in all clients used and to put\r
- them where the user wants them.\r
-\r
-3.4.9. Reference Names in the LIST Command\r
-\r
- Many implementers of both clients and servers are confused by the\r
- "reference name" on the LIST command. The reference name is intended\r
- to be used in much the way a "cd" (change directory) command is used\r
- on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox\r
- name is interpreted in much the same way as a file of that name would\r
- be found if one had done a "cd" command into the directory specified\r
- by the reference name. For example, in Unix we have the following:\r
-\r
- > cd /u/jones/junk\r
- > vi banana [file is "/u/jones/junk/banana"]\r
- > vi stuff/banana [file is "/u/jones/junk/stuff/banana"]\r
- > vi /etc/hosts [file is "/etc/hosts"]\r
-\r
- In the past, there have been several interoperability problems with\r
- this. First, while some IMAP servers are built on Unix or PC file\r
- systems, many others are not, and the file system semantics do not\r
- make sense in those configurations. Second, while some IMAP servers\r
- expose the underlying file system to the clients, others allow access\r
- only to the user's personal mailboxes, or to some other limited set\r
- of files, making such file-system-like semantics less meaningful.\r
- Third, because the IMAP spec leaves the interpretation of the\r
- reference name as "implementation-dependent", in the past the various\r
- server implementations handled it in vastly differing ways.\r
-\r
-\r
-\r
-Leiba Informational [Page 17]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- The following recommendations are the result of significant\r
- operational experience, and are intended to maximize\r
- interoperability.\r
-\r
- Server implementations must implement the reference argument in a way\r
- that matches the intended "change directory" operation as closely as\r
- possible. As a minimum implementation, the reference argument may be\r
- prepended to the mailbox name (while suppressing double delimiters;\r
- see the next paragraph). Even servers that do not provide a way to\r
- break out of the current hierarchy (see "breakout facility" below)\r
- must provide a reasonable implementation of the reference argument,\r
- as described here, so that they will interoperate with clients that\r
- use it.\r
-\r
- Server implementations that prepend the reference argument to the\r
- mailbox name should insert a hierarchy delimiter between them, and\r
- must not insert a second if one is already present:\r
-\r
- C: A001 LIST ABC DEF\r
- S: * LIST () "/" ABC/DEF <=== should do this\r
- S: A001 OK done\r
-\r
- C: A002 LIST ABC/ /DEF\r
- S: * LIST () "/" ABC//DEF <=== must not do this\r
- S: A002 OK done\r
-\r
- On clients, the reference argument is chiefly used to implement a\r
- "breakout facility", wherein the user may directly access a mailbox\r
- outside the "current directory" hierarchy. Client implementations\r
- should have an operational mode that does not use the reference\r
- argument. This is to interoperate with older servers that did not\r
- implement the reference argument properly. While it's a good idea to\r
- give the user access to a breakout facility, clients that do not\r
- intend to do so should not use the reference argument at all.\r
-\r
- Client implementations should always place a trailing hierarchy\r
- delimiter on the reference argument. This is because some servers\r
- prepend the reference argument to the mailbox name without inserting\r
- a hierarchy delimiter, while others do insert a hierarchy delimiter\r
- if one is not already present. A client that puts the delimiter in\r
- will work with both varieties of server.\r
-\r
- Client implementations that implement a breakout facility should\r
- allow the user to choose whether or not to use a leading hierarchy\r
- delimiter on the mailbox argument. This is because the handling of a\r
- leading mailbox hierarchy delimiter also varies from server to\r
- server, and even between different mailstores on the same server. In\r
- some cases, a leading hierarchy delimiter means "discard the\r
-\r
-\r
-\r
-Leiba Informational [Page 18]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- reference argument" (implementing the intended breakout facility),\r
- thus:\r
-\r
- C: A001 LIST ABC/ /DEF\r
- S: * LIST () "/" /DEF\r
- S: A001 OK done\r
-\r
- In other cases, however, the two are catenated and the extra\r
- hierarchy delimiter is discarded, thus:\r
-\r
- C: A001 LIST ABC/ /DEF\r
- S: * LIST () "/" ABC/DEF\r
- S: A001 OK done\r
-\r
- Client implementations must not assume that the server supports a\r
- breakout facility, but may provide a way for the user to use one if\r
- it is available. Any breakout facility should be exported to the\r
- user interface. Note that there may be other "breakout" characters\r
- besides the hierarchy delimiter (for instance, UNIX filesystem\r
- servers are likely to use a leading "~" as well), and that their\r
- interpretation is server-dependent.\r
-\r
-3.4.10. Mailbox Hierarchy Delimiters\r
-\r
- The server's selection of what to use as a mailbox hierarchy\r
- delimiter is a difficult one, involving several issues: What\r
- characters do users expect to see? What characters can they enter\r
- for a hierarchy delimiter if it is desired (or required) that the\r
- user enter it? What character can be used for the hierarchy\r
- delimiter, noting that the chosen character can not otherwise be used\r
- in the mailbox name?\r
-\r
- Because some interfaces show users the hierarchy delimiters or allow\r
- users to enter qualified mailbox names containing them, server\r
- implementations should use delimiter characters that users generally\r
- expect to see as name separators. The most common characters used\r
- for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows\r
- file names), and "." (as in news groups). There is little to choose\r
- among these apart from what users may expect or what is dictated by\r
- the underlying file system, if any. One consideration about using\r
- "\" is that it's also a special character in the IMAP protocol. While\r
- the use of other hierarchy delimiter characters is permissible, A\r
- DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the\r
- server is intended for special purposes only. Implementers might be\r
- thinking about using characters such as "-", "_", ";", "&", "#", "@",\r
- and "!", but they should be aware of the surprise to the user as well\r
- as of the effect on URLs and other external specifications (since\r
- some of these characters have special meanings there). Also, a\r
-\r
-\r
-\r
-Leiba Informational [Page 19]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- server that uses "\" (and clients of such a server) must remember to\r
- escape that character in quoted strings or to send literals instead.\r
- Literals are recommended over escaped characters in quoted strings in\r
- order to maintain compatibility with older IMAP versions that did not\r
- allow escaped characters in quoted strings (but check the grammar to\r
- see where literals are allowed):\r
-\r
- C: 001 LIST "" {13}\r
- S: + send literal\r
- C: this\%\%\%\h*\r
- S: * LIST () "\\" {27}\r
- S: this\is\a\mailbox\hierarchy\r
- S: 001 OK LIST complete\r
-\r
- In any case, a server should not use normal alpha-numeric characters\r
- (such as "X" or "0") as delimiters; a user would be very surprised to\r
- find that "EXPENDITURES" actually represented a two-level hierarchy.\r
- And a server should not use characters that are non-printable or\r
- difficult or impossible to enter on a standard US keyboard. Control\r
- characters, box-drawing characters, and characters from non-US\r
- alphabets fit into this category. Their use presents\r
- interoperability problems that are best avoided.\r
-\r
- The UTF-7 encoding of mailbox names also raises questions about what\r
- to do with the hierarchy delimiters in encoded names: do we encode\r
- each hierarchy level and separate them with delimiters, or do we\r
- encode the fully qualified name, delimiters and all? The answer for\r
- IMAP is the former: encode each hierarchy level separately, and\r
- insert delimiters between. This makes it particularly important not\r
- to use as a hierarchy delimiter a character that might cause\r
- confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.\r
-\r
- To repeat: a server should use "/", "\", or "." as its hierarchy\r
- delimiter. The use of any other character is likely to cause\r
- problems and is STRONGLY DISCOURAGED.\r
-\r
-3.4.11. ALERT Response Codes\r
-\r
- The protocol spec is very clear on the matter of what to do with\r
- ALERT response codes, and yet there are many clients that violate it\r
- so it needs to be said anyway: "The human-readable text contains a\r
- special alert that must be presented to the user in a fashion that\r
- calls the user's attention to the message." That should be clear\r
- enough, but I'll repeat it here: Clients must present ALERT text\r
- clearly to the user.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 20]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
-3.4.12. Deleting Mailboxes\r
-\r
- The protocol does not guarantee that a client may delete a mailbox\r
- that is not empty, though on some servers it is permissible and is,\r
- in fact, much faster than the alternative or deleting all the\r
- messages from the client. If the client chooses to try to take\r
- advantage of this possibility it must be prepared to use the other\r
- method in the even that the more convenient one fails. Further, a\r
- client should not try to delete the mailbox that it has selected, but\r
- should first close that mailbox; some servers do not permit the\r
- deletion of the selected mailbox.\r
-\r
- That said, a server should permit the deletion of a non-empty\r
- mailbox; there's little reason to pass this work on to the client.\r
- Moreover, forbidding this prevents the deletion of a mailbox that for\r
- some reason can not be opened or expunged, leading to possible\r
- denial-of-service problems.\r
-\r
- Example:\r
-\r
- [User tells the client to delete mailbox BANANA, which is\r
- currently selected...]\r
- C: 008 CLOSE\r
- S: 008 OK done\r
- C: 009 DELETE BANANA\r
- S: 009 NO Delete failed; mailbox is not empty.\r
- C: 010 SELECT BANANA\r
- S: * ... untagged SELECT responses\r
- S: 010 OK done\r
- C: 011 STORE 1:* +FLAGS.SILENT \DELETED\r
- S: 011 OK done\r
- C: 012 CLOSE\r
- S: 012 OK done\r
- C: 013 DELETE BANANA\r
- S: 013 OK done\r
-\r
-3.5. A Word About Testing\r
-\r
- Since the whole point of IMAP is interoperability, and since\r
- interoperability can not be tested in a vacuum, the final\r
- recommendation of this treatise is, "Test against EVERYTHING." Test\r
- your client against every server you can get an account on. Test\r
- your server with every client you can get your hands on. Many\r
- clients make limited test versions available on the Web for the\r
- downloading. Many server owners will give serious client developers\r
- guest accounts for testing. Contact them and ask. NEVER assume that\r
- because your client works with one or two servers, or because your\r
- server does fine with one or two clients, you will interoperate well\r
-\r
-\r
-\r
-Leiba Informational [Page 21]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
- in general.\r
-\r
- In particular, in addition to everything else, be sure to test\r
- against the reference implementations: the PINE client, the\r
- University of Washington server, and the Cyrus server.\r
-\r
- See the following URLs on the web for more information here:\r
-\r
- IMAP Products and Sources: http://www.imap.org/products.html\r
- IMC MailConnect: http://www.imc.org/imc-mailconnect\r
-\r
-4. Security Considerations\r
-\r
- This document describes behaviour of clients and servers that use the\r
- IMAP4 protocol, and as such, has the same security considerations as\r
- described in [RFC-2060].\r
-\r
-5. References\r
-\r
- [RFC-2060] Crispin, M., "Internet Message Access Protocol - Version\r
- 4rev1", RFC 2060, December 1996.\r
-\r
- [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate\r
- Requirement Levels", BCP 14, RFC 2119, March 1997.\r
-\r
- [RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC\r
- 2180, July 1997.\r
-\r
- [UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode\r
- and ISO 10646", RFC 2044, October 1996.\r
-\r
- [UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe\r
- Transformation Format of Unicode", RFC 2152, May 1997.\r
-\r
- [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in\r
- Progress.\r
-\r
-6. Author's Address\r
-\r
- Barry Leiba\r
- IBM T.J. Watson Research Center\r
- 30 Saw Mill River Road\r
- Hawthorne, NY 10532\r
-\r
- Phone: 1-914-784-7941\r
- EMail: leiba@watson.ibm.com\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 22]\r
-\f\r
-RFC 2683 IMAP4 Implementation Recommendations September 1999\r
-\r
-\r
-7. Full Copyright Statement\r
-\r
- Copyright (C) The Internet Society (1999). All Rights Reserved.\r
-\r
- This document and translations of it may be copied and furnished to\r
- others, and derivative works that comment on or otherwise explain it\r
- or assist in its implementation may be prepared, copied, published\r
- and distributed, in whole or in part, without restriction of any\r
- kind, provided that the above copyright notice and this paragraph are\r
- included on all such copies and derivative works. However, this\r
- document itself may not be modified in any way, such as by removing\r
- the copyright notice or references to the Internet Society or other\r
- Internet organizations, except as needed for the purpose of\r
- developing Internet standards in which case the procedures for\r
- copyrights defined in the Internet Standards process must be\r
- followed, or as required to translate it into languages other than\r
- English.\r
-\r
- The limited permissions granted above are perpetual and will not be\r
- revoked by the Internet Society or its successors or assigns.\r
-\r
- This document and the information contained herein is provided on an\r
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-Acknowledgement\r
-\r
- Funding for the RFC Editor function is currently provided by the\r
- Internet Society.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Leiba Informational [Page 23]\r
-\f\r
+++ /dev/null
-
-
-
- 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
-\f
-\f
-
-
-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
-\f
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
-
-
-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]
-\f
-
-
-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
-\f
+++ /dev/null
-
-
-
-
-
-
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-\f
-
-
- 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
-\f
-
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-\f
-
-
- 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
-
+++ /dev/null
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
-
-
-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]
-\f
+++ /dev/null
-\r
-\r
-Network Working Group Brian Kantor (U.C. San Diego)\r
-Request for Comments: 977 Phil Lapsley (U.C. Berkeley)\r
- February 1986\r
-\r
- Network News Transfer Protocol\r
- \r
- A Proposed Standard for the Stream-Based\r
- Transmission of News\r
-\r
-Status of This Memo\r
-\r
- NNTP specifies a protocol for the distribution, inquiry, retrieval,\r
- and posting of news articles using a reliable stream-based\r
- transmission of news among the ARPA-Internet community. NNTP is\r
- designed so that news articles are stored in a central database\r
- allowing a subscriber to select only those items he wishes to read.\r
- Indexing, cross-referencing, and expiration of aged messages are also\r
- provided. This RFC suggests a proposed protocol for the ARPA-Internet\r
- community, and requests discussion and suggestions for improvements.\r
- Distribution of this memo is unlimited.\r
-\r
-1. Introduction\r
-\r
- For many years, the ARPA-Internet community has supported the\r
- distribution of bulletins, information, and data in a timely fashion\r
- to thousands of participants. We collectively refer to such items of\r
- information as "news". Such news provides for the rapid\r
- dissemination of items of interest such as software bug fixes, new\r
- product reviews, technical tips, and programming pointers, as well as\r
- rapid-fire discussions of matters of concern to the working computer\r
- professional. News is very popular among its readers.\r
-\r
- There are popularly two methods of distributing such news: the\r
- Internet method of direct mailing, and the USENET news system.\r
-\r
-1.1. Internet Mailing Lists\r
-\r
- The Internet community distributes news by the use of mailing lists.\r
- These are lists of subscriber's mailbox addresses and remailing\r
- sublists of all intended recipients. These mailing lists operate by\r
- remailing a copy of the information to be distributed to each\r
- subscriber on the mailing list. Such remailing is inefficient when a\r
- mailing list grows beyond a dozen or so people, since sending a\r
- separate copy to each of the subscribers occupies large quantities of\r
- network bandwidth, CPU resources, and significant amounts of disk\r
- storage at the destination host. There is also a significant problem\r
- in maintenance of the list itself: as subscribers move from one job\r
- to another; as new subscribers join and old ones leave; and as hosts\r
- come in and out of service.\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 1]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-1.2. The USENET News System\r
-\r
- Clearly, a worthwhile reduction of the amount of these resources used\r
- can be achieved if articles are stored in a central database on the\r
- receiving host instead of in each subscriber's mailbox. The USENET\r
- news system provides a method of doing just this. There is a central\r
- repository of the news articles in one place (customarily a spool\r
- directory of some sort), and a set of programs that allow a\r
- subscriber to select those items he wishes to read. Indexing,\r
- cross-referencing, and expiration of aged messages are also provided.\r
-\r
-1.3. Central Storage of News\r
-\r
- For clusters of hosts connected together by fast local area networks\r
- (such as Ethernet), it makes even more sense to consolidate news\r
- distribution onto one (or a very few) hosts, and to allow access to\r
- these news articles using a server and client model. Subscribers may\r
- then request only the articles they wish to see, without having to\r
- wastefully duplicate the storage of a copy of each item on each host.\r
-\r
-1.4. A Central News Server\r
-\r
- A way to achieve these economies is to have a central computer system\r
- that can provide news service to the other systems on the local area\r
- network. Such a server would manage the collection of news articles\r
- and index files, with each person who desires to read news bulletins\r
- doing so over the LAN. For a large cluster of computer systems, the\r
- savings in total disk space is clearly worthwhile. Also, this allows\r
- workstations with limited disk storage space to participate in the\r
- news without incoming items consuming oppressive amounts of the\r
- workstation's disk storage.\r
-\r
- We have heard rumors of somewhat successful attempts to provide\r
- centralized news service using IBIS and other shared or distributed\r
- file systems. While it is possible that such a distributed file\r
- system implementation might work well with a group of similar\r
- computers running nearly identical operating systems, such a scheme\r
- is not general enough to offer service to a wide range of client\r
- systems, especially when many diverse operating systems may be in use\r
- among a group of clients. There are few (if any) shared or networked\r
- file systems that can offer the generality of service that stream\r
- connections using Internet TCP provide, particularly when a wide\r
- range of host hardware and operating systems are considered.\r
-\r
- NNTP specifies a protocol for the distribution, inquiry, retrieval,\r
- and posting of news articles using a reliable stream (such as TCP)\r
- server-client model. NNTP is designed so that news articles need only\r
-\r
-\r
-Kantor & Lapsley [Page 2]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- be stored on one (presumably central) host, and subscribers on other\r
- hosts attached to the LAN may read news articles using stream\r
- connections to the news host.\r
-\r
- NNTP is modelled upon the news article specifications in RFC 850,\r
- which describes the USENET news system. However, NNTP makes few\r
- demands upon the structure, content, or storage of news articles, and\r
- thus we believe it easily can be adapted to other non-USENET news\r
- systems.\r
-\r
- Typically, the NNTP server runs as a background process on one host,\r
- and would accept connections from other hosts on the LAN. This works\r
- well when there are a number of small computer systems (such as\r
- workstations, with only one or at most a few users each), and a large\r
- central server.\r
-\r
-1.5. Intermediate News Servers\r
-\r
- For clusters of machines with many users (as might be the case in a\r
- university or large industrial environment), an intermediate server\r
- might be used. This intermediate or "slave" server runs on each\r
- computer system, and is responsible for mediating news reading\r
- requests and performing local caching of recently-retrieved news\r
- articles.\r
-\r
- Typically, a client attempting to obtain news service would first\r
- attempt to connect to the news service port on the local machine. If\r
- this attempt were unsuccessful, indicating a failed server, an\r
- installation might choose to either deny news access, or to permit\r
- connection to the central "master" news server.\r
-\r
- For workstations or other small systems, direct connection to the\r
- master server would probably be the normal manner of operation.\r
-\r
- This specification does not cover the operation of slave NNTP\r
- servers. We merely suggest that slave servers are a logical addition\r
- to NNTP server usage which would enhance operation on large local\r
- area networks.\r
-\r
-1.6. News Distribution\r
-\r
- NNTP has commands which provide a straightforward method of\r
- exchanging articles between cooperating hosts. Hosts which are well\r
- connected on a local area or other fast network and who wish to\r
- actually obtain copies of news articles for local storage might well\r
- find NNTP to be a more efficient way to distribute news than more\r
- traditional transfer methods (such as UUCP).\r
-\r
-\r
-Kantor & Lapsley [Page 3]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- In the traditional method of distributing news articles, news is\r
- propagated from host to host by flooding - that is, each host will\r
- send all its new news articles on to each host that it feeds. These\r
- hosts will then in turn send these new articles on to other hosts\r
- that they feed. Clearly, sending articles that a host already has\r
- obtained a copy of from another feed (many hosts that receive news\r
- are redundantly fed) again is a waste of time and communications\r
- resources, but for transport mechanisms that are single-transaction\r
- based rather than interactive (such as UUCP in the UNIX-world <1>),\r
- distribution time is diminished by sending all articles and having\r
- the receiving host simply discard the duplicates. This is an\r
- especially true when communications sessions are limited to once a\r
- day.\r
-\r
- Using NNTP, hosts exchanging news articles have an interactive\r
- mechanism for deciding which articles are to be transmitted. A host\r
- desiring new news, or which has new news to send, will typically\r
- contact one or more of its neighbors using NNTP. First it will\r
- inquire if any new news groups have been created on the serving host\r
- by means of the NEWGROUPS command. If so, and those are appropriate\r
- or desired (as established by local site-dependent rules), those new\r
- newsgroups can be created.\r
-\r
- The client host will then inquire as to which new articles have\r
- arrived in all or some of the newsgroups that it desires to receive,\r
- using the NEWNEWS command. It will receive a list of new articles\r
- from the server, and can request transmission of those articles that\r
- it desires and does not already have.\r
-\r
- Finally, the client can advise the server of those new articles which\r
- the client has recently received. The server will indicate those\r
- articles that it has already obtained copies of, and which articles\r
- should be sent to add to its collection.\r
-\r
- In this manner, only those articles which are not duplicates and\r
- which are desired are transferred.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 4]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-2. The NNTP Specification\r
-\r
-2.1. Overview\r
-\r
- The news server specified by this document uses a stream connection\r
- (such as TCP) and SMTP-like commands and responses. It is designed\r
- to accept connections from hosts, and to provide a simple interface\r
- to the news database.\r
-\r
- This server is only an interface between programs and the news\r
- databases. It does not perform any user interaction or presentation-\r
- level functions. These "user-friendly" functions are better left to\r
- the client programs, which have a better understanding of the\r
- environment in which they are operating.\r
-\r
- When used via Internet TCP, the contact port assigned for this\r
- service is 119.\r
-\r
-2.2. Character Codes\r
-\r
- Commands and replies are composed of characters from the ASCII\r
- character set. When the transport service provides an 8-bit byte\r
- (octet) transmission channel, each 7-bit character is transmitted\r
- right justified in an octet with the high order bit cleared to zero.\r
-\r
-2.3. Commands\r
-\r
- Commands consist of a command word, which in some cases may be\r
- followed by a parameter. Commands with parameters must separate the\r
- parameters from each other and from the command by one or more space\r
- or tab characters. Command lines must be complete with all required\r
- parameters, and may not contain more than one command.\r
-\r
- Commands and command parameters are not case sensitive. That is, a\r
- command or parameter word may be upper case, lower case, or any\r
- mixture of upper and lower case.\r
-\r
- Each command line must be terminated by a CR-LF (Carriage Return -\r
- Line Feed) pair.\r
-\r
- Command lines shall not exceed 512 characters in length, counting all\r
- characters including spaces, separators, punctuation, and the\r
- trailing CR-LF (thus there are 510 characters maximum allowed for the\r
- command and its parameters). There is no provision for continuation\r
- command lines.\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 5]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-2.4. Responses\r
-\r
- Responses are of two kinds, textual and status.\r
-\r
-2.4.1. Text Responses\r
-\r
- Text is sent only after a numeric status response line has been sent\r
- that indicates that text will follow. Text is sent as a series of\r
- successive lines of textual matter, each terminated with CR-LF pair.\r
- A single line containing only a period (.) is sent to indicate the\r
- end of the text (i.e., the server will send a CR-LF pair at the end\r
- of the last line of text, a period, and another CR-LF pair).\r
-\r
- If the text contained a period as the first character of the text\r
- line in the original, that first period is doubled. Therefore, the\r
- client must examine the first character of each line received, and\r
- for those beginning with a period, determine either that this is the\r
- end of the text or whether to collapse the doubled period to a single\r
- one.\r
-\r
- The intention is that text messages will usually be displayed on the\r
- user's terminal whereas command/status responses will be interpreted\r
- by the client program before any possible display is done.\r
-\r
-2.4.2. Status Responses\r
-\r
- These are status reports from the server and indicate the response to\r
- the last command received from the client.\r
-\r
- Status response lines begin with a 3 digit numeric code which is\r
- sufficient to distinguish all responses. Some of these may herald\r
- the subsequent transmission of text.\r
-\r
- The first digit of the response broadly indicates the success,\r
- failure, or progress of the previous command.\r
-\r
- 1xx - Informative message\r
- 2xx - Command ok\r
- 3xx - Command ok so far, send the rest of it.\r
- 4xx - Command was correct, but couldn't be performed for\r
- some reason.\r
- 5xx - Command unimplemented, or incorrect, or a serious\r
- program error occurred.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 6]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- The next digit in the code indicates the function response category.\r
-\r
- x0x - Connection, setup, and miscellaneous messages\r
- x1x - Newsgroup selection\r
- x2x - Article selection\r
- x3x - Distribution functions\r
- x4x - Posting\r
- x8x - Nonstandard (private implementation) extensions\r
- x9x - Debugging output\r
-\r
- The exact response codes that should be expected from each command\r
- are detailed in the description of that command. In addition, below\r
- is listed a general set of response codes that may be received at any\r
- time.\r
-\r
- Certain status responses contain parameters such as numbers and\r
- names. The number and type of such parameters is fixed for each\r
- response code to simplify interpretation of the response.\r
-\r
- Parameters are separated from the numeric response code and from each\r
- other by a single space. All numeric parameters are decimal, and may\r
- have leading zeros. All string parameters begin after the separating\r
- space, and end before the following separating space or the CR-LF\r
- pair at the end of the line. (String parameters may not, therefore,\r
- contain spaces.) All text, if any, in the response which is not a\r
- parameter of the response must follow and be separated from the last\r
- parameter by a space. Also, note that the text following a response\r
- number may vary in different implementations of the server. The\r
- 3-digit numeric code should be used to determine what response was\r
- sent.\r
-\r
- Response codes not specified in this standard may be used for any\r
- installation-specific additional commands also not specified. These\r
- should be chosen to fit the pattern of x8x specified above. (Note\r
- that debugging is provided for explicitly in the x9x response codes.)\r
- The use of unspecified response codes for standard commands is\r
- prohibited.\r
-\r
- We have provided a response pattern x9x for debugging. Since much\r
- debugging output may be classed as "informative messages", we would\r
- expect, therefore, that responses 190 through 199 would be used for\r
- various debugging outputs. There is no requirement in this\r
- specification for debugging output, but if such is provided over the\r
- connected stream, it must use these response codes. If appropriate\r
- to a specific implementation, other x9x codes may be used for\r
- debugging. (An example might be to use e.g., 290 to acknowledge a\r
- remote debugging request.)\r
-\r
-\r
-Kantor & Lapsley [Page 7]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-2.4.3. General Responses\r
-\r
- The following is a list of general response codes that may be sent by\r
- the NNTP server. These are not specific to any one command, but may\r
- be returned as the result of a connection, a failure, or some unusual\r
- condition.\r
-\r
- In general, 1xx codes may be ignored or displayed as desired; code\r
- 200 or 201 is sent upon initial connection to the NNTP server\r
- depending upon posting permission; code 400 will be sent when the\r
- NNTP server discontinues service (by operator request, for example);\r
- and 5xx codes indicate that the command could not be performed for\r
- some unusual reason.\r
-\r
- 100 help text\r
- 190\r
- through\r
- 199 debug output\r
-\r
- 200 server ready - posting allowed\r
- 201 server ready - no posting allowed\r
-\r
- 400 service discontinued\r
-\r
- 500 command not recognized\r
- 501 command syntax error\r
- 502 access restriction or permission denied\r
- 503 program fault - command not performed\r
-\r
-3. Command and Response Details\r
-\r
- On the following pages are descriptions of each command recognized by\r
- the NNTP server and the responses which will be returned by those\r
- commands.\r
-\r
- Each command is shown in upper case for clarity, although case is\r
- ignored in the interpretation of commands by the NNTP server. Any\r
- parameters are shown in lower case. A parameter shown in [square\r
- brackets] is optional. For example, [GMT] indicates that the\r
- triglyph GMT may present or omitted.\r
-\r
- Every command described in this section must be implemented by all\r
- NNTP servers.\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 8]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- There is no prohibition against additional commands being added;\r
- however, it is recommended that any such unspecified command begin\r
- with the letter "X" to avoid conflict with later revisions of this\r
- specification.\r
-\r
- Implementors are reminded that such additional commands may not\r
- redefine specified status response codes. Using additional\r
- unspecified responses for standard commands is also prohibited.\r
-\r
-3.1. The ARTICLE, BODY, HEAD, and STAT commands\r
-\r
- There are two forms to the ARTICLE command (and the related BODY,\r
- HEAD, and STAT commands), each using a different method of specifying\r
- which article is to be retrieved. When the ARTICLE command is\r
- followed by a message-id in angle brackets ("<" and ">"), the first\r
- form of the command is used; when a numeric parameter or no parameter\r
- is supplied, the second form is invoked.\r
-\r
- The text of the article is returned as a textual response, as\r
- described earlier in this document.\r
-\r
- The HEAD and BODY commands are identical to the ARTICLE command\r
- except that they respectively return only the header lines or text\r
- body of the article.\r
-\r
- The STAT command is similar to the ARTICLE command except that no\r
- text is returned. When selecting by message number within a group,\r
- the STAT command serves to set the current article pointer without\r
- sending text. The returned acknowledgement response will contain the\r
- message-id, which may be of some value. Using the STAT command to\r
- select by message-id is valid but of questionable value, since a\r
- selection by message-id does NOT alter the "current article pointer".\r
-\r
-3.1.1. ARTICLE (selection by message-id)\r
-\r
- ARTICLE <message-id>\r
-\r
- Display the header, a blank line, then the body (text) of the\r
- specified article. Message-id is the message id of an article as\r
- shown in that article's header. It is anticipated that the client\r
- will obtain the message-id from a list provided by the NEWNEWS\r
- command, from references contained within another article, or from\r
- the message-id provided in the response to some other commands.\r
-\r
- Please note that the internally-maintained "current article pointer"\r
- is NOT ALTERED by this command. This is both to facilitate the\r
- presentation of articles that may be referenced within an article\r
-\r
-\r
-Kantor & Lapsley [Page 9]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- being read, and because of the semantic difficulties of determining\r
- the proper sequence and membership of an article which may have been\r
- posted to more than one newsgroup.\r
-\r
-3.1.2. ARTICLE (selection by number)\r
-\r
- ARTICLE [nnn]\r
-\r
- Displays the header, a blank line, then the body (text) of the\r
- current or specified article. The optional parameter nnn is the\r
-\r
- numeric id of an article in the current newsgroup and must be chosen\r
- from the range of articles provided when the newsgroup was selected.\r
- If it is omitted, the current article is assumed.\r
-\r
- The internally-maintained "current article pointer" is set by this\r
- command if a valid article number is specified.\r
-\r
- [the following applies to both forms of the article command.] A\r
- response indicating the current article number, a message-id string,\r
- and that text is to follow will be returned.\r
-\r
- The message-id string returned is an identification string contained\r
- within angle brackets ("<" and ">"), which is derived from the header\r
- of the article itself. The Message-ID header line (required by\r
- RFC850) from the article must be used to supply this information. If\r
- the message-id header line is missing from the article, a single\r
- digit "0" (zero) should be supplied within the angle brackets.\r
-\r
- Since the message-id field is unique with each article, it may be\r
- used by a news reading program to skip duplicate displays of articles\r
- that have been posted more than once, or to more than one newsgroup.\r
-\r
-3.1.3. Responses\r
-\r
- 220 n <a> article retrieved - head and body follow\r
- (n = article number, <a> = message-id)\r
- 221 n <a> article retrieved - head follows\r
- 222 n <a> article retrieved - body follows\r
- 223 n <a> article retrieved - request text separately\r
- 412 no newsgroup has been selected\r
- 420 no current article has been selected\r
- 423 no such article number in this group\r
- 430 no such article found\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 10]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-3.2. The GROUP command\r
-\r
-3.2.1. GROUP\r
-\r
- GROUP ggg\r
-\r
- The required parameter ggg is the name of the newsgroup to be\r
- selected (e.g. "net.news"). A list of valid newsgroups may be\r
- obtained from the LIST command.\r
-\r
- The successful selection response will return the article numbers of\r
- the first and last articles in the group, and an estimate of the\r
- number of articles on file in the group. It is not necessary that\r
- the estimate be correct, although that is helpful; it must only be\r
- equal to or larger than the actual number of articles on file. (Some\r
- implementations will actually count the number of articles on file.\r
- Others will just subtract first article number from last to get an\r
- estimate.)\r
-\r
- When a valid group is selected by means of this command, the\r
- internally maintained "current article pointer" is set to the first\r
- article in the group. If an invalid group is specified, the\r
- previously selected group and article remain selected. If an empty\r
- newsgroup is selected, the "current article pointer" is in an\r
- indeterminate state and should not be used.\r
-\r
- Note that the name of the newsgroup is not case-dependent. It must\r
- otherwise match a newsgroup obtained from the LIST command or an\r
- error will result.\r
-\r
-3.2.2. Responses\r
-\r
- 211 n f l s group selected\r
- (n = estimated number of articles in group,\r
- f = first article number in the group,\r
- l = last article number in the group,\r
- s = name of the group.)\r
- 411 no such news group\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 11]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-3.3. The HELP command\r
-\r
-3.3.1. HELP\r
-\r
- HELP\r
-\r
- Provides a short summary of commands that are understood by this\r
- implementation of the server. The help text will be presented as a\r
- textual response, terminated by a single period on a line by itself.\r
-\r
- 3.3.2. Responses\r
-\r
- 100 help text follows\r
-\r
-3.4. The IHAVE command\r
-\r
-3.4.1. IHAVE\r
-\r
- IHAVE <messageid>\r
-\r
- The IHAVE command informs the server that the client has an article\r
- whose id is <messageid>. If the server desires a copy of that\r
- article, it will return a response instructing the client to send the\r
- entire article. If the server does not want the article (if, for\r
- example, the server already has a copy of it), a response indicating\r
- that the article is not wanted will be returned.\r
-\r
- If transmission of the article is requested, the client should send\r
- the entire article, including header and body, in the manner\r
- specified for text transmission from the server. A response code\r
- indicating success or failure of the transferral of the article will\r
- be returned.\r
-\r
- This function differs from the POST command in that it is intended\r
- for use in transferring already-posted articles between hosts.\r
- Normally it will not be used when the client is a personal\r
- newsreading program. In particular, this function will invoke the\r
- server's news posting program with the appropriate settings (flags,\r
- options, etc) to indicate that the forthcoming article is being\r
- forwarded from another host.\r
-\r
- The server may, however, elect not to post or forward the article if\r
- after further examination of the article it deems it inappropriate to\r
- do so. The 436 or 437 error codes may be returned as appropriate to\r
- the situation.\r
-\r
- Reasons for such subsequent rejection of an article may include such\r
-\r
-\r
-Kantor & Lapsley [Page 12]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- problems as inappropriate newsgroups or distributions, disk space\r
- limitations, article lengths, garbled headers, and the like. These\r
- are typically restrictions enforced by the server host's news\r
- software and not necessarily the NNTP server itself.\r
-\r
-3.4.2. Responses\r
-\r
- 235 article transferred ok\r
- 335 send article to be transferred. End with <CR-LF>.<CR-LF>\r
- 435 article not wanted - do not send it\r
- 436 transfer failed - try again later\r
- 437 article rejected - do not try again\r
-\r
- An implementation note:\r
-\r
- Because some host news posting software may not be able to decide\r
- immediately that an article is inappropriate for posting or\r
- forwarding, it is acceptable to acknowledge the successful transfer\r
- of the article and to later silently discard it. Thus it is\r
- permitted to return the 235 acknowledgement code and later discard\r
- the received article. This is not a fully satisfactory solution to\r
- the problem. Perhaps some implementations will wish to send mail to\r
- the author of the article in certain of these cases.\r
-\r
-3.5. The LAST command\r
-\r
-3.5.1. LAST\r
-\r
- LAST\r
-\r
- The internally maintained "current article pointer" is set to the\r
- previous article in the current newsgroup. If already positioned at\r
- the first article of the newsgroup, an error message is returned and\r
- the current article remains selected.\r
-\r
- The internally-maintained "current article pointer" is set by this\r
- command.\r
-\r
- A response indicating the current article number, and a message-id\r
- string will be returned. No text is sent in response to this\r
- command.\r
-\r
-3.5.2. Responses\r
-\r
- 223 n a article retrieved - request text separately\r
- (n = article number, a = unique article id)\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 13]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- 412 no newsgroup selected\r
- 420 no current article has been selected\r
- 422 no previous article in this group\r
-\r
-3.6. The LIST command\r
-\r
-3.6.1. LIST\r
-\r
- LIST\r
-\r
- Returns a list of valid newsgroups and associated information. Each\r
- newsgroup is sent as a line of text in the following format:\r
-\r
- group last first p\r
-\r
- where <group> is the name of the newsgroup, <last> is the number of\r
- the last known article currently in that newsgroup, <first> is the\r
- number of the first article currently in the newsgroup, and <p> is\r
- either 'y' or 'n' indicating whether posting to this newsgroup is\r
- allowed ('y') or prohibited ('n').\r
-\r
- The <first> and <last> fields will always be numeric. They may have\r
- leading zeros. If the <last> field evaluates to less than the\r
- <first> field, there are no articles currently on file in the\r
- newsgroup.\r
-\r
- Note that posting may still be prohibited to a client even though the\r
- LIST command indicates that posting is permitted to a particular\r
- newsgroup. See the POST command for an explanation of client\r
- prohibitions. The posting flag exists for each newsgroup because\r
- some newsgroups are moderated or are digests, and therefore cannot be\r
- posted to; that is, articles posted to them must be mailed to a\r
- moderator who will post them for the submitter. This is independent\r
- of the posting permission granted to a client by the NNTP server.\r
-\r
- Please note that an empty list (i.e., the text body returned by this\r
- command consists only of the terminating period) is a possible valid\r
- response, and indicates that there are currently no valid newsgroups.\r
-\r
-3.6.2. Responses\r
-\r
- 215 list of newsgroups follows\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 14]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-3.7. The NEWGROUPS command\r
-\r
-3.7.1. NEWGROUPS\r
-\r
- NEWGROUPS date time [GMT] [<distributions>]\r
-\r
- A list of newsgroups created since <date and time> will be listed in\r
- the same format as the LIST command.\r
-\r
- The date is sent as 6 digits in the format YYMMDD, where YY is the\r
- last two digits of the year, MM is the two digits of the month (with\r
- leading zero, if appropriate), and DD is the day of the month (with\r
- leading zero, if appropriate). The closest century is assumed as\r
- part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is\r
- 1999, 00 is 2000).\r
-\r
- Time must also be specified. It must be as 6 digits HHMMSS with HH\r
- being hours on the 24-hour clock, MM minutes 00-59, and SS seconds\r
- 00-59. The time is assumed to be in the server's timezone unless the\r
- token "GMT" appears, in which case both time and date are evaluated\r
- at the 0 meridian.\r
-\r
- The optional parameter "distributions" is a list of distribution\r
- groups, enclosed in angle brackets. If specified, the distribution\r
- portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be\r
- examined for a match with the distribution categories listed, and\r
- only those new newsgroups which match will be listed. If more than\r
- one distribution group is to be listed, they must be separated by\r
- commas within the angle brackets.\r
-\r
- Please note that an empty list (i.e., the text body returned by this\r
- command consists only of the terminating period) is a possible valid\r
- response, and indicates that there are currently no new newsgroups.\r
-\r
-3.7.2. Responses\r
-\r
- 231 list of new newsgroups follows\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 15]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-3.8. The NEWNEWS command\r
-\r
-3.8.1. NEWNEWS\r
-\r
- NEWNEWS newsgroups date time [GMT] [<distribution>]\r
-\r
- A list of message-ids of articles posted or received to the specified\r
- newsgroup since "date" will be listed. The format of the listing will\r
- be one message-id per line, as though text were being sent. A single\r
- line consisting solely of one period followed by CR-LF will terminate\r
- the list.\r
-\r
- Date and time are in the same format as the NEWGROUPS command.\r
-\r
- A newsgroup name containing a "*" (an asterisk) may be specified to\r
- broaden the article search to some or all newsgroups. The asterisk\r
- will be extended to match any part of a newsgroup name (e.g.,\r
- net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus\r
- if only an asterisk is given as the newsgroup name, all newsgroups\r
- will be searched for new news.\r
-\r
- (Please note that the asterisk "*" expansion is a general\r
- replacement; in particular, the specification of e.g., net.*.unix\r
- should be correctly expanded to embrace names such as net.wombat.unix\r
- and net.whocares.unix.)\r
-\r
- Conversely, if no asterisk appears in a given newsgroup name, only\r
- the specified newsgroup will be searched for new articles. Newsgroup\r
- names must be chosen from those returned in the listing of available\r
- groups. Multiple newsgroup names (including a "*") may be specified\r
- in this command, separated by a comma. No comma shall appear after\r
- the last newsgroup in the list. [Implementors are cautioned to keep\r
- the 512 character command length limit in mind.]\r
-\r
- The exclamation point ("!") may be used to negate a match. This can\r
- be used to selectively omit certain newsgroups from an otherwise\r
- larger list. For example, a newsgroups specification of\r
- "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and\r
- all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be\r
- matched. If used, the exclamation point must appear as the first\r
- character of the given newsgroup name or pattern.\r
-\r
- The optional parameter "distributions" is a list of distribution\r
- groups, enclosed in angle brackets. If specified, the distribution\r
- portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will\r
- be examined for a match with the distribution categories listed, and\r
- only those articles which have at least one newsgroup belonging to\r
-\r
-\r
-Kantor & Lapsley [Page 16]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- the list of distributions will be listed. If more than one\r
- distribution group is to be supplied, they must be separated by\r
- commas within the angle brackets.\r
-\r
- The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute\r
- news is discussed in an earlier part of this document.\r
-\r
- Please note that an empty list (i.e., the text body returned by this\r
- command consists only of the terminating period) is a possible valid\r
- response, and indicates that there is currently no new news.\r
-\r
-3.8.2. Responses\r
-\r
- 230 list of new articles by message-id follows\r
-\r
-3.9. The NEXT command\r
-\r
-3.9.1. NEXT\r
-\r
- NEXT\r
-\r
- The internally maintained "current article pointer" is advanced to\r
- the next article in the current newsgroup. If no more articles\r
- remain in the current group, an error message is returned and the\r
- current article remains selected.\r
-\r
- The internally-maintained "current article pointer" is set by this\r
- command.\r
-\r
- A response indicating the current article number, and the message-id\r
- string will be returned. No text is sent in response to this\r
- command.\r
-\r
-3.9.2. Responses\r
-\r
- 223 n a article retrieved - request text separately\r
- (n = article number, a = unique article id)\r
- 412 no newsgroup selected\r
- 420 no current article has been selected\r
- 421 no next article in this group\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 17]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-3.10. The POST command\r
-\r
-3.10.1. POST\r
-\r
- POST\r
-\r
- If posting is allowed, response code 340 is returned to indicate that\r
- the article to be posted should be sent. Response code 440 indicates\r
- that posting is prohibited for some installation-dependent reason.\r
-\r
- If posting is permitted, the article should be presented in the\r
- format specified by RFC850, and should include all required header\r
- lines. After the article's header and body have been completely sent\r
- by the client to the server, a further response code will be returned\r
- to indicate success or failure of the posting attempt.\r
-\r
- The text forming the header and body of the message to be posted\r
- should be sent by the client using the conventions for text received\r
- from the news server: A single period (".") on a line indicates the\r
- end of the text, with lines starting with a period in the original\r
- text having that period doubled during transmission.\r
-\r
- No attempt shall be made by the server to filter characters, fold or\r
- limit lines, or otherwise process incoming text. It is our intent\r
- that the server just pass the incoming message to be posted to the\r
- server installation's news posting software, which is separate from\r
- this specification. See RFC850 for more details.\r
-\r
- Since most installations will want the client news program to allow\r
- the user to prepare his message using some sort of text editor, and\r
- transmit it to the server for posting only after it is composed, the\r
- client program should take note of the herald message that greeted it\r
- when the connection was first established. This message indicates\r
- whether postings from that client are permitted or not, and can be\r
- used to caution the user that his access is read-only if that is the\r
- case. This will prevent the user from wasting a good deal of time\r
- composing a message only to find posting of the message was denied.\r
- The method and determination of which clients and hosts may post is\r
- installation dependent and is not covered by this specification.\r
-\r
-3.10.2. Responses\r
-\r
- 240 article posted ok\r
- 340 send article to be posted. End with <CR-LF>.<CR-LF>\r
- 440 posting not allowed\r
- 441 posting failed\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 18]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- (for reference, one of the following codes will be sent upon initial\r
- connection; the client program should determine whether posting is\r
- generally permitted from these:) 200 server ready - posting allowed\r
- 201 server ready - no posting allowed\r
-\r
-3.11. The QUIT command\r
-\r
-3.11.1. QUIT\r
-\r
- QUIT\r
-\r
- The server process acknowledges the QUIT command and then closes the\r
- connection to the client. This is the preferred method for a client\r
- to indicate that it has finished all its transactions with the NNTP\r
- server.\r
-\r
- If a client simply disconnects (or the connection times out, or some\r
- other fault occurs), the server should gracefully cease its attempts\r
- to service the client.\r
-\r
-3.11.2. Responses\r
-\r
- 205 closing connection - goodbye!\r
-\r
-3.12. The SLAVE command\r
-\r
-3.12.1. SLAVE\r
-\r
- SLAVE\r
-\r
- Indicates to the server that this client connection is to a slave\r
- server, rather than a user.\r
-\r
- This command is intended for use in separating connections to single\r
- users from those to subsidiary ("slave") servers. It may be used to\r
- indicate that priority should therefore be given to requests from\r
- this client, as it is presumably serving more than one person. It\r
- might also be used to determine which connections to close when\r
- system load levels are exceeded, perhaps giving preference to slave\r
- servers. The actual use this command is put to is entirely\r
- implementation dependent, and may vary from one host to another. In\r
- NNTP servers which do not give priority to slave servers, this\r
- command must nonetheless be recognized and acknowledged.\r
-\r
-3.12.2. Responses\r
-\r
- 202 slave status noted\r
-\r
-\r
-Kantor & Lapsley [Page 19]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-4. Sample Conversations\r
-\r
- These are samples of the conversations that might be expected with\r
- the news server in hypothetical sessions. The notation C: indicates\r
- commands sent to the news server from the client program; S: indicate\r
- responses received from the server by the client.\r
-\r
-4.1. Example 1 - relative access with NEXT\r
-\r
- S: (listens at TCP port 119)\r
-\r
- C: (requests connection on TCP port 119)\r
- S: 200 wombatvax news server ready - posting ok\r
-\r
- (client asks for a current newsgroup list)\r
- C: LIST\r
- S: 215 list of newsgroups follows\r
- S: net.wombats 00543 00501 y\r
- S: net.unix-wizards 10125 10011 y\r
- (more information here)\r
- S: net.idiots 00100 00001 n\r
- S: .\r
-\r
- (client selects a newsgroup)\r
- C: GROUP net.unix-wizards\r
- S: 211 104 10011 10125 net.unix-wizards group selected\r
- (there are 104 articles on file, from 10011 to 10125)\r
-\r
- (client selects an article to read)\r
- C: STAT 10110\r
- S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics\r
- only (article 10110 selected, its message-id is\r
- <23445@sdcsvax.ARPA>)\r
-\r
- (client examines the header)\r
- C: HEAD\r
- S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head\r
- follows (text of the header appears here)\r
- S: .\r
-\r
- (client wants to see the text body of the article)\r
- C: BODY\r
- S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body\r
- follows (body text here)\r
- S: .\r
-\r
- (client selects next article in group)\r
-\r
-\r
-Kantor & Lapsley [Page 20]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- C: NEXT\r
- S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics\r
- only (article 10113 was next in group)\r
-\r
- (client finishes session)\r
- C: QUIT\r
- S: 205 goodbye.\r
-\r
-4.2. Example 2 - absolute article access with ARTICLE\r
-\r
- S: (listens at TCP port 119)\r
-\r
- C: (requests connection on TCP port 119)\r
- S: 201 UCB-VAX netnews server ready -- no posting allowed\r
-\r
- C: GROUP msgs\r
- S: 211 103 402 504 msgs Your new group is msgs\r
- (there are 103 articles, from 402 to 504)\r
-\r
- C: ARTICLE 401\r
- S: 423 No such article in this newsgroup\r
-\r
- C: ARTICLE 402\r
- S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows\r
- S: (article header and body follow)\r
- S: .\r
-\r
- C: HEAD 403\r
- S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows\r
- S: (article header follows)\r
- S: .\r
-\r
- C: QUIT\r
- S: 205 UCB-VAX news server closing connection. Goodbye.\r
-\r
-4.3. Example 3 - NEWGROUPS command\r
-\r
- S: (listens at TCP port 119)\r
-\r
- C: (requests connection on TCP port 119)\r
- S: 200 Imaginary Institute News Server ready (posting ok)\r
-\r
- (client asks for new newsgroups since April 3, 1985)\r
- C: NEWGROUPS 850403 020000\r
-\r
- S: 231 New newsgroups since 03/04/85 02:00:00 follow\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 21]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- S: net.music.gdead\r
- S: net.games.sources\r
- S: .\r
-\r
- C: GROUP net.music.gdead\r
- S: 211 0 1 1 net.music.gdead Newsgroup selected\r
- (there are no articles in that newsgroup, and\r
- the first and last article numbers should be ignored)\r
-\r
- C: QUIT\r
- S: 205 Imaginary Institute news server ceasing service. Bye!\r
-\r
-4.4. Example 4 - posting a news article\r
-\r
- S: (listens at TCP port 119)\r
-\r
- C: (requests connection on TCP port 119)\r
- S: 200 BANZAIVAX news server ready, posting allowed.\r
-\r
- C: POST\r
- S: 340 Continue posting; Period on a line by itself to end\r
- C: (transmits news article in RFC850 format)\r
- C: .\r
- S: 240 Article posted successfully.\r
-\r
- C: QUIT\r
- S: 205 BANZAIVAX closing connection. Goodbye.\r
-\r
-4.5. Example 5 - interruption due to operator request\r
-\r
- S: (listens at TCP port 119)\r
-\r
- C: (requests connection on TCP port 119)\r
- S: 201 genericvax news server ready, no posting allowed.\r
-\r
- (assume normal conversation for some time, and\r
- that a newsgroup has been selected)\r
-\r
- C: NEXT\r
- S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.\r
-\r
- C: HEAD\r
- C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.\r
-\r
- S: (sends head of article, but halfway through is\r
- interrupted by an operator request. The following\r
- then occurs, without client intervention.)\r
-\r
-\r
-Kantor & Lapsley [Page 22]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- S: (ends current line with a CR-LF pair)\r
- S: .\r
- S: 400 Connection closed by operator. Goodbye.\r
- S: (closes connection)\r
-\r
-4.6. Example 6 - Using the news server to distribute news between\r
- systems.\r
-\r
- S: (listens at TCP port 119)\r
-\r
- C: (requests connection on TCP port 119)\r
- S: 201 Foobar NNTP server ready (no posting)\r
-\r
- (client asks for new newsgroups since 2 am, May 15, 1985)\r
- C: NEWGROUPS 850515 020000\r
- S: 235 New newsgroups since 850515 follow\r
- S: net.fluff\r
- S: net.lint\r
- S: .\r
-\r
- (client asks for new news articles since 2 am, May 15, 1985)\r
- C: NEWNEWS * 850515 020000\r
- S: 230 New news since 850515 020000 follows\r
- S: <1772@foo.UUCP>\r
- S: <87623@baz.UUCP>\r
- S: <17872@GOLD.CSNET>\r
- S: .\r
-\r
- (client asks for article <1772@foo.UUCP>)\r
- C: ARTICLE <1772@foo.UUCP>\r
- S: 220 <1772@foo.UUCP> All of article follows\r
- S: (sends entire message)\r
- S: .\r
-\r
- (client asks for article <87623@baz.UUCP>\r
- C: ARTICLE <87623@baz.UUCP>\r
- S: 220 <87623@baz.UUCP> All of article follows\r
- S: (sends entire message)\r
- S: .\r
-\r
- (client asks for article <17872@GOLD.CSNET>\r
- C: ARTICLE <17872@GOLD.CSNET>\r
- S: 220 <17872@GOLD.CSNET> All of article follows\r
- S: (sends entire message)\r
- S: .\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 23]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- (client offers an article it has received recently)\r
- C: IHAVE <4105@ucbvax.ARPA>\r
- S: 435 Already seen that one, where you been?\r
-\r
- (client offers another article)\r
- C: IHAVE <4106@ucbvax.ARPA>\r
- S: 335 News to me! <CRLF.CRLF> to end.\r
- C: (sends article)\r
- C: .\r
- S: 235 Article transferred successfully. Thanks.\r
-\r
- (or)\r
-\r
- S: 436 Transfer failed.\r
-\r
- (client is all through with the session)\r
- C: QUIT\r
- S: 205 Foobar NNTP server bids you farewell.\r
-\r
-4.7. Summary of commands and responses.\r
-\r
- The following are the commands recognized and responses returned by\r
- the NNTP server.\r
-\r
-4.7.1. Commands\r
-\r
- ARTICLE\r
- BODY\r
- GROUP\r
- HEAD\r
- HELP\r
- IHAVE\r
- LAST\r
- LIST\r
- NEWGROUPS\r
- NEWNEWS\r
- NEXT\r
- POST\r
- QUIT\r
- SLAVE\r
- STAT\r
-\r
-4.7.2. Responses\r
-\r
- 100 help text follows\r
- 199 debug output\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 24]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- 200 server ready - posting allowed\r
- 201 server ready - no posting allowed\r
- 202 slave status noted\r
- 205 closing connection - goodbye!\r
- 211 n f l s group selected\r
- 215 list of newsgroups follows\r
- 220 n <a> article retrieved - head and body follow 221 n <a> article\r
- retrieved - head follows\r
- 222 n <a> article retrieved - body follows\r
- 223 n <a> article retrieved - request text separately 230 list of new\r
- articles by message-id follows\r
- 231 list of new newsgroups follows\r
- 235 article transferred ok\r
- 240 article posted ok\r
-\r
- 335 send article to be transferred. End with <CR-LF>.<CR-LF>\r
- 340 send article to be posted. End with <CR-LF>.<CR-LF>\r
-\r
- 400 service discontinued\r
- 411 no such news group\r
- 412 no newsgroup has been selected\r
- 420 no current article has been selected\r
- 421 no next article in this group\r
- 422 no previous article in this group\r
- 423 no such article number in this group\r
- 430 no such article found\r
- 435 article not wanted - do not send it\r
- 436 transfer failed - try again later\r
- 437 article rejected - do not try again.\r
- 440 posting not allowed\r
- 441 posting failed\r
-\r
- 500 command not recognized\r
- 501 command syntax error\r
- 502 access restriction or permission denied\r
- 503 program fault - command not performed\r
-\r
-4.8. A Brief Word about the USENET News System\r
-\r
- In the UNIX world, which traditionally has been linked by 1200 baud\r
- dial-up telephone lines, the USENET News system has evolved to handle\r
- central storage, indexing, retrieval, and distribution of news. With\r
- the exception of its underlying transport mechanism (UUCP), USENET\r
- News is an efficient means of providing news and bulletin service to\r
- subscribers on UNIX and other hosts worldwide. The USENET News\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 25]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
- system is discussed in detail in RFC 850. It runs on most versions\r
- of UNIX and on many other operating systems, and is customarily\r
- distributed without charge.\r
-\r
- USENET uses a spooling area on the UNIX host to store news articles,\r
- one per file. Each article consists of a series of heading text,\r
- which contain the sender's identification and organizational\r
- affiliation, timestamps, electronic mail reply paths, subject,\r
- newsgroup (subject category), and the like. A complete news article\r
- is reproduced in its entirety below. Please consult RFC 850 for more\r
- details.\r
-\r
- Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site\r
- sdcsvax.UUCP\r
- Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp\r
- Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek\r
- !honman\r
- From: honman@unitek.uucp (Man Wong)\r
- Newsgroups: net.unix-wizards\r
- Subject: foreground -> background ?\r
- Message-ID: <167@unitek.uucp>\r
- Date: 25 Sep 85 23:51:52 GMT\r
- Date-Received: 29 Sep 85 09:54:48 GMT\r
- Reply-To: honman@unitek.UUCP (Hon-Man Wong)\r
- Distribution: net.all\r
- Organization: Unitek Technologies Corporation\r
- Lines: 12\r
-\r
- I have a process (C program) which generates a child and waits for\r
- it to return. What I would like to do is to be able to run the\r
- child process interactively for a while before kicking itself into\r
- the background so I can return to the parent process (while the\r
- child process is RUNNING in the background). Can it be done? And\r
- if it can, how?\r
-\r
- Please reply by E-mail. Thanks in advance.\r
-\r
- Hon-Man Wong\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 26]\r
-\f\r
-\r
-\r
-RFC 977 February 1986\r
-Network News Transfer Protocol\r
-\r
-\r
-5. References\r
-\r
- [1] Crocker, D., "Standard for the Format of ARPA Internet Text\r
- Messages", RFC-822, Department of Electrical Engineering,\r
- University of Delaware, August, 1982.\r
-\r
- [2] Horton, M., "Standard for Interchange of USENET Messages",\r
- RFC-850, USENET Project, June, 1983.\r
-\r
- [3] Postel, J., "Transmission Control Protocol- DARPA Internet\r
- Program Protocol Specification", RFC-793, USC/Information\r
- Sciences Institute, September, 1981.\r
-\r
- [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821,\r
- USC/Information Sciences Institute, August, 1982.\r
-\r
-6. Acknowledgements\r
-\r
- The authors wish to express their heartfelt thanks to those many\r
- people who contributed to this specification, and especially to Erik\r
- Fair and Chuq von Rospach, without whose inspiration this whole thing\r
- would not have been necessary.\r
-\r
-7. Notes\r
-\r
- <1> UNIX is a trademark of Bell Laboratories.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Kantor & Lapsley [Page 27]\r
-\f\r
RFC2193 IMAP4 Mailbox Referrals
RFC2221 IMAP4 Login Referrals
-->
+
+<h1>Other useful documents</h1>
+
+<dl>
+<dt><a
+href="http://www.faqs.org/faqs/LANs/mail-protocols/">http://www.faqs.org/faqs/LANs/mail-protocols/</a></dt>
+
+<dd>LAN Mail Protocols Summary</dd>
+</dl>
+
<hr />
<table width="100%" cellpadding="0" summary="Canned page footer">
<tr>
projects / ~andy / fetchmail / commitdiff