Remote Mail Checking Protocol
RFC 1339
|
Document |
Type |
|
RFC - Experimental
(June 1992; No errata)
|
|
Authors |
|
Steve Dorner
,
Pete Resnick
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
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