0x4447_product_s3_email: a serverless email server built on S3, SES and Lambda

The problem 0x4447_product_s3_email removes: mail servers you have to feed

Running a conventional mail server means owning the parts that break: the SMTP daemon, the spam filter, the storage, the TLS certificates, the queue. The README describes the stack as a reaction to exactly that, saying there was no easy way to have a full email server "without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages." The answer here is to stop running a mail server and let AWS SES do the protocol work.

What you get instead is a mailbox that is really an S3 bucket. There is no interface, by design. The README calls it "an unmanaged email server with unlimited email addresses." The audience is narrow and specific: someone with a domain, an AWS account, and a preference for reading mail through the AWS console or the S3 API rather than a mail client. If you want a mailbox you can open on a phone, this is the wrong shape of product, and the README does not pretend otherwise.

How the pieces fit: SES receives, S3 stores, Lambda sorts

The deployment creates one SES rule set, two S3 buckets (one for CodePipeline artifacts, one for the email itself), three CodePipelines, three CodeBuilds, three Lambdas and one IAM group. The README lists those counts directly, and the repository layout mirrors them: the CloudFormation template is split across 01_Description, 02_Metadata, 03_Parameters, 05_Conditions and 07_Resources, with buildspec.yml driving the builds.

The receiving path is described in three steps. An email arrives at SES and is stored in a TMP folder in S3. That write triggers the inbound Lambda, which organizes the message using the to, from and date fields, and decides between the Inbox and Sent folders by checking whether the to field contains a domain registered in SES. A message addressed to your own domain lands in Inbox; anything else is treated as outbound and goes to Sent. That second folder write triggers another Lambda, which loads the raw message, converts it to .html and .txt, and stores those next to the original.

The addressing scheme is the part that changes how you work. Any string in front of the @ works once the domain is confirmed, and the plus character is rewritten as a slash, which is a path separator in S3. So [email protected] becomes a nested object path rather than a label you have to filter on. The README's client example, [email protected], shows the intent: the folder tree is the filing system, and you never write a rule to create it.

Deploying 0x4447_product_s3_email from the CloudFormation console

There is no package manager step and no local install. The README's deploy instructions are a single CloudFormation launch, either through the button in the repository or by downloading the template and creating the stack yourself. The template URL the README gives is https://s3.amazonaws.com/0x4447-drive-cloudformation/s3-email.json and the suggested stack name is zer0x4447-S3-Email.

The README offers no CLI command of its own, so the only concrete artifact to copy is the template location itself:

https://s3.amazonaws.com/0x4447-drive-cloudformation/s3-email.json

That URL is what the README points to both for the launch button and for the manual download option. If you take the manual route, you upload that template through the CloudFormation console in your AWS Dashboard and follow the prompts there.

After the stack reaches a complete state, three manual steps remain, and the README is blunt that "everything may not work right out of the box." First, add your domain in the SES console under Domains, click Verify a New Domain, enter the domain, select Generate DKIM Settings, and wait for the status to move from pending verification to verified. Second, open Email receiving in SES, tick 0x4447_S3_Email on the All rule sets tab, and click Set as active. The README attributes the need for this to a known CloudFormation behavior in SES, and notes that fresh accounts usually have it enabled already. Third, attach a user to the IAM group the stack created, which carries the minimum policy needed to read and create objects in the email bucket.

For the first real test, send a message from an outside account to any address at your verified domain, including a plus form such as [email protected]. You should see the raw message appear under TMP first, then in a nested Inbox path that matches the plus segments.

SES limits decide whether this can send at all

The README devotes a short section to two SES restrictions, and they are the most consequential facts on the page. By default AWS allows 200 emails per 24 hours at a rate of 1 email per second, and raising that requires asking AWS. Separately, the default account cannot send to unverified addresses, so outbound mail to arbitrary recipients needs an AWS-side change before it will leave the account.

That means the stack is not symmetric on arrival. Receiving works as soon as the domain is verified and the rule set is active. Sending is the half that depends on a support request you have not filed yet. Anyone evaluating this as a replacement for a transactional email provider should treat the sandbox as the starting state, not as a configuration detail.

The other limitation is structural rather than regulatory: with no interface, there is no search UI, no thread view, no draft folder, and no push notification. The README presents this as the point, but it also means that reading mail depends on the S3 console or your own tooling against the bucket. Converting a message to .html and .txt gives you something renderable, not something a mail client will sync.

Where auto deploy helps and where the branch advice matters

The stack wires three CodePipelines so that a push to a selected branch updates the Lambda functions for you. The README names two branches: master, described as the latest stable code, and development, described as unstable code tested in their environment and explicitly not recommended for use. If you fork the project and point a pipeline at your own branch, that advice is the one to keep.

The release history tells a different story than the pipeline does. The most recent tagged release is v1.6.0 from 2020-03-01, described as "Conditional webhook," preceded by v1.5.1 in January 2020 and 1.5.0 in August 2019. The repository's last push was on 2026-07-15, so work has continued since those tags, but the tagged releases are the only version markers the material provides. Do not assume a tagged version corresponds to the current state of master.

Upgrade cost is therefore mostly AWS-side. Because the template provisions CodeBuild and CodePipeline, a rebuild consumes those services on every push, and the Lambda runtimes will need attention as AWS deprecates runtime versions. The README does not document a rollback procedure for a bad pipeline run, so plan on CloudFormation stack rollback semantics rather than anything the project provides.

Licence and the as-is disclaimer

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept. The README adds a separate disclaimer on top of the licence: the stack is available at no cost "on an as-is basis," and 0x4447 LLC states it is not responsible for damages or costs of any kind arising from use, with full responsibility falling on the user.

Those two statements do different jobs. MIT governs the code. The disclaimer speaks to the AWS bill and to operational outcomes, which the licence never covers anyway. Running this stack means paying for S3 storage, Lambda invocations, SES, CodePipeline and CodeBuild on your own account, and nothing in the repository caps that spend. The README also points to the company's products page as the way to support the project; that is a funding note, not a licence term.

Editorial conclusion

Adopt it if you already run AWS, want a mailbox with no server to patch, and accept that sending is capped by SES sandbox limits until you ask AWS for more. Do not adopt it if you need a webmail interface, a mobile client over IMAP, or a mail server you can move to another provider. Before deploying, verify that the SES rule set named 0x4447_S3_Email is active, that your domain shows as verified in the SES console, and that a user has been attached to the IAM group the stack creates, because the README states the deployment does not do all of that for you.

Frequently asked questions

Official sources

1. 0x4447/0x4447_product_s3_email on GitHub
2. License: MIT
3. Project website
4. README
5. Releases