RFC 1339

Remote Mail Checking Protocol 💌

Part 1 of 2 🎀

Okay bestie, let's start with the ID card 🪪 This is RFC 1339, called Remote Mail Checking Protocol. It was written by S. Dorner and P. Resnick, both at the University of Illinois at Urbana-Champaign, and it's dated June 1992. It's an Experimental one, since the Status section calls it an Experimental Protocol. The title block doesn't list any RFCs that it obsoletes or updates, so it's pretty low-drama on that front 📎✨

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 that gives you a mail checking service between a client and a server pair. Usually, a small program on a client workstation uses the protocol to ask a server whether new mail has arrived for a specified user. It's basically the tiny messenger that goes "did anything land for them?" 💌

Intent 🎯

Okay so the goal here is a simple, low-overhead protocol for checking the status of a maildrop on a host. 🦋 It's mainly meant to sit alongside "remote mail" servers, like the ones that implement the Post Office Protocol (RFC 1225).

Here's the tea 🫖 Remote mail clients must poll their servers to find out when mail shows up. Using one of the remote mail protocols for periodic checking can be seriously impractical and expensive for the server. Either a constant connection between client and server has to be maintained, or repeated and expensive user validations have to happen. Ngl, that's a lot of drama for a simple "anything new?" 😭

Also, users on less capable computers might not want to spend the memory needed for a full client that polls for mail. So the authors feel an easy-to-implement, inexpensive polling scheme would be a win for both mail servers and their clients. Main character energy for the lightweight option 👑

Protocol Overview 🧚

To avoid connection overhead, the Remote Mail Checking Protocol is based on the User Datagram Protocol (UDP). The server uses UDP port 50 decimal (62 octal). ✨

The protocol offers both non-authenticated and authenticated polling. Non-authenticated polling is the simplest option for both the client and the server. Authenticated polling gives you a small bit of extra privacy, but it costs more complexity on both sides. It's still way less work than polling with one of the remote mail protocols, though 🙈

Non-Authenticated Protocol 🌸

In the non-authenticated version, the server listens on port 50 for maildrop check requests for users who have maildrops on the machine. 🎀

A client sends a single UDP datagram from a randomly chosen unreserved UDP port to UDP port 50 on the server. The datagram contains a 32-bit (four-octet) number set to all zeros (0), followed by a case-sensitive ASCII string holding a username on the server system. Capitalisation matters here, so be careful, bestie 💅

The server finds the maildrop for that user and works out two things. The first is how much time has passed since the last message was appended to the maildrop. The second is how much time has passed since the maildrop was last accessed for reading. ⏱️

Then the server sends back a single UDP datagram to the originating port on the client. It contains three 32-bit numbers in network byte order. The first is zero (0) again. The second is the number of seconds plus one since the last addition to that user's maildrop. The third is the number of seconds plus one since the last read on that maildrop 📬

If the username doesn't exist, if the maildrop isn't on the system, or if the maildrop is empty, the server sends back zero (0) in the last two numbers of its reply. 🫥

The client decides what it's looking at like this:

• It's 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, and either number is non-zero. 🔥
• It's 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, and either number is non-zero. 🥀
• It's empty if both numbers are zero. 🫧

Authenticated Protocol 🔐

The authenticated protocol works exactly like the non-authenticated one, with one exception: the first interaction between the server and the client. 💖

After the client sends its initial request with the requested username, the server sends back a single UDP packet with three 32-bit numbers. Here's the plot twist: the first number is a bit-mask instead of the usual 32 bits of zero. This bit-mask asks for authentication. Each bit in the mask stands for a type of authentication the server accepts. 🪄

The bits are numbered with the least significant bit as 0 and the most significant bit as 31. They're defined like this:

0     Cleartext password The password for the maildrop, not
      NULL-terminated.

1-23  Reserved for future use

24-31 Implementation-dependent. Implementors wishing to
      experiment may use these.

For every type of authentication the server accepts, the matching bit is set to one. All the other bits are set to zero. The last two 32-bit numbers in the reply are also set to zero. 🧸

If the client supports authentication, it sends back a 32-bit mask with the bit for its kind of authentication set to one. After that comes the data used for authentication. The client is free to use any of the types the server indicated in its request. 🌈

If the client doesn't support authentication and gets an authentication request, it SHOULD stop sending requests, though this behaviour is not required. 🙃

Once the server receives valid authentication for a particular maildrop, it treats the IP address and UDP port of the client, along with that maildrop, as an authenticated address/port/maildrop triple. From then on, normal non-authenticated transactions happen between the server and the client, just as described above. 🦋

Things can change, though. If a datagram comes from an authenticated address/port pair but with a different username, the server should remove that address/port/maildrop triple from its list of authenticated triples and send another authentication request. The same goes if some amount of time has passed since the last request, which is implementation dependent. 🫠

Because the time it takes for an authenticated triple to become unauthenticated depends on the implementation, clients should be prepared to send an authentication reply to containing the server whenever it's requested. Basically, always be ready to respond when the server asks 🫶

Authors' Addresses ✨

Okay bestie, last stop! 🧚 These are the two people behind this whole thing, and their contact details are right here, exactly as the RFC lists them 💅

Steve Dorner was at the Digital Computer Laboratory 🌸

Steve Dorner
Digital Computer Laboratory
University of Illinois at Urbana-Champaign
1304 West Springfield Avenue
Urbana, Illinois 61801

Phone: (217) 244-1765
EMail: s-dorner@uiuc.edu

Pete Resnick was over at The Beckman Institute 🦋

Pete Resnick
The Beckman Institute
University of Illinois at Urbana-Champaign
405 North Mathews Avenue
Urbana, Illinois 61801

Phone: (217) 244-1265
EMail: resnick@cogsci.uiuc.edu