BLOG

Email History through RFCs

There were quite a few people in the early 1970s working out how to provide useful services using ARPANET, the network that evolved over the next 10 or 15 years into the modern Internet.

They used Requests for Comment (RFCs) to document protocol and research, much as is still done today. Here are some of the interesting milestones.

April 1971RFC 114 A File Transfer Protocol. One of the earliest services that was deployed so as to be useful to people, rather than a required part of the network infrastructure, was a way to transfer files from one computer to another. In the earliest versions of the service I can find it could already append text to an existing file. This was soon used for sending short messages, initially to a remote printer from where it would be sent by internal mail, but soon also to a mailbox where they could be read online.

The other problem which was raised about the Mail Box Protocol was the possibility of someone accidentally or deliberately flooding the printer of a site with garbage, as there are no access or file size controls. Some thinking and discussions of this problem have yielded no simple satisfactory solutions. I would recommend initial implementations without standard special safeguards in this area. Safeguards would be a site-dependent option. Standard safeguards for the above problem can be easily added later if they really prove necessary and satisfactory ones can be agreed on.

August 1972RFC 385 Comments on the File Transfer Protocol formalized the use of this for electronic mail providing the command “MAIL <user>”. This let you interactively send a message to a user on a remote system identified either by their username on the remote system you connected to or by their “NIC IDENT”, the latter being a global way of identifying a person or a role mailbox. The protocol used required you to mark the end of your message with a line consisting of a single period, just the same as modern ESMTP mail.

March 1973RFC 469 and RFC 475 discuss the development of email from a simple remote-file-append system to a richer store-and-forward, including the first mention of “MAIL FROM” and an early mention of the “@” sign to create email addresses (adopted from Tenex SNDMSG?).

June 1973RFC 524 A Proposed Mail Protocol. This is a very complex, and complete, description of a mail protocol. It has the first mentions I’ve seen of delivery receipts and status notifications, but is mostly useful to understand quite how simple Simple Mail Transfer Protocol is in comparison, and the elegance of separating message delivery from message structure. RFC 539 responds to this, bringing up the idea of mail as a standalone protocol (rather than a subprotocol of FTP) and forwarding of email from one address to another.

… there is no mechanism for the Host to selectively refuse messages. This means that a Host which desires to receive some particular messages must read all messages addressed to it.
…
It would be useful for a Host to be able to decline messages from sources it believes are misbehaving or are simply annoying.
…
A Host might make use of such a facility by measuring, per source, the number of undesired messages per unit time, if this measure exceeds a threshold then the Host could issue the “refuse messages from Host X” message to the IMP.

You can't technical your way out of the bulk folder. I wrote that a year and a half ago, and it's even more true today. Filters at the big webmail providers continue to evolve to meet new threats and new spamming techniques. Sending technically perfect mail won't get your mail into the inbox. Recipients have to want the mail and interact with the mail for good delivery.
No Comments