Tous les articles par Gaetan

The History of Email

This was adapted from a post which originally appeared on the Eager blog. Eager has now become the new Cloudflare Apps.


— Text of the first email ever sent, 1971

The ARPANET (a precursor to the Internet) was created “to help maintain U.S. technological superiority and guard against unforeseen technological advances by potential adversaries,” in other words, to avert the next Sputnik. Its purpose was to allow scientists to share the products of their work and to make it more likely that the work of any one team could potentially be somewhat usable by others. One thing which was not considered particularly valuable was allowing these scientists to communicate using this network. People were already perfectly capable of communicating by phone, letter, and in-person meeting. The purpose of a computer was to do massive computation, to augment our memories and empower our minds.

Surely we didn’t need a computer, this behemoth of technology and innovation, just to talk to each other.

The computers which sent (and received) the first email.

The history of computing moves from massive data processing mainframes, to time sharing where many people share one computer, to the diverse collection of personal computing devices we have today. Messaging was first born in the time sharing era, when users wanted the ability to message other users of the same time shared computer.

Unix machines have a command called write which can be used to send messages to other currently logged-in users. For example, if I want to ask Mark out to lunch:

$ write mark
write: mark is logged in more than once; writing to ttys002

Hi, wanna grab lunch?

He will see:

Message from [email protected] on ttys003 at 10:36 …
Hi, wanna grab lunch?

This is absolutely hilarious if your coworker happens to be using a graphical tool like vim which will not take kindly to random output on the screen.

Persistant Messages

When the mail was being developed, nobody thought
at the beginning it was going to be the smash hit
that it was. People liked it, they thought it was
nice, but nobody imagined it was going to be the
explosion of excitement and interest that it
became. So it was a surprise to everybody, that it
was a big hit.

— Frank Heart, director of the ARPANET infrastructure team

An early alternative to Unix called Tenex took this capability one step further. Tenex included the ability to send a message to another user by writing onto the end of a file which only they could read. This is conceptually very simple, you could implement it yourself by creating a file in everyones home directory which only they can read:

mkdir ~/messages
chmod 0442 ~/messages

Anyone who wants to send a message just has to append to the file:

echo “🍕?n” >> /Users/zack/messages

This is, of course, not a great system because anyone could delete your messages! I trust the Tenex implementation (called SNDMSG) was a bit more secure.


In 1971, the Tenex team had just gotten access to the ARPANET, the network of computers which was a main precursor to the Internet. The team quickly created a program called CPYNET which could be used to send files to remote computers, similar to FTP today.

One of these engineers, Ray Tomlinson, had the idea to combine the message files with CPYNET. He added a command which allowed you to append to a file. He also wired things up such that you could add an @ symbol and a remote machine name to your messages and the machine would automatically connect to that host and append to the right file. In other words, running:

SNDMSG [email protected]

Would append to the /Users/zack/messages file on the host cloudflare. And email was born!


The CPYNET format did not have much of a life outside of Tenex unfortunately. It was necessary to create a standard method of communication which every system could understand. Fortunately, this was also the goal of another similar protocol, FTP. FTP (the File Transfer Protocol) sought to create a single way by which different machines could transfer files over the ARPANET.

FTP originally didn’t include support for email. Around the time it was updated to use TCP (rather than the NCP protocol which ARPANET historically used) the MAIL command was added.

$ ftp
< open bbn

> 220 HELLO, this is the BBN mail service

< MAIL zack

> 354 Type mail, ended by <CRLF>.<CRLF>

< Sup?
< .

> 250 Mail stored

These commands were ultimately borrowed from FTP and formed the basis for the SMTP (Simple Mail Transfer Protocol) protocol in 1982.


The format for defining how a message should be transmitted (and often how it would be stored on disk) was first standardized in 1977:

Date : 27 Aug 1976 0932-PDT
From : Ken Davis <KDavis at Other-Host>
Subject : Re: The Syntax in the RFC
To : George Jones <Group at Host>,
Al Neuman at Mad-Host

There’s no way this is ever going anywhere…

Note that at this time the ‘at’ word could be used rather than the ‘@’ symbol. Also note that this use of headers before the message predates HTTP by almost fifteen years. This format remains nearly identical today.

The Fifth Edition of Unix used a very similar format for storing a users email messages on disk. Each user would have a file which contained their messages:

From MAILER-DAEMON Fri Jul 8 12:08:34 1974
From: Author <[email protected]>
To: Recipient <[email protected]>
Subject: Save $100 on floppy disks

They’re never gonna go out of style!

From MAILER-DAEMON Fri Jul 8 12:08:34 1974
From: Author <[email protected]>
To: Recipient <[email protected]>
Subject: Seriously, buy AAPL

You’ve never heard of it, you’ve never heard of me, but when you see
that stock symbol appear. Buy it.

– The Future

Each message began with the word ‘From’, meaning if a message happened to contain From at the beginning of a line it needed to be escaped lest the system think that’s the start of a new message:

From MAILER-DAEMON Fri Jul 8 12:08:34 2011
From: Author <[email protected]>
To: Recipient <[email protected]>
Subject: Sample message 1

This is the body.
>From (should be escaped).
There are 3 lines.

It was technically possible to interact with your email by simply editing your mailbox file, but it was much more common to use an email client. As you might expect there was a diversity of clients available, but a few are of historical note.

RD was an editor which was created by Lawrence Roberts who was actually the program manager for the ARPANET itself at the time. It was a set of macros on top of the Tenex text editor (TECO), which itself would later become Emacs.

RD was the first client to give us the ability to sort messages, save messages, and delete them. There was one key thing missing though: any integration between receiving a message and sending one. RD was strictly for consuming emails you had received, to reply to a message it was necessary to compose an entirely new message in SNDMSG or another tool.

That innovation came from MSG, which itself was an improvement on a client with the hilarious name BANANARD. MSG added the ability to reply to a message, in the words of Dave Crocker:

My subjective sense was that propagation of MSG resulted in an exponential explosion of email use, over roughly a 6-month period. The simplistic explanation is that people could now close the Shannon-Weaver communication loop with a single, simple command, rather than having to formulate each new message. In other words, email moved from the sending of independent messages into having a conversation.

Email wasn’t just allowing people to talk more easily, it was changing how they talk. In the words of C. R. Linklider and Albert Vezza in 1978:

One of the advantages of the message systems over letter mail was that, in an ARPANET message, one could write tersely and type imperfectly, even to an older person in a superior position and even to a person one did not know very well, and the recipient took no offense… Among the advantages of the network message services over the telephone were the fact that one could proceed immediately to the point without having to engage in small talk first, that the message services produced a preservable record, and that the sender and receiver did not have to be available at the same time.

The most popular client from this era was called MH and was composed of several command line utilities for doing various actions with and to your email.

$ mh

% show

(Message inbox:1)
Return-Path: joed
Received: by (5.54/ACS)
id AA08581; Mon, 09 Jan 1995 16:56:39 EST
Message-Id: <[email protected]>
To: angelac
Subject: Here’s the first message you asked for
Date: Mon, 09 Jan 1995 16:56:37 -0600
From: “Joe Doe” <joed>

Hi, Angela! You asked me to send you a message. Here it is.
I hope this is okay and that you can figure out how to use
that mail system.


You could reply to the message easily:

% repl

To: “Joe Doe” <joed>
cc: angelac
Subject: Re: Here’s the first message you asked for
In-reply-to: Your message of “Mon, 09 Jan 1995 16:56:37 -0600.”
<[email protected]>

% edit vi

You could then edit your reply in vim which is actually pretty cool.

Interestingly enough, in June of 1996 the guide “MH & xmh: Email for Users & Programmers” was actually the first book in history to be published on the Internet.

Pine, Elm & Mutt

All mail clients suck. This one just sucks less.

— Mutt Slogan

It took several years until terminals became powerful enough, and perhaps email pervasive enough, that a more graphical program was required. In 1986 Elm was introduced, which allowed you to interact with your email more interactively.

Elm Mail Client

This was followed by more graphical TUI clients like Mutt and Pine.

In the words of the University of Washington’s Pine team:

Our goal was to provide a mailer that naive users could use without fear of making mistakes. We wanted to cater to users who were less interested in learning the mechanics of using electronic mail than in doing their jobs; users who perhaps had some computer anxiety. We felt the way to do this was to have a system that didn’t do surprising things and provided immediate feedback on each operation; a mailer that had a limited set of carefully-selected functions.

These clients were becoming gradually easier and easier to use by non-technical people, and it was becoming clear how big of a deal this really was:

We in the ARPA community (and no doubt many others
outside it) have come to realize that we have in
our hands something very big, and possibly very
important. It is now plain to all of us that
message service over computer networks has
enormous potential for changing the way
communication is done in all sectors of our
society: military, civilian government, and


Its like when I did the referer field. I got nothing but grief for my choice
of spelling. I am now attempting to get the spelling corrected in the OED
since my spelling is used several billion times a minute more than theirs.

— Phillip Hallam-Baker on his spelling of ’Referer’ 2000

The first webmail client was created by Phillip Hallam-Baker at CERN in 1994. Its creation was early enough in the history of the web that it led to the identification of the need for the Content-Length header in POST requests.

Hotmail was released in 1996. The name was chosen because it included the letters HTML to emphasize it being ‘on the web’ (it was original stylized as ‘HoTMaiL’). When it was launched users were limited to 2MB of storage (at the time a 1.6GB hard drive was $399).

Hotmail was originally implemented using FreeBSD, but in a decision I’m sure every engineer regretted, it was moved to Windows 2000 after the service was bought by Microsoft. In 1999, hackers revealed a security flaw in Hotmail that permitted anybody to log in to any Hotmail account using the password ‘eh’. It took until 2001 for ‘hackers’ to realize you could access other people’s messages by swap usernames in the URL and guessing at a valid message number.

Gmail was famously created in 2004 as a ‘20% project’ of Paul Buchheit. Originally it wasn’t particularly believed in as a product within Google. They had to launch using a few hundred Pentium III computers no one else wanted, and it took three years before they had the resources to accept users without an invitation. It was notable both for being much closer to a desktop application (using AJAX) and for the unprecedented offer of 1GB of mail storage.

The Future

US Postal Mail Volume, KPCB

At this point email is a ubiquitous enough communication standard that it’s very possible postal mail as an everyday idea will die before I do. One thing which has not survived well is any attempt to replace email with a more complex messaging tool like Google Wave. With the rise of more targeted communication tools like Slack, Facebook, and Snapchat though, you never know.

There is, of course, a cost to that. The ancestors of the Internet were kind enough to give us a communication standard which is free, transparent, and standardized. It would be a shame to see the tech communication landscape move further and further into the world of locked gardens and proprietary schemas.

We’ll leave you with two quotes:

Mostly because it seemed like a neat idea. There was no directive to ‘go forth and invent e-mail’.

— Ray Tomlinson, answering a question about why he invented e-mail

Permit me to carry the doom-crying one step further. I am
curious whether the increasingly easy access to computers by
adolescents will have any effect, however small, on their social
development. Keep in mind that the social skills necessary for
interpersonal relationships are not taught; they are learned by
experience. Adolescence is probably the most important time period
for learning these skills. There are two directions for a cause-effect relationship.
Either people lacking social skills (shy people, etc.) turn to
other pasttimes, or people who do not devote enough time to human
interactions have difficulty learning social skills. I do
not [consider] whether either or both of these alternatives actually occur. I believe I am justified in asking whether computers will
compete with human interactions as a way of spending time?
Will they compete more effectively than other pasttimes?
If so, and if we permit computers
to become as ubiquitous as televisions, will computers have
some effect (either positive or negative) on personal development
of future generations?

— Gary Feldman, 1981

Use Cloudflare Apps to build tools which can be installed by millions of sites.
Build an app →
If you’re in San Francisco, London or Austin: work with us.

Our next post is on the history of the URL! Get notified when new apps and apps-related posts are released:

Email Address

(function($) {window.fnames = new Array(); window.ftypes = new Array();fnames[0]=’EMAIL’;ftypes[0]=’email’;fnames[1]=’FNAME’;ftypes[1]=’text’;fnames[2]=’LNAME’;ftypes[2]=’text’;}(jQuery));var $mcj = jQuery.noConflict(true);

/* Social */

.social {
margin-top: 1.3em;
.fb_iframe_widget {
padding-right: 1px;
.IN-widget {
padding-left: 11px;

/* Hide period after author */

.post-header .meta a {
border-right: 5px solid white;
margin-right: -5px;
position: relative;

/* Post */

body {
background-color: white;
pre, code {
font-size: inherit;
line-height: inherit;
section.primary-content {
font-size: 16px;
line-height: 1.6;
color: black;
blockquote {
padding-bottom: 1.5em;
padding-top: 1em;
font-style: italic;
font-size: 1.25rem;
blockquote.pull-quote-centered {
font-size: 1.2em;
text-align: center;
max-width: 100%;
margin-left: auto;
margin-right: auto;
blockquote blockquote {
margin-left: 1em;
padding-left: 1em;
border-left: 5px solid rgba(0, 0, 0, 0.2);
padding-bottom: 0.5em;
padding-top: 0.5em;
margin-bottom: 0.5em;
margin-top: 0.5em;
figure.standard {
position: relative;
max-width: 100%;
margin: 1em auto;
text-align: center;
z-index: -1;
.figcaption {
padding-top: .5em;
font-size: .8em;
color: #888;
font-weight: 300;
letter-spacing: .03em;
line-height: 1.35;
.figcontent {
display: inline-block;
p.attribution {
color: #666;
font-size: 0.9em;
padding-bottom: 1em;
a code.year {
text-decoration: underline;
.closing-cards #mc_embed_signup .mc-field-group {
margin: 0.75em 0;
.closing-cards #mc_embed_signup input {
font-size: 1.5em;
height: auto;
.closing-cards #mc_embed_signup input[type=”email”] {
border: 1px solid #bcbcbc;
border-radius: 2px;
margin-bottom: 0;
.closing-cards #mc_embed_signup input[type=”submit”] {
background: #f38020;
color: #fff;
padding: .8em 1em .8em 1em;
white-space: nowrap;
line-height: 1.2;
text-align: center;
border-radius: 2px;
border: 0;
display: inline-block;
text-rendering: optimizeLegibility;
-webkit-tap-highlight-color: transparent;
-webkit-font-smoothing: subpixel-antialiased;
user-select: none;
-webkit-appearance: none;
appearance: none;
letter-spacing: .04em;
text-indent: .04em;
cursor: pointer;
.closing-cards #mc_embed_signup div.mce_inline_error {
background-color: transparent;
color: #C33;
padding: 0;
display: inline-block;
font-size: 0.9em;
.closing-cards #mc_embed_signup p:not(:empty) {
line-height: 1.5;
margin-bottom: 2em;

.closing-cards #mc_embed_signup input[type=”email”] {
font-size: 20px !important;
width: 100% !important;
padding: .6em 1em !important;

.closing-cards #mc_embed_signup .mc-field-group {
margin: 0 !important;

.closing-cards #mc_embed_signup input[type=”submit”] {
font-size: 20px !important;
margin-top: .5em !important;
padding: .6em 1em !important;

.closing-cards #mc_embed_signup div.mce_inline_error {
padding: 0;
margin: 0;
color: #F38020 !important;

aside.section.learn-more {
display: none;

.closing-cards {
background: #eee;
width: 100%;
list-style-type: none;
margin-left: 0;
.closing-card {
width: calc(50% – 10px) !important;
font-size: 20px;
padding: 1.5em;
display: inline-block;
box-sizing: border-box;
vertical-align: top;

@media (max-width: 788px){
.closing-card {
width: 100% !important;
.closing-card + .closing-card {
border-top: 10px solid white;

Source: CloudFlare

A New API Binding: cloudflare-php

Back in May last year, one of my colleagues blogged about the introduction of our Python binding for the Cloudflare API and drew reference to our other bindings in Go and Node. Today we are complimenting this range by introducing a new official binding, this time in PHP.

This binding is available via Packagist as cloudflare/sdk, you can install it using Composer simply by running composer require cloudflare/sdk. We have documented various use-cases in our “Cloudflare PHP API Binding” KB article to help you get started.

Alternatively should you wish to help contribute, or just give us a star on GitHub, feel free to browse to the cloudflare-php source code.

PHP is a controversial language, and there is no doubt there are elements of bad design within the language (as is the case with many other languages). However, love it or hate it, PHP is a language of high adoption; as of September 2017 W3Techs report that PHP is used by 82.8% of all the websites whose server-side programming language is known. In creating this binding the question clearly wasn’t on the merits of PHP, but whether we wanted to help drive improvements to the developer experience for the sizeable number of developers integrating with us whilst using PHP.

In order to help those looking to contribute or build upon this library, I write this blog post to explain some of the design decisions made in putting this together.

Exclusively for PHP 7

PHP 5 initially introduced the ability for type hinting on the basis of classes and interfaces, this opened up (albeit seldom used) parametric polymorphic behaviour in PHP. Type hinting on the basis of interfaces made it easier for those developing in PHP to follow the Gang of Four’s famous guidance: “Program to an ‘interface’, not an ‘implementation’.”

Type hinting has slowly developed in PHP, in PHP 7.0 the ability for Scalar Type Hinting was released after a few rounds of RFCs. Additionally PHP 7.0 introduced Return Type Declarations, allowing return values to be type hinted in a similar way to argument type hinting. In this library we extensively use Scalar Type Hinting and Return Type Declarations thereby restricting the backward compatibility that’s available with PHP 5.

In order for backward compatibility to be available, these improvements to type hinting simply would not be implementable and the associated benefits would be lost. With Active Support no longer being offered to PHP 5.6 and Security Support little over a year away from disappearing for the entirety of PHP 5.x, we decided the additional coverage wasn’t worth the cost.

Object Composition

What do we mean by a software architecture? To me the term architecture conveys a notion of the core elements of the system, the pieces that are difficult to change. A foundation on which the rest must be built. Martin Fowler

When getting started with this package, you’ll notice there are 3 classes you’ll need to instantiate:

$key = new CloudflareAPIAuthAPIKey(‘[email protected]’, ‘apiKey’);
$adapter = new CloudflareAPIAdapterGuzzle($key);
$user = new CloudflareAPIEndpointsUser($adapter);

echo $user->getUserID();

The first class being instantiated is called APIKey (a few other classes for authentication are available). We then proceed to instantiate the Guzzle class and the APIKey object is then injected into the constructor of the Guzzle class. The Auth interface that the APIKey class implements is fairly simple:

namespace CloudflareAPIAuth;

interface Auth
public function getHeaders(): array;

The Adapter interface (which the Guzzle class implements) makes explicit that an object built on the Auth interface is expected to be injected into the constructor:

namespace CloudflareAPIAdapter;

use CloudflareAPIAuthAuth;
use PsrHttpMessageResponseInterface;

interface Adapter

public function __construct(Auth $auth, String $baseURI);


In doing so; we define that classes which implement the Adapter interface are to be composed using objects made from classes which implement the Auth interface.

So why am I explaining basic Dependency Injection here? It is critical to understand as the design of our API changes, the mechanisms for Authentication may vary independently of the HTTP Client or indeed API Endpoints themselves. Similarly the HTTP Client or the API Endpoints may vary independently of the other elements involved. Indeed, this package already contains three classes for the purpose of authentication (APIKey, UserServiceKey and None) which need to be interchangeably used. This package therefore considers the possibility for changes to different components in the API and seeks to allow these components to vary independently.

Dependency Injection is also used where the parameters for an API Endpoint become more complicated then what is permitted by simpler variables types; for example, this is done for defining the Target or Configuration when configuring a Page Rule:


$key = new CloudflareAPIAuthAPIKey(‘[email protected]’, ‘apiKey’);
$adapter = new CloudflareAPIAdapterGuzzle($key);
$zones = new CloudflareAPIEndpointsZones($adapter);

$zoneID = $zones->getZoneID(“”);

$pageRulesTarget = new CloudflareAPIConfigurationsPageRulesTargets(‘*’);

$pageRulesConfig = new CloudflareAPIConfigurationsPageRulesActions();

$pageRules = new CloudflareAPIEndpointsPageRules($adapter);
$pageRules->createPageRule($zoneID, $pageRulesTarget, $pageRulesConfig, true, 6);

The structure of this project is overall based on simple object composition; this provides a far more simple object model for the long-term and a design that provides higher flexibility. For example; should we later want to create an Endpoint class which is a composite of other Endpoints, it becomes fairly trivial for us to build this by implementing the same interface as the other Endpoint classes. As more code is added, we are able to keep the design of the software relatively thinly layered.

Testing/Mocking HTTP Requests

If you’re interesting in helping contribute to this repository; there are two key ways you can help:

Building out coverage of endpoints on our API
Building out test coverage of those endpoint classes

The PHP-FIG (PHP Framework Interop Group) put together a standard on how HTTP responses can be represented in an interface, this is described in the PSR-7 standard. This response interface is utilised by our HTTP Adapter interface in which responses to API requests are type hinted to this interface (PsrHttpMessageResponseInterface).

By using this standard, it’s easier to add further abstractions for additional HTTP clients and mock HTTP responses for unit testing. Let’s assume the JSON response is stored in the $response variable and we want to test the listIPs method in the IPs Endpoint class:

public function testListIPs() {
$stream = GuzzleHttpPsr7stream_for($response);
$response = new GuzzleHttpPsr7Response(200, [‘Content-Type’ => ‘application/json’], $stream);
$mock = $this->getMockBuilder(CloudflareAPIAdapterAdapter::class)->getMock();

->with($this->equalTo(‘ips’), $this->equalTo([])

$ips = new CloudflareAPIEndpointsIPs($mock);
$ips = $ips->listIPs();
$this->assertObjectHasAttribute(“ipv4_cidrs”, $ips);
$this->assertObjectHasAttribute(“ipv6_cidrs”, $ips);

We are able to build a simple mock of our Adapter interface by using the standardised PSR-7 response format, when we do so we are able to define what parameters PHPUnit expects to be passed to this mock. With a mock Adapter class in place we are able to test the IPs Endpoint class as any if it was using a real HTTP client.


Through building on modern versions of PHP, using good Object-Oriented Programming theory and allowing for effective testing we hope our PHP API binding provides a developer experience that is pleasant to build upon.

If you’re interesting in helping improve the design of this codebase, I’d encourage you to take a look at the PHP API binding source code on GitHub (and optionally give us a star).

If you work with Go or PHP and you’re interested in helping Cloudflare turn our high-traffic customer-facing API into an ever more modern service-oriented environment; we’re hiring for Web Engineers in San Francisco, Austin and London.
Source: CloudFlare