Building a serverless email delivery service on AWS
medium.com
medium.com
Sounds like paying an office worker a few weeks to keep in touch with Microsoft/Google support plus hardware + employing sysadmins would be considerably cheaper than 200m/year.
That is, of course, unless you're spamming your users with undesired messages.
Using SES with the exact same emails, Gmail will block significantly less. The large providers are whitelisted and unless you're as large, you're not going to get that privilege.
Granted, for $200m you should be large enough to bribe a few Google people to get into the club, but for anything where it reasonably might be profitable to run it yourself and employ a sysadmin, you won't be able to afford that.
Yeah Gmail is actively filtering smaller providers. But from what i heard/read it appears after personally contacting them several times they will end up allowlisting you (like Microsoft).
Personally i don't care that Google won't let me talk to people. I treat google's email server like i treat a bourgeois café in a fancy district: there may be friendly people to have a chat with in there, but they definitely don't want me around and i have better places to be and better people to meet. Only a revolution can change this balance, and in the meantime i won't loose my energy trying to get into their club, but rather develop our decentralized clubs.
"We have received many reports from GMAil users that our messages were not delivered or delayed. Please provide an alternate address."
Somebody who knows somebody will see that and poke their contact for you.
Arguably, if you're operating a business and have a client using Gmail, you could have you and your client contact Google support to ask allowlisting, then sue Google for anti-competitive (monopolist) behavior if they don't comply. I don't know of a case like this, but it should be an easy win and would set an interesting precedent.
I'm personally not into legal stuff, but if some startup people around here with a few lawyers would try this approach... :)
If you keep attempting to email an address that bounces, over time, you may get marked as a spammy sender.
As far as I can tell, this setup doesn't do much with bounces other than quitting on a clear hard bounce from the end SMTP daemon.
This is one of the reasons email services aren't cheap.
SES uses account-level suppression lists, to avoid sending emails to addresses that has complaints, hard bounced or soft bounced a number of times. It does not automatically handle bounces sent over email, and I've not seen a provider out there doing that but I could be missing it.
We do manually monitor those however, by having the FROM address directed at an inbox that we monitor. Out of the 4M emails we send per month, we only get one bounce email back. And that's not really a bounce but a "please confirm you are real" bounce.
This could probably be automated with SES too, by parsing incoming emails and adding addresses to bounce list. For that 1 email per month we decided not to add that complexity.
Note: This setup is used for transactional emails, where users opt in via account creation and the first email sent is a verification email, to check that the address is real and that the user owns it.
However, my experience was that you also had to do something with soft bounces. For example, if someone's mailbox is perpetually full, re-sending to it over and over still can still eventually hurt your sending reputation.
If one wants to go further than just one-off emails, listmonk by Zerodha, a fintech company that builds most of its tech in-house, is pretty decent for an email-list manager. It one-click deploys to Heroku and the only dependency is Postgres. It could use SES as its SMTP server.
Prior to Listmonk I used Mailtrain[0] and like Listmonk so much I want to run it as a service (with 30% donated back to the Listmonk project of course) -- deliverability worries and initial setup aside it's just the kind of minimal tool I've come to love these days.
Hey hardwaresofton, this is exactly what we're planning to do on https://srv.io/ :)
The platform is mostly ready, and we're just finishing some infrastructure changes to allow the platform to run third-party applications safely. We are planning to include Listmonk in a second batch of the applications to release.
I personally enjoy working with Listmonk, it has replaced Sendy[0] for me.
[0]: https://sendy.co/
Glad someone else is thinking along the same lines! F/OSS could be so much better with the help of platforms — there’s space for a win win as long as the platform side just pares down the greed a tiny bit.
Just the other day I was wondering why there aren't "software maintainence/repair shops" as there are for hardware (PCs, gadgets, appliances). A tech shop like srv.io is exactly what I was wondering existed. Surely there is a market for it. I wish you (and your competitors) all the very best!
More than theory: https://www.google.com/search?hl=en&q=tcp%2Dover%2Ddns
Given as a Google search rather than a concrete link because it's really a rich field. It did take me a few tries to get the right search term.
About testing: It's not that different from any other runtime. I admit, I put a lot of code into the same file in the examples as it was easier displaying the code that way. I tend to keep the handler of the lambda very lightweight and then test the functions that the handler calls. That way it's just unit testing and mocking away dependencies. The functions are pretty small so naive dependency injection works fine. AWS docs covers testing of Lambdas a bit here: https://docs.aws.amazon.com/whitepapers/latest/serverless-ar...
It uses node to compile templates into html, but there is also an API available. Perfect, because my serverside project has no other need for node.