Interactive Mail Access Protocol: Version 2 (RFC1064)
Original Publication Date: 1988-Jul-01
Included in the Prior Art Database: 2019-Feb-15
Internet Society Requests For Comment (RFCs)
This memo suggests a method for workstations to dynamically access mail from a mailbox server ("respository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested.
Network Working Group M. Crispin Request for Comments: 1064 SUMEX-AIM July 1988
INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2
Status of this Memo
This RFC suggests a method for workstations to dynamically access mail from a mailbox server ("repository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2) is to allow a workstation or similar small machine to access electronic mail from a mailbox server. IMAP2 is the protocol used by the SUMEX-AIM MM-D (MM Distributed) mail system.
Although different in many ways from POP2 (RFC 937), IMAP2 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, 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). 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 IMAP2 server listens on port 143.
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
Crispin [Page 1]
RFC 1064 IMAP2 July 1988
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, 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 ...