Articles by Tim Jenkins


Tim Jenkins

Tim is a Co-founder and Chief Technology Officer at SendGrid.

Boats and Clouds: Choosing the Right Engine for Your Email Program

Tim Jenkins Product
Propeller. Flat web icon or sign isolated on grey background. Collection modern trend concept design style vector illustration symbol

Around 14 years ago, I got to experience one of the happiest days of a boat owner’s life; the day I bought it. In some respects it wasn’t exactly a happy day, since it broke down on its test run and we found out that the radio was busted. Since then, I’ve had to do a ton of maintenance on the engine, including replacing it. Fortunately, it uses a pretty standard Chevy 350 engine, which was used in millions of vehicles for decades, so even though the engine goes out often, it isn’t impossible to replace and get things running again. Making Sure Every Piece Fits I’m sure you’re wondering why I’m talking about boat motors and how they relate


Confirming Why SendGrid Built Its Own MTA

Tim Jenkins Company
server room

A number of people, both inside SendGrid and out, have asked me about our decision to build our own message transfer agent (MTA) versus using one of the commercial products that exist in the market. In light of recent market news concerning the merger of two commercial MTA vendors, I thought it would be a good time to share my thoughts on this. Back in the day In the very beginning, SendGrid used a modified version of Postfix, one of the most popular open source MTAs, to receive and deliver email. This worked pretty well until we started running into some of its scaling limitations. Postfix is a really great MTA for most cases, but at the scale we were


SendGrid’s Experience Converting Relay Service to Go

Tim Jenkins Community, Company, Technical
golang gopher

Last year I talked about SendGrid’s decision to use Go as our primary development language. For the most part this has affected only new services. Recently though, we have completed a rewrite of one of our highest load components to Go and I thought I would share the story and some of the lessons learned. Background As some background, almost a year ago one of our engineers who was helping to make the pitch of why we should use Go rewrote the service that handles final customer IP selection/transmission of data to remote SMTP servers as a proof of concept/example of how awesome Go is. Some time later, at an internal hackathon, he made even more progress. While this was


The Myth of Opportunistic TLS and Email Privacy

Tim Jenkins Product
email security

Back in June, SendGrid joined a large group of Internet companies in the effort to prevent dragnet surveillance of customer traffic. On our part this specifically involved adding opportunistic TLS—encrypting traffic to any mail server that supports it. While this does move us closer to the goal of complete customer privacy, there are some caveats that aren’t often talked about. Opportunistic TLS does provide better privacy than sending everything cleartext, but it does not provide any protection against an attacker attempting to hijack traffic to a specific domain. All an attacker needs to do is take over the domain, not advertise TLS capabilities, capture, and then proxy the data back to the real mail server, and no one would be


Looking Up: 5 Years of Scaling Our Technology and Our People

Tim Jenkins Company
Tim Quote

Recently, SendGrid celebrated five years since we formed the company. Five years and over 270 billion emails later, I want to share some of my thoughts on some key lessons I’ve learned along the way. Design For Failure One of the biggest mistakes we made in the initial creation of SendGrid was focusing on getting a feature working, and then moving on to the next piece. While this was all well and good at low scale, once you have millions of messages going through the system every minute, the “one in a million” error cases start happening very regularly. Even just putting in proper error handling isn’t good enough; the system as a whole needs to be designed to work


How to Convince Your Company to Go With Golang

Tim Jenkins Technical
gopher

Recently, SendGrid decided to move to using Go as its primary development language. This has been a long-standing internal battle, which I hear has happened and is continuing to happen in a number of organizations. I figured it would be productive to share our experience here, not just in why we chose to move forward with Go, but how this process played out, so that others in a similar situation can make a compelling argument for Go. Why We Needed a Change For some background, the backend systems of SendGrid were primarily written in Perl/AnyEvent in the first years, moving to Python/Twisted later on. We looked into using the Gevent framework for Python, but during an inception meeting we realized


SendGrid’s Parse API: Parsing Incoming Email is Now Faster and Easier

Tim Jenkins Product, Technical
Parse API diagram

What is SendGrid’s Parse API? Email from friends is interactive. It’s a conversation and that’s not always the case for commercial emails. Our customers are adding more back-and-forth to their campaigns with our Parse API, whose growth in the last year has nearly tripled. The Parse API lets your app accept incoming email, including attachments, and perform some operation on the content. With more customers taking advantage of that power, we decided to polish it up to work better and share more about how it can be used.     Yesterday Swift (a SendGrid evangelist) and development shop thoughtbot held a webcast on using the Parse API in Ruby on Rails. They covered using an open source Ruby gem originally


Which protocol should I use to send email, SMTP or REST?

Tim Jenkins Best Practices, Product, Technical
OMG_

We get asked quite often why we recommend customers use SMTP to send email to SendGrid, as opposed to using our REST API, and where one would be used over the other.  For options on how to integrate with SendGrid go here. To start, the absolute best method to send email through SendGrid is to set up a local mail server that queues all email from your application, and then relays the messages through SendGrid as a smart host.  This will have the least latency from your application’s perspective, and has the added benefit of handing your email off to a server that is fault tolerant.  If something goes wrong with internet connectivity between your servers and ours, a local