Email. Its been around longer than most of your reading this. Its had its ups and downs in popularity as other messaging has come and gone, but remains a staple of the worlds communication. And, as a staple of communication, it has attracted a reasonable number of scammers and advertisers, phishing, etc. Up until a few years ago it was common to find open-relays, allowing anyone to spoof anything. But, anti-spam measures clamped down, and this subsided somewhat. One of those common measures is blocking port 25. And that is what we will discuss today.
A customer came to me with a trivially simple need. “My application can only send email to my team, I need it to send (transactional) email to the world.” No problem, I got this, I’m wrangling millions of lines of open source, cloud this, api that, should be simple, right?
Well, Google Cloud blocks port 25. And, you can’t send email (generically) without that TCP port. Hmm. Their recommended solution is to buy SendGrid/MailJet/MailGun SMTP services. I have no conceptual problem with that, but, none of them will federate their login to our domain, no 2-factor authentication. And that, my friends, I have a problem with. How can I offer a secure service to my customer if part of it is done insecurely? I would have to share the login w/ a team member in case something happened to me, if that person left the company how would I control it, etc. Its essentially writing a blank cheque against your reputation. Hmm.
So, as you might imagine, I took the path less travelled. Amazon has a service called SES. It purports to do what I want (verify a domain, send some email). And, I can federate the login to Amazon with my G (formerly Suite now Workspace as of this am) login. SAML SSO. This wasn’t too hard to set up, but its a bit surprising, these federated users behave differently, not showing up in the IAM, sort of hiding out on the edge with a concept called a Role. Anyway, both web interfaces opened, some XML metadata discovery documents exchanged, and we can login without a password.
What’s this? Amazon won’t let me send email? Oh, its because they don’t know me (yet). I must open a Case and ask permission. I guess this is for the best, they don’t want someone showing up with a stolen credit card and some drive-by-spam.
Once I have the Amazon SES setup, I will have to create an SMTP identity, something something mutual TLS transport, and something something SPIFFE SPIRE agent with Istio Service Mesh in our Kubernetes cluster, and, my customer should be happy. I’ll need them to add an SPF and DKIM record to their DNS and we’ll be good to go.
Email. It only looks easy.