Interactive Mail Access Protocol: Version 2
RFC 1064

Document Type RFC - Unknown (July 1988; No errata)
Obsoleted by RFC 1176, RFC 1203
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1064 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         M. Crispin
Request for Comments: 1064                                     SUMEX-AIM
                                                               July 1988


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

Crispin                                                         [Page 1]
RFC 1064                         IMAP2                         July 1988

   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" 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
Show full document text