The history of email

My first access to “the internet” was through a dialup modem on a VAX at the FDA. I was a summer intern there through my college career and then worked full time after graduation and before grad school. My email address ended in .bitnet. I could mail some places but not others. One of the places I couldn’t send mail was to my friends back on campus.
A few of those friends were computer science majors, so one weekend they tried to help me troubleshoot things. . There were text files that they ended up searching through looking up how to send mail from .bitnet to .edu. But it was all a baffling experience. Why couldn’t it just work? I had email, they had email, why could we not talk?
I never did figure out how to send email to campus from .bitnet.
Eventually, the FDA moved from BITNET to the internet and I had a .gov address. I could send mail around just by getting the recipients’s address. But the mystery of why I could mail some .edus and not others still lingers. I wonder what our setup was that we couldn’t send mail. I’ll probably never know. I don’t even have enough details to explain the problem to someone who would know. I suspect the answer will be “bang paths” or “host.txt” files, but I really don’t know.

Image of a DEC VAX
By Emiliano Russo, Associazione Culturale VerdeBinario – VAX_11-780_all.jpg, Public Domain
That’s one of the reasons I like reading articles about email before SMTP and before email clients. Today’s article was The History of Email posted by Zach Bloom at eager.io. Some things I knew, like how a line starting with the word From had to be escaped (although typically the client handled that). And that mutt is the mail client that sucks less. (I miss mutt, and still use it occasionally for bulk IMAP functions.) Some things I didn’t know, or didn’t remember. It’s possible I used MH back on that old VAX. It certainly wasn’t mutt or pine we used.
It’s an article well worth a read just to learn about the people who created SMTP. We’re also lucky that some of the folks named in the articles are still around and are still contributing to the life and growth of email. Their knowledge and institutional memory helps us map out the future.
 

Related Posts

Memories of Spam in May

This morning on Facebook a friend posted a picture saying that 15 years ago was the very first anti-spam conference (Spamcon*). All we have are some blurry scans of pictures and coffee mugs.
13322193_10209611310107693_488418243076278791_n.
That 550 sign belonged to the bar where the night out was held. It got bought by K & P and lived in their garden until it rotted away a few years ago. So many folks who are still active in the space, and so many folks who’ve moved on. Names I’d forgotten, faces I haven’t.
Many of those folks are still working in email. Some on the sending side, some on the tools and vendor side, some on the ISP side, some on the consulting side.  That conference was one of the very first times people publicly gathered to talk about spam. There were other occasions, but most were invite only with hand picked representatives of specific companies.
At that first Spamcon I was freshly laid off from MAPS (now Trend Micro). I was considering what next. The thing is, I really liked the work I was doing. MAPS had me leading a team to provide abuse desk as an outsourced service. We had a very large network provider as a customer and we were handling all the mail that came into abuse@ there. It was a challenge, I was creating processes and documenting policy, trying to do more with less and managing my first team ever.
Much of what I do now, here, grew out of that position. It was clear even then there was a need for someone who could help navigate the challenges of email.
In the same thread another person posted pictures from a social night in DC during the FTC Spam Forum. More folks, some I have lost touch with and some who are still friends and colleagues.
We were so young. All of us.
This is yet another form of community that email created. Some of it was built over email, but a lot of it happened on USENET and IRC and local meetups. There were so many ways we built community using plain text and dialup. The technology has changed, and that community from a dozen years ago has changed but it’s still all the same deep down inside.
SpamconMugs
 
(* If, at any point, you see me type Spamconk instead of Spamcon please blame autocorrect. It’s being difficult and even tries to correct it when I go back and edit sentences.)

Read More

The Physics of the Email Universe

We talk a lot about rules and best practices in email, but we’re mostly talking about “squishy” rules-of-thumb that are based on simplified models of how mail systems, spam filters, recipients, postmasters and blacklist operators behave. They’re the biology, ecology and sociology of the email ecosystem.
There’s another set of rules we tend to only mention in passing, if at all, though. They’re the steely, sharp-edged laws that control the email universe. They’re the RFCs that define how email works and make sure that mail systems written by hundreds of different people across the globe all work and all interoperate with each other.
Building a message from Zeros and Ones
RFC 5322 – Internet Message Format
This tells you everything you need to know about crafting a simple email, with a subject line, a sender, some recipients and a simple plain-text message. It’s also the foundation of all fancier emails. If you’re creating emails, this is where to start.
A little more than plain ASCII
RFC 2047 – MIME Part 3: Message Header Extensions for Non-ASCII Text
RFC 2047 is one small part of the MIME (Multipurpose Internet Mail Extensions) suite of protocols that allow you to include pictures and attachments and prettily formatted text and comic sans in your email. This part defines how you can put things other than the plainest of plain text in your subject lines or in the “friendly from” of your message. It’s what allows you to put Hiragana, or Cyrillic, or umlauts, or cedillas, or properly matched double quotes in your subject line. It also let’s you put hearts or smiley faces or other little pictograms there – but nothing this useful is going to be perfect.
RFC 2045 – MIME Part 1: Format of Internet Message Bodies
This shows how to send an image, or a plain text mail in a different character set, or an HTML mail. It doesn’t tell you how to send plain text and HTML, or to send HTML with embedded images, or a message with an attached document. For that you need…
Finally, Modern Email
RFC 2046 – MIME Part 2: Media Types
This builds on RFC 2045 to allow you to have many different chunks in a message – this is what you need if you want to send “proper” HTML mail with a plain text alternative, or if you want embedded images or attachments.
Getting From A To B
RFC 5321 – Simple Mail Transfer Protocol
A message isn’t much use unless you send it somewhere. RFC 5321 explains the mysteries of actually sending that message over the wire to the recipient. If you need to know about the different phases of a message delivery, what “4xx” and “5xx” actually mean, why there’s not really any such thing as a hard or soft bounce defined, just temporary or permanent failures, or anything else about actually sending mail or diagnosing mail delivery, this is your starting point.
The Rest Of The Iceberg
I’ve only touched on the very smallest tip of the email iceberg here. There’s much, much more – both in RFCs and ad-hoc non-RFC standards. If you’re interested in more, this is a decent place to start.

Read More

Ray Tomlinson

Ray Tomlinson has passed away. Mainstream obituaries are going to focus on his being “the creator of email” or “the sender of the first email” or “the inventor of the @ sign in email addresses“.
All of which are true. He did send the first (networked) email. He did use the (otherwise mostly unused on TENEX) @ sign to separate user and host.
But he did a lot of other things with the basics of the modern Internet that are more important than the @-sign.

Read More