Remote Mail Checking Protocol
RFC 1339

Document Type RFC - Experimental (June 1992; No errata)
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 1339 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                         S. Dorner
Request for Comments: 1339                                   P. Resnick
                                     U. of Illinois at Urbana-Champaign
                                                              June 1992

                     Remote Mail Checking Protocol

Status of this Memo

   This memo defines 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.

Abstract

   This RFC defines a protocol to provide a mail checking service to be
   used between a client and server pair. Typically, a small program on
   a client workstation would use the protocol to query a server in
   order to find out whether new mail has arrived for a specified user.

Intent

   This RFC defines a simple, low-overhead protocol for checking the
   status of a maildrop on a host. It is primarily intended for use in
   adjunct with "remote mail" servers such as those implementing the
   Post Office Protocol (RFC 1225). Remote mail clients must poll their
   servers to discover the arrival of mail. Using one of the remote mail
   protocols for periodic checking can be quite impractical and
   expensive for the server since either a constant connection between
   client and server must be maintained or repeated and expensive user
   validations must be done. Furthermore, users on less capable
   computers may not wish to devote the memory required to have a full
   implementation of the client polling for mail.  Thus, we feel that an
   easy to implement and inexpensive to use polling scheme would be of
   benefit both to mail servers and their clients.

Protocol Overview

   To avoid connection overhead, the Remote Mail Checking Protocol is
   based on the User Datagram Protocol (UDP), using UDP port 50 decimal
   (62 octal) for the server. The protocol provides for both non-
   authenticated and authenticated polling. Non-authenticated polling is
   simplest for both client and server. Authenticated polling provides a
   small increment of privacy, at the cost of more complexity in both
   client and server (but still far less than polling with one of the

Dorner & Resnick                                                [Page 1]
RFC 1339             Remote Mail Checking Protocol             June 1992

   remote mail protocols).

Non-Authenticated Protocol

   In the non-authenticated version of the protocol, the server will
   listen on port 50 for maildrop check requests for users with
   maildrops on the machine. A client will send a single UDP datagram
   from a randomly chosen unreserved UDP port to UDP port 50 on the
   server. The datagram will contain a 32-bit (four-octet) number which
   is set to all zeros (0), followed by a case-sensitive ASCII string of
   a username on the server system. The server will find the maildrop on
   the system for that user and determine the amount of time that has
   passed since the last message in the maildrop was appended, as well
   as the amount of time that has passed since the maildrop was last
   accessed for reading. The server will then send back a single UDP
   datagram containing three 32-bit numbers in network byte order to the
   originating port on the client. Again, the first will be zero (0),
   the second will contain the number of seconds plus one since the last
   addition to the specified user's maildrop and the third will contain
   the number of seconds plus one since the last read on the user's
   maildrop. If the username provided does not exist, if the maildrop is
   not on the system or if the maildrop is empty, the server will send
   back zero (0) in the last two numbers for its reply. The client will
   consider the maildrop to contain new mail if the number of seconds
   since the last read access is greater than or equal to the number of
   seconds since the last addition access of the maildrop and either
   number is non-zero, old mail if the number of seconds since the last
   read access is less than or equal to the number of seconds since the
   last addition access of the maildrop and either number is non-zero,
   and empty if both numbers are zero.

Authenticated Protocol

   The authenticated protocol operates identically to the non-
   authenticated protocol with the exception of the first interaction
   between the server and the client. After the client has sent its
   initial request containing the requested username, the server will
   send back a single UDP packet containing three 32-bit numbers. The
   first number will be a bit-mask instead of the normal 32-bits of
   zero. The bit-mask will indicate a request for authentication. Each
   bit in the mask represents a type of authentication that the server
   accepts. The bits (with the least significant bit numbered 0, and the
Show full document text