Email History through RFCs

Many aspects of email are a lot older than you may think.
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.
arpanet3
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 1971 [rfc 114]RFC 114 A File Transfer Protocol.[/rfc] 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 [rfc 114]earliest versions[/rfc] 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.
August 1971 [rfc 221]RFC 221 A Mail Box Protocol, Version-2[/rfc] had this prescient paragraph:

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 1972 [rfc 385]RFC 385 Comments on the File Transfer Protocol[/rfc] 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.
November 1972 [rfcx 414] – uses user@host email addresses as primary contact information.
February 1973 [rfc 458]RFC 458 Mail Retrieval via FTP[/rfc] allowed a user to directly read email in a remote mailbox, a distant ancestor of modern POP and IMAP.
March 1973 [rfcx 469] and [rfcx 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 1973 [rfc 524]RFC 524 A Proposed Mail Protocol[/rfc]. 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. [rfcx 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.
September 1973 [rfc 561]RFC 561 Standardizing Network Mail Headers[/rfc]. Lots of this looks familiar – From:, Date:, Subject:! This describes the separation of email payload metadata from email routing data – though it’s described as a short-term interim solution. This will evolve into [rfcx 680], [rfcx 724], [rfcx 733], [rfcx 822], [rfcx 2822] and finally todays [rfcx 5322].
October 1973 [rfc 577]RFC 577 Mail Priority[/rfc] has the first mention of electronic junk mail I’ve seen.
July 1974 [rfc 644]RFC 644 On the Problem of Signature Authentication for Network Mail[/rfc] is an early discussion of how to be sure that email came from who it claims to be from.
November 1975 [rfc 706]RFC 706 On the Junk Mail Problem[/rfc] – Network level rejection of sources of unwanted email (the “IMP” is the router to the network).

… 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.

March 1979 [rfc 753]RFC 753 Internet Message Protocol[/rfc] is a proposed binary format for mail transfer. It’s not SMTP yet, but the ideas are evolving.
August 1980 [rfc 767]RFC 767 A Structured Format for Transmission of Multi-Media Documents[/rfc] – the beginnings of MIME
September 1980 [rfc 772]RFC 772 Mail Transfer Protocol[/rfc]. This is fairly recognizable as modern SMTP.

The objective of Mail Transfer Protocol (MTP) is to transfer mail reliably and efficiently.

It will evolve through [rfcx 780], [rfcx 788], [rfcx 821] and [rfcx 2821] to become modern ESMTP in [rfcx 5321].
 
(Alisa Bagrii has provided a translation of this post into Russian, over at EveryCloud.)

Related Posts

July 2014: The month in email

We continue to be busy with really interesting client work. Look for some new posts and white papers to come out of this research over the next few months, but for now blogging has been a bit light while we’re working hard. In parallel with our busy times, we have also been pondering the ways in which the email world illustrates the classic bon mot  “plus ça change, plus c’est la même chose”, and we’ve been revisiting some posts from a few years ago to examine this.
We started July with a nod to a good subscription experience just as CASL, the Canadian Anti-Spam Legislation went into effect on Canada Day. While companies have another 17 months to put these provisions into practice, it’s a good reminder that periodic re-engagement with customers can be very effective in helping you maintain high-quality subscriber lists. We talked a bit more about CASL here and what protections the law intends.
In stark contrast, we posted about an organization that is doing a less-than-stellar job making sure they’re only sending wanted email. The Direct Marketing Association is a terrific resource and member organization for marketers across industries and channels, but their email marketing practices don’t always live up to their mission of “Advancing and Protecting Responsible Data-Driven Marketing”, and we explored some ways in which they might improve this.
Those of you who have been reading this blog for any time at all know that we tend to talk about wanted mail and unwanted mail rather than the more general category of spam. Marketers tend to think their mail can’t possibly be spam if it’s not offering Viagra or phishing for credit card information, but that’s not really the point — if a customer doesn’t want to read your email about new mountain bikes, even if they bought a mountain bike from you three years ago, that’s unwanted email. Here’s a post we revisited about why customers might not want your mail, and a new post about engagement.
One risk of sending unwanted email, of course, is that customers complain, and that will affect your delivery going forward. We revisited a post about feedback loops, and also talked a bit about addressing delivery problems as they come up rather than waiting for them to resolve on their own (mostly, they won’t!)
I also proposed a bit of a thought experiment around monetizing the complaint stream, and followed up with a second post. There are some good points in the comments of those posts, but mostly I think it’s an interesting solution to addressing risk and abuse at ESPs.
Finally, Steve wrote a short post about our new mail servers and how quickly spammers descended as we set those up. It’s a constant battle!

Read More

Email saves trees!

The arrival of my first spam email was a bit of a shock. I’d been on the internet for years by that point and had never seen junk mail in my inbox. Of course, the Internet was a very different place. The web was still a toddler. There was no email marketing industry. In fact, there wasn’t much commerce on the web at all. Much of the “surfing” I did was using gopher and ftp rather than the fancy new web browser called NCSA Mosaic. To share pictures we actually had to send printouts by postal mail.
It wasn’t just getting spam that was memorable (oh, great! now my inbox is going to look like my postal box, stuffed full of things I don’t want), it was the domain name: savetrees.com. Built into the domain name was an entire argument defending spam on the grounds of environmental friendliness. By sending spam instead of postal mail we could save the earth. Anyone who didn’t like it was morally corrupt and must hate the planet.
Why do I mention this history? During a discussion on a list for marketers earlier this week, multiple people mentioned that email marketing was clearly and obviously the much more environmentally sound way to do things. I mentioned this over on Facebook and one of my librarian friends (who was one of the people I was email friends with back in those early days) started doing her thing.
She posted her findings over on the Environmental News Bits blog: The comparative environmental impact of email and paper mail. It’s well worth a read, if only because a lot of companies have really looked into the issue in great detail. Much greater detail than I thought was being put into the issue.
I shared one of the links she found, the 2009 McAfee study, with the email marketing group discussing the issue. (You may want to put down the drinks before reading the next line.) It was universally panned as marketing and therefore the conclusions couldn’t be trusted.
Anyone who pays any attention knows that nothing we do and none of the choices we make are environmentally neutral. Plastic bags were supposed to save trees from becoming paper bags, but turned into an environmental mess of their own.
Simple slogans like “email saves trees” might make marketers feel better, and may have gained Cyberpromo a strong customer base in the early days. But the reality is different.

Read More

Ever changing filtering

One of the ongoing challenges sending email, and managing a high volume outbound mail server is dealing with the ongoing changes in filtering. Filters are not static, nor can they be. As ISPs and filtering companies identify new ways to separate out wanted email from unwanted email, spammers find new ways to make their mail look more like wanted mail.
This is one reason traps are useful to filtering companies. With traps there is no discussion about whether or not the mail was requested. No one with any connection to the email address opted in to receive mail. The mail was never requested. While it is possible for trap addresses to get on any list monitoring mail to spam traps is a way to monitor which senders don’t have good practices.
New filtering techniques are always evolving. I mentioned yesterday that Gmail was making filtering changes, and that this was causing a lot of delivery issues for senders. The other major challenge for Gmail is the personalized delivery they are doing. It’s harder and harder for senders to monitor their inbox delivery because almost every inbox is different at Gmail. I’ve seen different delivery in some of my own mailboxes at Gmail.
All of this makes email delivery an ongoing challenge.

Read More