Interactive Mail Access Protocol: Version 2 (RFC1064)
Original Publication Date: 1988-Jul-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
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.
Network Working Group M. Crispin
Request for Comments: 1064 SUMEX-AIM
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"
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
facilities to do this. However, this approach has several
(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" fo...