As one of our first posts, I’d like to describe some of the inner workings of June.ai and share with you some exciting things to come.
At June, we’re on a mission to build the future of communication using the best technologies and design to benefit society at large.
We started by taking a first principles approach to the problems around email communication by breaking them down to their basic components. We challenged original assumptions through research and experimentation. We then arrived at our conclusions by examining the evidence and asking ourselves — Where can we make a significant impact and what are the necessary improvements?
Today I’m going to walk you through how and why we’ve decided to build on top of email.
The Internet Message Format
The standards for a basic email message format is defined by RFC5322.
Email Headers
Email headers have a lot of invisible magic in them that most people never see in their day-to-day email use.
Some interesting headers include:
Message-Id, In-Reply-To, References: A message-id is a unique identifier of a message when it’s created. This is important when it comes to threading because threading happens when you reference the message-id you’re replying to in subsequent messages. There are a lot more rules around threading, but we hope to cover that topic more in depth in a follow up.
DMARC, DKIM, SPF: Email validation or anti-spoofing mechanisms to verify the IP address and domain, verify that the message came from that domain and verify that the message came from the right person. These validation steps are run every time you send an email message.
A lot of these anti-email spoofing mechanisms have been put in place because as the internet and email adoption grew, bad actors started using emails to spoof identity. Today, a lot of these spoofing attempts are thwarted, however, a new kind of identity theft emerged as spoofing became difficult: phishing. Phishing attempts happen when you receive emails from a source that is similar to a familiar email address. For example, you might receive an email from admin@G00GLE.com. Upon a quick glance, some people might not realize that it says the message is from g00gle, rather than google so inevitably people click on links in that message that might lead you to a fake sign-in page where a bad actor is now able to steal your password.
At June, we love email headers. At first glance they have a lot of archaic jargon, but if you look them up, they’re rich in useful information such as: how long it took to send, email aliases or email forwarding, etc…
Email Body
The body is what gets rendered on the email clients themselves.
One of the more interesting things I’ve noticed was how email has evolved over time. Back in the day, emails were read on terminal windows not on native clients or web browsers. Since then, most email clients send two bodies; one that’s plain-text and one that’s html.
Why should we built on top of email?
Email has one of the largest user base on the planet with roughly 3.8 billion email users sending hundreds of billions of messages every day. We wanted to build a communication hub that lives on top of email so that our end users can still reach anyone but experience their communication in a completely different way.
How do you build on top of email in a scalable and extensible way?
The first step when working with these emails is to take parts of the original raw email data and turn them into something that any modern developer can work with.
We call these pieces of original email data: the core data attributes. We took broad strokes of the original pieces and broke them down into bite sized pieces. However, even after we broke them down, we still needed to clean up or modify the data for building these different experiences that we wanted to try out.
When you’re building something new, you go through rapid successions of iterating, experimenting, failing and back to experimenting. We had to be prepared for rapid prototypes and hundreds of trials and errors, without getting bogged down on legacy code.
At June, we love our command line tools like git, yarn, and http because it let us do all sorts of creative tasks, blazingly fast. It’s great because each tool does something simple enough to remember and it does it reliably well. So we took this unix-inspired approach — Do one thing, and do it well.
We took this concept and designed a microservices architecture, but in a way where each microservice and data structure go hand in hand. Each microservice is able to contribute small calculations and simply appending the data to the core data object. This keeps original data immutable so that everything is closed for modification but open for extension.
Here are some of our favorite microservices and how they add to the original email data:
Chatter
This microservice parses and organizes conversations in order for them to be presented in a cleaner way to our end users. Chatter uses a combination of machine-learning and rule-based algorithms to structure original email data so anyone else can build on top of the cleaned data. Many of our other natural language processing microservices rely on carefully cleaned conversations (without quoted text and signatures) and chatter-generated data provides an easy way for the next set of microservices to focus on their specific tasks.
Shipping-Tracker
This microservice takes tracking numbers from the emails and fetches data from major shipping carriers in realtime. Notice that even though we have all this extra information, our design team did a great job of presenting the right information at the right time.
Requests
This microservice is a simple allow or disallow system. The output of this microservice seems simple, but in order to do this, it takes into account:
- sender info consolidated from multiple sources online
- the history of messages with this sender (received and how often, if you’ve replied, or percentages of messages that you’ve read from this person)
- the category of the message (for example: receipts pass through but promos get blocked if you requested to unsubscribe)
It also helps with phishing attempts because anyone new who contacts you, you’re able to clearly see sender information consolidated from public sources on the internet.
Building an Ecosystem
Since our inception back in 2016, we’ve built out 50+ microservices that live on top of your email and enhances them in ways only we thought of…
We hope to open these tools up to you soon so that you — developers, designers, and dreamers — can help connect the world in completely new ways. We would love to hear from you.
— John Jung, CTO and Co-Founder @ June.ai
A big thank you to Allie, Kaitlin, Jiayi, and Dan for helping me put this post together!
Connect with us, give us a shout, let’s build something new
Twitter: @junedotai / @johnjjung
Medium: June.ai
Facebook: June.ai
