# The deep rabbit hole of email in cloud

- Link: https://www.agilicus.com/email-aws-ses-saml-sso/
- Published: 2020-10-06T18:24:36+00:00
- Author: Don Bowman

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](https://support.google.com/a/answer/6194963?hl=en).
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.