They aren’t wrong, running your own email server on the internet is up there with rolling your own crypto in the list of technical things you should never do.
I’ve been running my own email server ever since I was on dialup (yes!), more than 20 years now. I do not agree. Smtp is actually a resilient protocol which doesn’t require 100% uptime, just sensible configuration which is not that hard to check and very low maintenance once setup. There are many excellent smtp servers nowadays which do this almost automatically.
But I’ve seen this statement repeated over and over and over.
The main issue with smtp for me has been the complete arrogance of the biggest players in the field like gmail, hotmail, etc. The dwindling number of independent smtp servers has been shrinking, making them even more powerful every year. Yet, they are the number #1 source of spam for my host currently (open proxies and relays are incredibly rare for me nowdays). Spam from their network gets a green pass and checks all the boxes: however they provide only black-hole-style spam reporting on their end while blocking almost everyone else with automated checks with zero intervention.
I hate to see that email is being centralized further and further. It’s actually decreasing the quality of the service for everybody else.
@ $WORK, we max at about 5k emails a day. Our daily average is about 1,500 emails a day, giving us about 100k/emails a month. We aren’t huge by any means, but we would spend ~ $100/month with any professional email sending service(sendgrid, mailgun, etc). We instead do our own email. We send things like purchase orders, payroll info, timesheets and other backoffice/accounting stuff via email, we are not spam by any means. We have a special domain just for this stuff, outside of the organizational domain, we own address space direct from ARIN, etc.
The big players when getting annoyed at you usually at least send along a URL saying oh hey, we are mad at you, go here for details. It’s usually a few clicks and a little babysitting and life is good again, until they get annoyed again a month or 6 down the line.
It’s all the small players that are annoying, you get nothing just a SMTP 550, their postmaster@ isn’t working or is ignored, so you are stuck trying to track down a human to fix their blasted email server.
That said, I 100% agree with you, if one of the big people get REALLY annoyed at you, there isn’t anything you can do. Most of our email is internal to our organization(s) we do payroll and what not for, so we have exceptions with their mail provider, to mostly bypass the insanity for them, which helps a lot.
IF you are going to run your own mail server, PLEASE turn on postmaster@ and have it go somewhere you actually READ. There are a bunch of other RFC’d email addresses you should also turn on (webmaster@, security@, etc)
Fun read, one small nit: the crontab entry running every 5 minutes should be more easily expressed as “*/5” instead of the explicit “0,5,10,15,20,25,30,35,40,45,50,55”.
I’m the author of the post. I hadn’t heard of Migadu before, but it almost looks like it would work. The only issue is their Micro plan ($19/year) only allows 200 inbound emails per day. I guess that may not be an issue most of the time, but there are days where I receive more than 200 emails. The inability to control how much inbound email you are receiving makes me hesitant to use such a service.
I also use migadu for a family account. The thing I really like about it is that you can add as many accounts as you like for your domain: this@my.domain, that@my.domain, theother@my.domain, it’s so nice.
But yes, the 200-in limit has been my concern too. I subscribe to a few mailing lists and have a worry that one day some big heated mailing list conversation will put me over. This FAQ answer suggests they are lenient and that emails won’t actually be lost (assuming senders follow correct email practices!), but my tentative plan has been to wait and see if I ever get a warning email, and upgrade to the next tier if it becomes an issue. It hasn’t so far, after a year or so.
For what it’s worth, it’s not a hard limit. They won’t block the 201st email — if it’s a recurring thing, they’ll ask you to upgrade. This is mentioned in their docs, somewhere. cc @jeremyevans
I checked and it is in their documentation. So maybe that would have been a simpler option. I might have switched to Migadu instead of using a VM if I had known about it first. I think the only issue is the next level up from the $19/year plan is the $90/year plan, which is a pretty significant jump. But for someone who isn’t likely to go over their limits, Migadu looks like a really nice option.
Which email client(s) do you use? Last time I checked, Thunderbird doesn’t put design thought toward this use case. As such it is clunky to use for sending emails from different addresses.
I’m on Evolution now, but always looking for better options.
I primarily use mutt, which I have configured with 4 different email accounts: 1 work, 1 gmail, 2 migadu. So I don’t actually send from different addresses exactly (although I think that is easy to do in mutt), but have commands which switch me completely to a different account and inbox.
But what I meant about migadu is not that they give you multiple email addresses to send to and from within your domain, but that they let you add as many accounts as you like within that domain. So my daughters get their own email addresses and passwords and can sign into them on whatever mail client they like. And I can give these out to as many of my family as I like (the domain is a play on our surname), as long as I don’t hit the 200/20 limit.
Thanks for posting your setup. I’ve been sniffing at things adjacent to this for a while, looking at some other providers for SMTP. mailroute was the one that had looked most promising, but their definition of a “user” would have had me paying heavily for all the aliases I use, so I had not made the jump yet. Tuffmail’s EOL is going to force my hand.
Right now, I’m deciding between Migadu and a setup similar to what you’ve done. I had almost given up on the self hosted setup. Sendgrid could work for me, though. My only heartburn about it is, if they decide to kill off their free plan, it’s a huge jump up to $15/mo while I work out an alternative. Where I’d be flirting with the 200 in/day limit on Migadu, the jump up to the next tier isn’t as nasty if I need to do that.
My email server is similar in a lot of ways (OpenBSD, OpenSMTPD, Vultr) but also different.
The biggest difference is how the emails actually make their way to my LAN. I wanted to avoid a 5‐minute cronjob because I want some mails, like login codes, to show up as soon as they come in. Instead of using rsync, my Vultr server’s smtpd is configured as a relay. Incoming mail is sent over a WireGuard tunnel to a small always‐on machine on my LAN. Helpfully, if the LAN server is down, the relay will queue the mail and automatically retry once the connection is restored. The LAN server’s smtpd delivers incoming mail to a maildir, and Dovecot serves IMAP to my LAN with the maildir as the backing store.
I also have httpd serving a MTA-STS policy for my domain. Several big providers (Google, Microsoft, and Comcast at least) will use it to send email to me via TLS rather than negotiating STARTTLS (which can be MITM’d).
It shouldn’t be able to be MITM’d unless you’re using an implementation with a nasty bug. If you require STARTTLS and validate the certificate correctly, it provides exactly the same MITM protection as a TLS MTA. An MITM on STARTTLS would either not validate or not be able to see the traffic it is MITM-ing.
MTA-STS is new to me, though, and it looks like I should enable it. Thanks for pointing it out.
If you require STARTTLS and validate the certificate correctly
You can’t require STARTTLS. It’s designed to fall back to plaintext if the destination server doesn’t support encryption. Thus it can be exploited by attackers—and has been, rather famously by the Thai government, and also by Cricket.
It’s analogous to a plaintext HTTP URL that immediately 30x redirects to HTTPS: better than nothing, but still vulnerable, because an active attacker can simply strip the redirect to keep the entire session in plaintext.
If the sender simply refused to send mail without a successful STARTTLS negotiation, you’d be right that it would provide as much protection as a full TLS session. But STARTTLS has an insecure fallback baked in. MTA-STS was designed to solve that problem by providing a means for receiving servers to advertise a desire for TLS‐only mail.
You damn sure can, on a client. I have personally written a client that refuses to proceed if STARTTLS doesn’t work, and it wasn’t anything exotic.
It’s designed to fall back to plaintext if the destination server doesn’t support encryption.
This isn’t accurate at all. While I’d dispute that STARTTLS was “designed” to begin with, it certainly isn’t meant to fall back to cleartext. STARTTLS is a means of upgrading an insecure channel to a secure one. Failing to proceed if that upgrade doesn’t work is the only sensible behavior, IMO; otherwise why would you write your client to issue the STARTTLS command in the first place?
If the sender simply refused to send mail without a successful STARTTLS negotiation, you’d be right that it would provide as much protection as a full TLS session.
This is literally the only reasonable way to write a client that uses STARTTLS. If a client isn’t going to do that, why bother with STARTTLS at all? TLS isn’t something that’s just supposed to work if everyone is being nice. It’s a means of secure communication over an insecure, hostile network. Giving up and falling back to insecure communication in response to an error defeats the purpose of TLS. If the developer of an endpoint is going to do that, they may as well save themselves the time and labor and leave TLS support out altogether.
Sure, from the server’s perspective, requiring STARTTLS would be weird. But on a client, requiring it is the only sane thing to do if the client’s operator indicates that STARTTLS should be used. Anyone who writes a client that issues the STARTTLS command and doesn’t require it to succeed opens their users to the rather famous exploits you yourself point out.
The context here isn’t sanely written clients. The context is a public‐facing MX that has no control over whether incoming mailservers continue to send mail upon failure to negotiate STARTTLS and cannot reject plaintext mail.
While I’d dispute that STARTTLS was “designed” to begin with, it certainly isn’t meant to fall back to cleartext.
I refer you to RFC 3207:
A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally. This rule
prevents the STARTTLS extension from damaging the interoperability of
the Internet's SMTP infrastructure. A publicly-referenced SMTP
server is an SMTP server which runs on port 25 of an Internet host
listed in the MX record (or A record if an MX record is not present)
for the domain name on the right hand side of an Internet mail
address.
TLS isn’t something that’s just supposed to work if everyone is being nice. It’s a means of secure communication over an insecure, hostile network. Giving up and falling back to insecure communication in response to an error defeats the purpose of TLS.
I agree entirely, which is precisely why I suggest using MTA-STS, because STARTTLS behaves insecurely on a hostile network, exactly the way you decry.
The context here isn’t sanely written clients. The context is a public‐facing MX that has no control over whether incoming mailservers fall back to plaintext or not.
Then we’re having a stupid discussion, and I apologize for that. In the case of either STARTTLS or a plain TLS server on a public-facing MX, we’re still only talking about “server authenticated” TLS. That means that the server presents a certificate for the client to validate, but not vice versa. A server would never be able to detect an MITM in either scenario. They are equivalent in that regard.
Without a context of sanely written clients, server-auth TLS is useless. You need mutual auth to harden against badly behaved clients in this regard.
Your edit pointed out a MUST NOT in the RFC that I absolutely hadn’t been thinking about. So thanks, even if I replied too fast to catch it the first time. I’ve spilled a lot of words to mostly agree with you, I think.
After a pass over RFC 8461, though, I still don’t think there’s a meaningful difference even for a public facing MX unless you can turn off cleartext SMTP completely.
Section 4 explicitly calls out that STARTTLS is supported:
4. Policy Validation
When sending to an MX at a domain for which the sender has a valid
and non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS MUST
check whether:
1. At least one of the policy's "mx" patterns matches the selected
MX host, as described in Section 4.1, "MX Host Validation".
2. The recipient mail server supports STARTTLS and offers a PKIX-
based TLS certificate, during TLS handshake, which is valid for
that host, as described in Section 4.2, "Recipient MTA
Certificate Validation".
If you can’t turn the non-TLS MTA off, I don’t see the difference.
I do still think the STS record is a win. But I can’t see a meaningful difference between an MTA that requires TLS from the handshake versus STARTTLS.
In the context of SMTP server‐to‐server transactions, if STARTTLS negotation fails, the mail sender is likely to continue in plaintext rather than drop the mail. If STARTTLS succeeds but the TLS certificate is invalid, the mail sender is likely to continue with the invalid certificate rather than drop the mail. Not all senders continue in these cases, but many do, because STARTTLS‐capable servers with valid certificates have historically been far from universal (and still aren’t, probably, even after Let’s Encrypt). Naturally, this situation is ripe for MITM.
Turning off cleartext SMTP on your MX doesn’t help. Senders will still default to port 25, which an attacker can spoof a cleartext server on without you in the loop at all.
MTA-STS policies provide a way for an MX to require secure transport. In “enforce” mode, STARTTLS is mandatory, and certificates must be valid. Senders can’t continue without STARTTLS, and they can’t accept an invalid certificate; such mail must be rejected. So MTA-STS prevents MITM in a way that was not possible before.
This helps only when the sender checks for MTA-STS. Even so, you’re no worse off than before, and slightly better, because many of the big providers like Google and Microsoft do check. If you’ve configured your policy properly, incoming mail can’t be MITM’d between you and any MTA-STS–compliant sender.
I guess there’s the rub. If the MTA-STS spec lets servers consider STARTTLS as mandatory, though, I’m still not seeing how STARTTLS is more vulnerable to MITM than TLS at the handshake.
After all this, I see a few options for a server operator:
Cleartext SMTP listener with STARTTLS. Can be MITMd if it doesn’t require STARTLS, and might be MITM-able even if it does due to poor “client” (by this I mean othethatr servers, principally) implementations.
Cleartext SMTP listener with no STARTTLS. Obviously MITM-able.
TLS at the handshake. MITM could just block the port and cause “clients” to fall back to 25 anyway. Also, it’s unlikely that those clients who don’t validate certs for STARTTLS suddenly start doing so at the handshake.
Turn off port 25. Still MITM-able because non MTA-STS “clients” will try it first and proceed with no STARTTLS anyway.
MTA-STS is obviously a win insofar as it induces a few big implementations to be better clients. I wasn’t doubting that, though. I’m not seeing where sending via TLS at the handshake buys anything over STARTTLS. Am I missing a spot where it does?
That’s a pretty good way to set things up, definitely better than my hacky cron job. I didn’t have experience with wireguard, and it’s usually not a big deal for me to wait 5 minutes. If I’m expecting an email and don’t want to wait, I run the cron job manually. But maybe I’ll look into using wireguard.
Serving MTA-STS also sounds interesting, I may look into doing that as well.
Since there was a bit of a pricing discussion at the end of the article, there is even a cheaper alternative if you want to try self-hosting.
I have my complete email infrastructure running on IONOS VPS (https://www.ionos.com/servers/vps#packages). Setup is similar to the one in the article (OpenBSD, OpenSMTPD/Postfix, …) and it’s all running on 1EUR/$2 p.m. VPS in different data centers.
I haven’t used vultr, however, IONOS uses VMWare ESXI as hypervisor. Compared to the previous cloud/VPS providers I used (they use mostly KVM), the VMs are blazing fast. Disk I/O for even the cheap 1EUR VPS is wroooom…
Google: Only allows 30 email aliases per user, so Google was out.
Don’t Google (and microsoft) support plus addressing? For the purpose [the article author] are using aliases (unique addresses per service) plus addressing would fit the bill and there’s no limit on how many you can invent. I use plus addressing despite self hosting my own mail.
That works until you run into a service which tells you that no, “+” is not a valid character in email. Or they just strip it before sending their mail. It’s uncommon, but not that uncommon.
Yeah I know. In my particular case I use another delimiter (but I self host). If I couldn’t, it’s uncommon enough that’d I’d either expend one of a limited number of aliases (when using a paid service) or not bother giving that service a unique address.
It’s a shame Zoho was discounted quickly. I’m paying them for the email only and love the service. I’ve got multiple domains on it and use catch-all addresses, so I don’t have to do any extra work for the per-service aliases.
I probably should have spent more time researching Zoho. I just went to their website and was overwhelmed with all of the options.
I’ve considered using a catch-all, as it saves work setting up aliases. However, I prefer to only allow a specific addresses, so that if someone has to know a valid email address for me to accept the email.
I’m on my third year of Zoho for one of my domains, and I can’t say I love it. I’ve had some small, occasional mail delivery issues both receiving and sending, and the response from their support desk has been underwhelming. It hasn’t been enough of a problem for me to move that domain to another service, but it’s been annoying enough that I’m not moving any more of my mail to Zoho either, even now that tuffmail is going to force me to move a big chunk of it somewhere.
I’ve been running my own email server ever since I was on dialup (yes!), more than 20 years now. I do not agree. Smtp is actually a resilient protocol which doesn’t require 100% uptime, just sensible configuration which is not that hard to check and very low maintenance once setup. There are many excellent smtp servers nowadays which do this almost automatically.
But I’ve seen this statement repeated over and over and over.
The main issue with smtp for me has been the complete arrogance of the biggest players in the field like gmail, hotmail, etc. The dwindling number of independent smtp servers has been shrinking, making them even more powerful every year. Yet, they are the number #1 source of spam for my host currently (open proxies and relays are incredibly rare for me nowdays). Spam from their network gets a green pass and checks all the boxes: however they provide only black-hole-style spam reporting on their end while blocking almost everyone else with automated checks with zero intervention.
I hate to see that email is being centralized further and further. It’s actually decreasing the quality of the service for everybody else.
@ $WORK, we max at about 5k emails a day. Our daily average is about 1,500 emails a day, giving us about 100k/emails a month. We aren’t huge by any means, but we would spend ~ $100/month with any professional email sending service(sendgrid, mailgun, etc). We instead do our own email. We send things like purchase orders, payroll info, timesheets and other backoffice/accounting stuff via email, we are not spam by any means. We have a special domain just for this stuff, outside of the organizational domain, we own address space direct from ARIN, etc.
The big players when getting annoyed at you usually at least send along a URL saying oh hey, we are mad at you, go here for details. It’s usually a few clicks and a little babysitting and life is good again, until they get annoyed again a month or 6 down the line.
It’s all the small players that are annoying, you get nothing just a SMTP 550, their postmaster@ isn’t working or is ignored, so you are stuck trying to track down a human to fix their blasted email server.
That said, I 100% agree with you, if one of the big people get REALLY annoyed at you, there isn’t anything you can do. Most of our email is internal to our organization(s) we do payroll and what not for, so we have exceptions with their mail provider, to mostly bypass the insanity for them, which helps a lot.
IF you are going to run your own mail server, PLEASE turn on postmaster@ and have it go somewhere you actually READ. There are a bunch of other RFC’d email addresses you should also turn on (webmaster@, security@, etc)
Fun read, one small nit: the crontab entry running every 5 minutes should be more easily expressed as “*/5” instead of the explicit “0,5,10,15,20,25,30,35,40,45,50,55”.
FWIW, I’ve personally enjoyed email hosting by Migadu.
Same here. Switched after self-hosting mail for a couple years. Can absolutely recommend Migadu.
I’m the author of the post. I hadn’t heard of Migadu before, but it almost looks like it would work. The only issue is their Micro plan ($19/year) only allows 200 inbound emails per day. I guess that may not be an issue most of the time, but there are days where I receive more than 200 emails. The inability to control how much inbound email you are receiving makes me hesitant to use such a service.
I also use migadu for a family account. The thing I really like about it is that you can add as many accounts as you like for your domain: this@my.domain, that@my.domain, theother@my.domain, it’s so nice.
But yes, the 200-in limit has been my concern too. I subscribe to a few mailing lists and have a worry that one day some big heated mailing list conversation will put me over. This FAQ answer suggests they are lenient and that emails won’t actually be lost (assuming senders follow correct email practices!), but my tentative plan has been to wait and see if I ever get a warning email, and upgrade to the next tier if it becomes an issue. It hasn’t so far, after a year or so.
For what it’s worth, it’s not a hard limit. They won’t block the 201st email — if it’s a recurring thing, they’ll ask you to upgrade. This is mentioned in their docs, somewhere. cc @jeremyevans
I checked and it is in their documentation. So maybe that would have been a simpler option. I might have switched to Migadu instead of using a VM if I had known about it first. I think the only issue is the next level up from the $19/year plan is the $90/year plan, which is a pretty significant jump. But for someone who isn’t likely to go over their limits, Migadu looks like a really nice option.
It’s mentioned in the FAQ answer I linked to
Ah, didn’t notice you’d done that.
Re: using multiple addresses at the same domain:
Which email client(s) do you use? Last time I checked, Thunderbird doesn’t put design thought toward this use case. As such it is clunky to use for sending emails from different addresses.
I’m on Evolution now, but always looking for better options.
I primarily use mutt, which I have configured with 4 different email accounts: 1 work, 1 gmail, 2 migadu. So I don’t actually send from different addresses exactly (although I think that is easy to do in mutt), but have commands which switch me completely to a different account and inbox.
But what I meant about migadu is not that they give you multiple email addresses to send to and from within your domain, but that they let you add as many accounts as you like within that domain. So my daughters get their own email addresses and passwords and can sign into them on whatever mail client they like. And I can give these out to as many of my family as I like (the domain is a play on our surname), as long as I don’t hit the 200/20 limit.
Thanks for posting your setup. I’ve been sniffing at things adjacent to this for a while, looking at some other providers for SMTP. mailroute was the one that had looked most promising, but their definition of a “user” would have had me paying heavily for all the aliases I use, so I had not made the jump yet. Tuffmail’s EOL is going to force my hand.
Right now, I’m deciding between Migadu and a setup similar to what you’ve done. I had almost given up on the self hosted setup. Sendgrid could work for me, though. My only heartburn about it is, if they decide to kill off their free plan, it’s a huge jump up to $15/mo while I work out an alternative. Where I’d be flirting with the 200 in/day limit on Migadu, the jump up to the next tier isn’t as nasty if I need to do that.
Really sad to hear about Tuffmail. They were truly the best option.
Gilles Chehade, one of the authors of OpenSMTPD, wrote a big tutorial on setting up an OpenBSD email server, in case anyone else wants to try it.
My email server is similar in a lot of ways (OpenBSD, OpenSMTPD, Vultr) but also different.
The biggest difference is how the emails actually make their way to my LAN. I wanted to avoid a 5‐minute cronjob because I want some mails, like login codes, to show up as soon as they come in. Instead of using rsync, my Vultr server’s smtpd is configured as a relay. Incoming mail is sent over a WireGuard tunnel to a small always‐on machine on my LAN. Helpfully, if the LAN server is down, the relay will queue the mail and automatically retry once the connection is restored. The LAN server’s smtpd delivers incoming mail to a maildir, and Dovecot serves IMAP to my LAN with the maildir as the backing store.
I also have httpd serving a MTA-STS policy for my domain. Several big providers (Google, Microsoft, and Comcast at least) will use it to send email to me via TLS rather than negotiating STARTTLS (which can be MITM’d).
It shouldn’t be able to be MITM’d unless you’re using an implementation with a nasty bug. If you require STARTTLS and validate the certificate correctly, it provides exactly the same MITM protection as a TLS MTA. An MITM on STARTTLS would either not validate or not be able to see the traffic it is MITM-ing.
MTA-STS is new to me, though, and it looks like I should enable it. Thanks for pointing it out.
You can’t require STARTTLS. It’s designed to fall back to plaintext if the destination server doesn’t support encryption. Thus it can be exploited by attackers—and has been, rather famously by the Thai government, and also by Cricket.
It’s analogous to a plaintext HTTP URL that immediately 30x redirects to HTTPS: better than nothing, but still vulnerable, because an active attacker can simply strip the redirect to keep the entire session in plaintext.
If the sender simply refused to send mail without a successful STARTTLS negotiation, you’d be right that it would provide as much protection as a full TLS session. But STARTTLS has an insecure fallback baked in. MTA-STS was designed to solve that problem by providing a means for receiving servers to advertise a desire for TLS‐only mail.
You damn sure can, on a client. I have personally written a client that refuses to proceed if STARTTLS doesn’t work, and it wasn’t anything exotic.
This isn’t accurate at all. While I’d dispute that STARTTLS was “designed” to begin with, it certainly isn’t meant to fall back to cleartext. STARTTLS is a means of upgrading an insecure channel to a secure one. Failing to proceed if that upgrade doesn’t work is the only sensible behavior, IMO; otherwise why would you write your client to issue the STARTTLS command in the first place?
This is literally the only reasonable way to write a client that uses STARTTLS. If a client isn’t going to do that, why bother with STARTTLS at all? TLS isn’t something that’s just supposed to work if everyone is being nice. It’s a means of secure communication over an insecure, hostile network. Giving up and falling back to insecure communication in response to an error defeats the purpose of TLS. If the developer of an endpoint is going to do that, they may as well save themselves the time and labor and leave TLS support out altogether.
Sure, from the server’s perspective, requiring STARTTLS would be weird. But on a client, requiring it is the only sane thing to do if the client’s operator indicates that STARTTLS should be used. Anyone who writes a client that issues the STARTTLS command and doesn’t require it to succeed opens their users to the rather famous exploits you yourself point out.
The context here isn’t sanely written clients. The context is a public‐facing MX that has no control over whether incoming mailservers continue to send mail upon failure to negotiate STARTTLS and cannot reject plaintext mail.
I refer you to RFC 3207:
I agree entirely, which is precisely why I suggest using MTA-STS, because STARTTLS behaves insecurely on a hostile network, exactly the way you decry.
Then we’re having a stupid discussion, and I apologize for that. In the case of either STARTTLS or a plain TLS server on a public-facing MX, we’re still only talking about “server authenticated” TLS. That means that the server presents a certificate for the client to validate, but not vice versa. A server would never be able to detect an MITM in either scenario. They are equivalent in that regard.
Without a context of sanely written clients, server-auth TLS is useless. You need mutual auth to harden against badly behaved clients in this regard.
Sorry for editing my comment. I didn’t notice you’d replied already.
Your edit pointed out a
MUST NOTin the RFC that I absolutely hadn’t been thinking about. So thanks, even if I replied too fast to catch it the first time. I’ve spilled a lot of words to mostly agree with you, I think.After a pass over RFC 8461, though, I still don’t think there’s a meaningful difference even for a public facing MX unless you can turn off cleartext SMTP completely.
Section 4 explicitly calls out that STARTTLS is supported:
If you can’t turn the non-TLS MTA off, I don’t see the difference.
I do still think the STS record is a win. But I can’t see a meaningful difference between an MTA that requires TLS from the handshake versus STARTTLS.
In the context of SMTP server‐to‐server transactions, if STARTTLS negotation fails, the mail sender is likely to continue in plaintext rather than drop the mail. If STARTTLS succeeds but the TLS certificate is invalid, the mail sender is likely to continue with the invalid certificate rather than drop the mail. Not all senders continue in these cases, but many do, because STARTTLS‐capable servers with valid certificates have historically been far from universal (and still aren’t, probably, even after Let’s Encrypt). Naturally, this situation is ripe for MITM.
Turning off cleartext SMTP on your MX doesn’t help. Senders will still default to port 25, which an attacker can spoof a cleartext server on without you in the loop at all.
MTA-STS policies provide a way for an MX to require secure transport. In “enforce” mode, STARTTLS is mandatory, and certificates must be valid. Senders can’t continue without STARTTLS, and they can’t accept an invalid certificate; such mail must be rejected. So MTA-STS prevents MITM in a way that was not possible before.
This helps only when the sender checks for MTA-STS. Even so, you’re no worse off than before, and slightly better, because many of the big providers like Google and Microsoft do check. If you’ve configured your policy properly, incoming mail can’t be MITM’d between you and any MTA-STS–compliant sender.
I guess there’s the rub. If the MTA-STS spec lets servers consider STARTTLS as mandatory, though, I’m still not seeing how STARTTLS is more vulnerable to MITM than TLS at the handshake.
After all this, I see a few options for a server operator:
Cleartext SMTP listener with STARTTLS. Can be MITMd if it doesn’t require STARTLS, and might be MITM-able even if it does due to poor “client” (by this I mean othethatr servers, principally) implementations.
Cleartext SMTP listener with no STARTTLS. Obviously MITM-able.
TLS at the handshake. MITM could just block the port and cause “clients” to fall back to 25 anyway. Also, it’s unlikely that those clients who don’t validate certs for STARTTLS suddenly start doing so at the handshake.
Turn off port 25. Still MITM-able because non MTA-STS “clients” will try it first and proceed with no STARTTLS anyway.
MTA-STS is obviously a win insofar as it induces a few big implementations to be better clients. I wasn’t doubting that, though. I’m not seeing where sending via TLS at the handshake buys anything over STARTTLS. Am I missing a spot where it does?
That’s a pretty good way to set things up, definitely better than my hacky cron job. I didn’t have experience with wireguard, and it’s usually not a big deal for me to wait 5 minutes. If I’m expecting an email and don’t want to wait, I run the cron job manually. But maybe I’ll look into using wireguard.
Serving MTA-STS also sounds interesting, I may look into doing that as well.
Thanks for the ideas!
I loved the idea of giving an individual email alias per service and also the running your own mail server is an issue mostly for sending emails!
I’m having brain thoughts now! 🤔
Really enjoyed this write up. What did you use for spam filtering?
The other provider I had come across is https://posteo.de/en thought I share in case useful to anyone. Have not used myself yet.
Since there was a bit of a pricing discussion at the end of the article, there is even a cheaper alternative if you want to try self-hosting.
I have my complete email infrastructure running on IONOS VPS (https://www.ionos.com/servers/vps#packages). Setup is similar to the one in the article (OpenBSD, OpenSMTPD/Postfix, …) and it’s all running on 1EUR/$2 p.m. VPS in different data centers.
I haven’t used vultr, however, IONOS uses VMWare ESXI as hypervisor. Compared to the previous cloud/VPS providers I used (they use mostly KVM), the VMs are blazing fast. Disk I/O for even the cheap 1EUR VPS is wroooom…
I guess one could do the same setup with Runbox for outgoing SMTP as they support sending from any address that belongs to your domain.
I’ve sent an email to them and will update with a more authoritative answer.
Don’t Google (and microsoft) support plus addressing? For the purpose [the article author] are using aliases (unique addresses per service) plus addressing would fit the bill and there’s no limit on how many you can invent. I use plus addressing despite self hosting my own mail.
That works until you run into a service which tells you that no, “+” is not a valid character in email. Or they just strip it before sending their mail. It’s uncommon, but not that uncommon.
Yeah I know. In my particular case I use another delimiter (but I self host). If I couldn’t, it’s uncommon enough that’d I’d either expend one of a limited number of aliases (when using a paid service) or not bother giving that service a unique address.
Google also supports a catchall address which sounds like what he needs here.
It’s a shame Zoho was discounted quickly. I’m paying them for the email only and love the service. I’ve got multiple domains on it and use catch-all addresses, so I don’t have to do any extra work for the per-service aliases.
I probably should have spent more time researching Zoho. I just went to their website and was overwhelmed with all of the options.
I’ve considered using a catch-all, as it saves work setting up aliases. However, I prefer to only allow a specific addresses, so that if someone has to know a valid email address for me to accept the email.
I’m on my third year of Zoho for one of my domains, and I can’t say I love it. I’ve had some small, occasional mail delivery issues both receiving and sending, and the response from their support desk has been underwhelming. It hasn’t been enough of a problem for me to move that domain to another service, but it’s been annoying enough that I’m not moving any more of my mail to Zoho either, even now that tuffmail is going to force me to move a big chunk of it somewhere.