home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1339 < prev    next >
Text File  |  1992-06-29  |  13KB  |  340 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         S. Dorner
  8. Request for Comments: 1339                                   P. Resnick
  9.                                      U. of Illinois at Urbana-Champaign
  10.                                                               June 1992
  11.  
  12.  
  13.                      Remote Mail Checking Protocol
  14.  
  15. Status of this Memo
  16.  
  17.    This memo defines an Experimental Protocol for the Internet
  18.    community.  Discussion and suggestions for improvement are requested.
  19.    Please refer to the current edition of the "IAB Official Protocol
  20.    Standards" for the standardization state and status of this protocol.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    This RFC defines a protocol to provide a mail checking service to be
  26.    used between a client and server pair. Typically, a small program on
  27.    a client workstation would use the protocol to query a server in
  28.    order to find out whether new mail has arrived for a specified user.
  29.  
  30. Intent
  31.  
  32.    This RFC defines a simple, low-overhead protocol for checking the
  33.    status of a maildrop on a host. It is primarily intended for use in
  34.    adjunct with "remote mail" servers such as those implementing the
  35.    Post Office Protocol (RFC 1225). Remote mail clients must poll their
  36.    servers to discover the arrival of mail. Using one of the remote mail
  37.    protocols for periodic checking can be quite impractical and
  38.    expensive for the server since either a constant connection between
  39.    client and server must be maintained or repeated and expensive user
  40.    validations must be done. Furthermore, users on less capable
  41.    computers may not wish to devote the memory required to have a full
  42.    implementation of the client polling for mail.  Thus, we feel that an
  43.    easy to implement and inexpensive to use polling scheme would be of
  44.    benefit both to mail servers and their clients.
  45.  
  46. Protocol Overview
  47.  
  48.    To avoid connection overhead, the Remote Mail Checking Protocol is
  49.    based on the User Datagram Protocol (UDP), using UDP port 50 decimal
  50.    (62 octal) for the server. The protocol provides for both non-
  51.    authenticated and authenticated polling. Non-authenticated polling is
  52.    simplest for both client and server. Authenticated polling provides a
  53.    small increment of privacy, at the cost of more complexity in both
  54.    client and server (but still far less than polling with one of the
  55.  
  56.  
  57.  
  58. Dorner & Resnick                                                [Page 1]
  59.  
  60. RFC 1339             Remote Mail Checking Protocol             June 1992
  61.  
  62.  
  63.    remote mail protocols).
  64.  
  65. Non-Authenticated Protocol
  66.  
  67.    In the non-authenticated version of the protocol, the server will
  68.    listen on port 50 for maildrop check requests for users with
  69.    maildrops on the machine. A client will send a single UDP datagram
  70.    from a randomly chosen unreserved UDP port to UDP port 50 on the
  71.    server. The datagram will contain a 32-bit (four-octet) number which
  72.    is set to all zeros (0), followed by a case-sensitive ASCII string of
  73.    a username on the server system. The server will find the maildrop on
  74.    the system for that user and determine the amount of time that has
  75.    passed since the last message in the maildrop was appended, as well
  76.    as the amount of time that has passed since the maildrop was last
  77.    accessed for reading. The server will then send back a single UDP
  78.    datagram containing three 32-bit numbers in network byte order to the
  79.    originating port on the client. Again, the first will be zero (0),
  80.    the second will contain the number of seconds plus one since the last
  81.    addition to the specified user's maildrop and the third will contain
  82.    the number of seconds plus one since the last read on the user's
  83.    maildrop. If the username provided does not exist, if the maildrop is
  84.    not on the system or if the maildrop is empty, the server will send
  85.    back zero (0) in the last two numbers for its reply. The client will
  86.    consider the maildrop to contain new mail if the number of seconds
  87.    since the last read access is greater than or equal to the number of
  88.    seconds since the last addition access of the maildrop and either
  89.    number is non-zero, old mail if the number of seconds since the last
  90.    read access is less than or equal to the number of seconds since the
  91.    last addition access of the maildrop and either number is non-zero,
  92.    and empty if both numbers are zero.
  93.  
  94. Authenticated Protocol
  95.  
  96.    The authenticated protocol operates identically to the non-
  97.    authenticated protocol with the exception of the first interaction
  98.    between the server and the client. After the client has sent its
  99.    initial request containing the requested username, the server will
  100.    send back a single UDP packet containing three 32-bit numbers. The
  101.    first number will be a bit-mask instead of the normal 32-bits of
  102.    zero. The bit-mask will indicate a request for authentication. Each
  103.    bit in the mask represents a type of authentication that the server
  104.    accepts. The bits (with the least significant bit numbered 0, and the
  105.    most significant bit 31) are defined as follows:
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Dorner & Resnick                                                [Page 2]
  115.  
  116. RFC 1339             Remote Mail Checking Protocol             June 1992
  117.  
  118.  
  119.       0     Cleartext password The password for the maildrop, not
  120.             NULL-terminated.
  121.  
  122.       1-23  Reserved for future use
  123.  
  124.       24-31 Implementation-dependent. Implementors wishing to
  125.             experiment may use these.
  126.  
  127.    For each type of authentication that the server accepts, the
  128.    corresponding bit will be set to one. All other bits will be set to
  129.    zero.  The last two 32-bit numbers in the reply will be set to zero.
  130.    If the client supports authentication, it will send back a 32-bit
  131.    mask with the bit representing the kind of authentication it is using
  132.    set to one, followed by the data used for authentication. The client
  133.    is free to use any of the types of authentication indicated by the
  134.    authentication request from the server. If the client does not
  135.    support authentication and it receives an authentication request, it
  136.    SHOULD stop sending requests (though this behavior is not required).
  137.  
  138.    Once a valid authentication is received by the server for a
  139.    particular maildrop, the server considers the IP address and UDP port
  140.    of the client along with that maildrop to be an authenticated
  141.    address/port/maildrop triple. From then on, normal non-authenticated
  142.    transactions take place between the server and the client as
  143.    described above. Should a datagram come from an authenticated
  144.    address/port pair with a different username, or if some amount of
  145.    time has elapsed since the last request (which is implementation
  146.    dependent), the server should remove the address/port/maildrop triple
  147.    from its list of authenticated triples and send another
  148.    authentication request. Since the time required for an authenticated
  149.    triple to become unauthenticated is implementation dependent, clients
  150.    should be prepared to send an authentication reply to containing the
  151.    server whenever it is requested.
  152.  
  153. Server Implementation Notes
  154.  
  155.    Servers which implement either the authenticated or non-authenticated
  156.    protocol may decide that they do not wish to reveal the actual amount
  157.    of time that has passed since the last update or read from a
  158.    maildrop. (See the "Security Considerations" section below for
  159.    reasons some feel this is problematic.) In this case, a server may
  160.    instead reply with the following:
  161.  
  162.                    First 32 bits     Second 32 bits     Third 32 bits
  163.       New mail           0                 0                  1
  164.       Old mail           0                 1                  0
  165.       No mail            0                 0                  0
  166.  
  167.  
  168.  
  169.  
  170. Dorner & Resnick                                                [Page 3]
  171.  
  172. RFC 1339             Remote Mail Checking Protocol             June 1992
  173.  
  174.  
  175.    These values will appear to the client as correctly representing new,
  176.    old or no mail respectively but will give no indication of the actual
  177.    times that the changes took place.
  178.  
  179.    Servers implementing the non-authenticated protocol MUST provide some
  180.    mechanism by which users on the system can give permission for their
  181.    maildrops to accessed by the protocol. See the "Security
  182.    Considerations" section below for specifics.
  183.  
  184. Client Implementation Notes
  185.  
  186.    Clients MUST not send more than one poll (and one authentication) per
  187.    minute. In particular, lack of server response should not result in
  188.    retransmission.
  189.  
  190.    Since the last two numbers in an authentication request from a server
  191.    are always 0 as are the last two numbers in a response for an empty
  192.    or non-existent maildrop, clients that do not support authentication
  193.    need not examine the first number in the server datagram at all
  194.    (though they are encouraged to do so for the sake of proper reporting
  195.    to the user).
  196.  
  197.    Clients can turn the modification interval into absolute time, and
  198.    track the changing of this absolute time in order to discern the
  199.    arrival of new mail (as opposed to the mere existence of unread
  200.    mail). However, such clients should bear three things in mind.
  201.    First, network delays and clock vagaries may result in small
  202.    inconsistencies in times. A "slop factor" of several seconds is
  203.    encouraged. Second, the reading of mail often entails modification of
  204.    the maildrop; the relationship of the access and modification
  205.    intervals should always be consulted. Third, the special results of
  206.    (1,0) and (0,1) are most properly handled as special cases.
  207.  
  208.    Clients need not recall whether or not they are authenticated (though
  209.    they must use a consistent port if they receive any authentication
  210.    requests for a given maildrop). It is sufficient to issue requests
  211.    when desired, and to respond to any authentication requests that
  212.    appear.
  213.  
  214. Security Considerations
  215.  
  216.    The are two security considerations for the protocol. The first is
  217.    one mainly of privacy. Some sites and individual users consider it
  218.    problematic to have information about mail arrival available freely.
  219.    This can be a simple privacy issue for individuals or a security
  220.    issue for highly secure sites. The authenticated version of the
  221.    protocol allows sites to have a reasonable amount of security in that
  222.    only people with passwords can access this information. The protocol
  223.  
  224.  
  225.  
  226. Dorner & Resnick                                                [Page 4]
  227.  
  228. RFC 1339             Remote Mail Checking Protocol             June 1992
  229.  
  230.  
  231.    currently only uses cleartext passwords, but can be simply modified
  232.    to use other authentication formats. The scheme mentioned in "Server
  233.    Implementation Notes" of using only (0,1) and (1,0) in the responses
  234.    also may limit access to some types of information.  Implementations
  235.    that do not use the authenticated scheme MUST have a mechanism by
  236.    which a user can give consent to have this information made
  237.    available; the default for the unauthenticated implementation should
  238.    be that a user's maildrop cannot be accessed until consent of the
  239.    user is given. (For example, UNIX server implementations may wish to
  240.    make use of the "owner execute" bit to indicate whether a particular
  241.    maildrop allows use of the unauthenticated protocol. If this is done,
  242.    a single "stat" call can be used to gather all information required
  243.    to respond to a poll.) Servers which do not implement authentication
  244.    should simply return a zero-filled datagram for maildrops which don't
  245.    have permission.
  246.  
  247.    The other security consideration involves unknown maildrops and
  248.    usernames. Some site administrators consider it a security risk give
  249.    out any information which would reveal the existence or non-existence
  250.    of a certain username or maildrop on the system. For this reason, we
  251.    have chosen to have the server send back a zero-filled datagram as
  252.    the response to either a request for an unknown username or a
  253.    maildrop that does not exist or is empty. In this way, potential
  254.    security violations are limited, since there is no way to tell the
  255.    difference between an empty maildrop and non-existent maildrop, and
  256.    also no way to tell if the user exists on the system or not. If
  257.    greater security is desired, the protocol should probably not be run
  258.    in the first place.
  259.  
  260. Authors' Addresses
  261.  
  262.    Steve Dorner
  263.    Digital Computer Laboratory
  264.    University of Illinois at Urbana-Champaign
  265.    1304 West Springfield Avenue
  266.    Urbana, Illinois 61801
  267.  
  268.    Phone: (217) 244-1765
  269.    EMail: s-dorner@uiuc.edu
  270.  
  271.    Pete Resnick
  272.    The Beckman Institute
  273.    University of Illinois at Urbana-Champaign
  274.    405 North Mathews Avenue
  275.    Urbana, Illinois 61801
  276.  
  277.    Phone: (217) 244-1265
  278.    EMail: resnick@cogsci.uiuc.edu
  279.  
  280.  
  281.  
  282. Dorner & Resnick                                                [Page 5]
  283.  
  284. RFC 1339             Remote Mail Checking Protocol             June 1992
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Dorner & Resnick                                                [Page 6]
  339.  
  340.