Your setup seems sane and pretty close to what would be if you want to run the same thing on a single server.

It makes the code base in the original link looks like a proprietary duct tape spaghetti :P

I just recommend setup postscreen[1] and rspamd[2].

1. http://www.postfix.org/POSTSCREEN_README.html

2. https://www.rspamd.com/

Yeah, I totally understand the desire. And even hosting this on a cloud, you benefit from SMTP TLS sometimes, presuming no active MITM and the cloud service not actively abusing its privileges on your VM or storage. Which is probably not happening widely. At least as opposed to the protocol level logging that SES or similar services do for sure.

I recently opened some new accounts at AWS and other large one for a new company... first thing to do is setup mail of course. Both denied my request to allow SMTP. AWS ominously rejected me with some vague "maybe one or more of these reasons" including prior ToS violations or payment issues with "linked" accounts.

Frankly it's scary, and so far they are stonewalling me on any details as to what I "may" have done. AWS is one place I sure don't want to have a bad reputation with.

This will be a great post with lots of traffic I imagine!

Thanks, great work!

Since you are running everything in docker this could probably be made easier by using a slimmed down distro with automatic updates.

You'll still need to make sure your docker images are updated and patched though.

I have being running it on a instance with 1 GB ram and it is running pretty smoothly.

But both solutions are kind for developers, not for end-users.

1. Someone else maintains the software running these services, including OS upgrades, security upgrades and patches, uptime monitoring, etc.

2. Since every logical component is an independent service, each scaling independently, any one single component is unlikely to become a bottle-neck while scaling. In traditional monolithic servers, you'll have to have contingency plans if you beat storage/network/CPU/RAM limits

3. The closest thing to this is to break up a monolithic email server into microservices and deploy them as independently scalable containers, which is a considerable engineering effort.

Assuming this works as advertised, you can go from zero to a full blown email service for organizations with thousands of people (assuming the stated AWS limits are lifted), in record time

But a quick Google search is all that it would take to “understand it”

https://en.wikipedia.org/wiki/Serverless_computing

I suspect the "serverless" word was created due to the emotional appeal to a specific (majority) group that is strongly opinionated against having servers at all.

Reading from the README.md file:

  There are two major limitations with SES:

    For security reasons, AWS defaults to 200 emails sent per 24 hour period at a rate of 1 email/second. If you need to send more than that, you'll need to ask AWS to increase your limit.
    By default, you can't send emails to unverified addresses. If you'd like to be able to send (as opposed to just receiving), you'll need to reach out to AWS to remove this limitation from your account.

But all it means is "we manage the server, both physically but also its operating system, you just bring your application code and we'll run it".

But to your second point, I agree. the technical hurdle required to learn all the configuration and moving parts ... And then to know that this language is vendor specific... Makes it less palatable.

That's why I expect the cloud vendors to normalize their offerings over time. I should be able to take a CloudFormation template from aws and put it through Googles Deployment Manager

* Not having to manage a server.

* Not having to have dedicated resources which can be wasteful.

* Having an architecture that scales.

When most people talk about serverless, they mean something that solves all three of those problems. When I think of serverless, I think it only needs to solve the first problem.

What if I don't want to manage a server, but I want dedicated resources? I just want to deploy a standard web app (written with node js for example) with a postgres backend and preallocated resources but without having to maintain a server? Is that serverless?

> Serverless computing is a cloud-computing execution model in which the cloud provider runs the server

...so, there is a server? What's with the name, then?

PaaS = your data + code to run it. Servers automatically provided.

SaaS = your data. Code and servers are automatically provided.

Serverless is just another name for PaaS where your bring your code, which can be deployed as a single JS function in a text file or an entire container running anything.

It's just very detailed.

It also includes all the CI/CD services/roles they used.

28 boxes alone are permissions related.

The stuff that runs in the end (like a server would) are 3 Lambda functions and an S3 bucket.

As we aimed to be an ever evolving civilization, it was decided that our language should then be, also, ever evolving. Once a month, during The Update -our most significant celebration where new discoveries, thought trends, etc, were presented to the population at large- a time was reserved for the ritual of language renovation. A number of random words, somewhere in the range of 30 to 50, were marked as outdated while a similar number, again from 30 to 50, of new words was introduced into the language as the words to show you were current with your civic duties of evolution and progress.

Usage of so called outdated words wasn't re-classified as a crime until much later, and only as a way to better enforce the goal of Continuous Progress. For some time you were just seen as an outcast or simply as one of the billions of poor people. Poverty was not so much defined in economic terms mainly because it wouldn't have meant much, with what happened in 2043 and all that. Instead being poor now meant you were someone that did not have access to enough information to participate in the careless happiness of Continuous Progress. But as I said, not keeping up with language evolution is now considered an offence and repeater offenders are forced to undergo re-adjustment.

Of course, after a short period of going through this, it was noticed that it's not so easy to continuously come up with new words and not make the language a unintelligible garble. And so words are recycled rather than discarded, which was a wasteful and unsustainable thing to do anyway.

-- Excerpt from "A Visitor in Cybernus" - a "recollection of future history" from Sean M. Ferion. 2007. Sadly out of print and very difficult to find.

If its any consolation, at this years Vegas AWS love-fest, most people started walking out once the Amazon presenter started talking 'serverless' recipes

It means the same thing as "cloud:" You're renting someone else's server.

While this is a cool project, you'd use 3 different servers at a minimum here.

Are there a lot of requests made or am I missing something else?

I wish you all the best! Mind if I ask for the link?

> With (1), there is no need to worry about overages, but scaling the mail server might be challenging.

Honestly, quite the opposite.

1. Duplicate your MX box.

2. Duplicate your MX record.

That is it :)

> I am writing the mail processing daemon ... in Rust...

You might like to take a look in https://github.com/mailman/mailman for ideas/inspiration. It's a great tool for processing emails too, but cannot deny I'm now curious to see how one in rust will look like.

I use Postfix/dovecot to self host.

Anyway, what is the point in moving from one Giant to another Giant? :-) Unless it saves the cost, I don't see the benefit of such hassle.

By tying your entire email system to a single cloud provider?

This is lock-in on steroids. (Oh, and zero privacy)

i.e. emails are received and put into specific buckets/folders and then, per message, a process is triggered to do something unique (put into database, forward to another IMAP'ed box, etc.)

I also think the JSON here is only for sending, not for receiving—I presume that you’ll receive the MIME message, because otherwise you’d be throwing away all kinds of essential information.

All of this gets you basically nowhere along the path to JMAP, and achieving a JMAP endpoint would be a lot of effort. This project doesn’t look to be at all suitable as a base for such an endeavour. Things like sorting (e.g. newest first), querying (e.g. emails from so-and-so) and JMAP’s state management (so the server can tell you “something changed” and you can ask the server to tell you what changed since x, rather than needing to throw everything away and start again) don’t work well within the design of this system—you need to store lots of extra details along the way, maintaining indexes and other such things.

For such an endeavour, I would instead recommend either wrapping an existing mail server in serverless voodoo (much of which I expect to be not too hard: you’re essentially just replacing ingress and egress and not running it as a daemon; but there will be architecturally difficult parts like getting push channels working probably), or starting new mail server software from scratch designed to be able to work serverless.

(I work for Fastmail on our webmail. I have general knowledge of how mail servers work internally, but little specific knowledge; for example, I have no idea how amenable Cyrus, which we use and develop, would be to serverless packaging.)