We know that deploying MTA-STS better secures inbound email and can prevent MITM and downgrade attacks. But you need a public web server to host the ~/.well-known/mta-sts.txt file. Not everyone has access to a web server they can use for this purpose, and even if they did, securing, patching, monitoring and maintaining a web server costs time (labor costs), not to mention actual hosting costs. In this blog post, I’ll show you how to host your required MTA-STS text file efficiently and securely on Amazon Web Services for pennies per month.
Note that this blog post presumes you’ve already accepted the benefits of deploying MTA-STS, and that you are familiar with MTA-STS concepts, including TLS reporting. Chances are good you’ve also already deployed a strict SPF record, are doing DKIM signing and have a strict DMARC record (with reporting) already configured as well, to prevent domain spoofing. Deploying MTA-STS is the last step; you know what you need to do — you just need to figure out a low-maintenance, secure and cost-effective way to host that pesky mta-sts.txt file. Here’s how:
If you haven’t done so already, go get an Amazon Web Services (“AWS”) account. If you are new to AWS, you are going to need to do some homework and learn about S3 object storage buckets, Cloudfront and Certificate Manager. AWS’s documentation is excellent, with specific “how-to” guides. Your AWS learning curve may be a bit steep, but it won’t be too tall.
First, you’ll configure an S3 bucket as a public web server to hold the ~/.well-known/mta-sts.txt file. S3 storage costs 2.3 cents per GB per month. Our file is ~216 bytes. Storage costs will be virtually nothing. S3 retrieval costs are $0.0004 per each 1,000 GET requests. This could be a few pennies per day at most, and the first 20K GET requests each month are free anyway. Plus, CloudFront does caching. I suggest using a long “max_age” parameter to increase CloudFront caching (and further lower your costs). You can use our mta-sts.txt file as an example if you need one.
S3 HTTP-Only Issue: AWS S3 buckets, when configured to host a static website, only support http not https (and MTA-STS absolutely requires https), so you will need to create a CloudFront Distribution to act as the https go-between to S3. AWS CloudFront’s free tier allows for 1TB of data transfer out and 10,000,000 https requests each month. After that, you will pay 8.5 cents per GB out per month, plus one cent for each additional 10,000 https requests. Even if you have a busy email system, with CloudFront caching you will likely not exceed the free tier, and even if you do, it will likely be only a few cents per month.
So where are we so far? Well, so far our S3 storage costs are maybe a few pennies per month, and Cloudfront looks to be essentially free, so all we need is an SSL certificate for the site mta-sts.yourdomain.tld. You can’t run certbot in CloudFront, so no LetsEncrypt certificates are possible, and paying for a commercial SSL certificate and having to deal with the renewals is expensive and a pain. Well, guess what?
AWS Certificate Manager-issued certificates are free when used with AWS services like CloudFront. Just follow the AWS documentation to configure your SSL certificate and have it automagically deployed in CloudFront. Easy peasy!
Final Status:
- Our S3 storage costs are perhaps a few pennies per month.
- Our https costs are likely to be entirely free; CloudFront may cost a few cents, but the needed SSL certificate is free.
- Security of S3 and CloudFront is handled entirely by AWS; we have no web server to secure, monitor, patch, maintain, lifecycle, etc., so once this environment is set up on AWS, our imputed labor costs are pretty much zero too.
And that’s how you can deploy MTA-STS, easily, securely, and for just pennies per month!
Would you like help deploying MTA-STS for your Zimbra environment? Fill out the form to start the conversation:
Hope that helps,
L. Mark Stone
Mission Critical Email LLC
12 October 2022
The information provided in this blog is intended for informational and educational purposes only. The views expressed herein are those of Mr. Stone personally. The contents of this site are not intended as advice for any purpose and are subject to change without notice. Mission Critical Email makes no warranties of any kind regarding the accuracy or completeness of any information on this site, and we make no representations regarding whether such information is up-to-date or applicable to any particular situation. All copyrights are reserved by Mr. Stone. Any portion of the material on this site may be used for personal or educational purposes provided appropriate attribution is given to Mr. Stone and this blog.
