Add TLSRPT and MTA-STS explanations

1 files changed, 117 insertions, 14 deletions

diff --git a/content/blog/2020/email-server-extras.md b/content/blog/2020/email-server-extras.md
index 5d09466..47d826e 100644
--- a/content/blog/2020/email-server-extras.md
+++ b/content/blog/2020/email-server-extras.md
@@ -106,28 +106,107 @@ domain {
 }
 ```
 
+### Advanced security
 
+SPF, DKIM and DMARC are email's traditional DNS-based security systems,
+but in 2018 the IETF released [RFC 8460](https://tools.ietf.org/html/rfc8460) and [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.txt),
+which respectively define TLSRPT and MTA-STS,
+two fancy new systems focused on TLS-encrypted email transport.
 
+These security mechanisms are pretty new,
+so you won't get a huge benefit from enabling them,
+but big email providers' draconian spam filters might like it.
 
-## Dovecot
 
-### Catchall inbox
+#### TLSRPT
 
-In Dovecot, you can create a catch-all inbox that will accept all
-emails sent to your domain that don't match anyone in `/etc/dovecot/users`.
-Just add another `userdb` block *after* the first:
+TLS reporting, or TLSRPT for short, is very simple:
+all it does is provide a contact email address in case
+somebody has trouble with the TLS configuration of your SMTP server.
+
+To enable it for your custom email domain `example.com`,
+simply create a DNS TXT record for the `_smtp._tls` subdomain:
 ```sh
-userdb {
-	driver = static
-	args = uid=vmail gid=vmail home=/var/vmail/catchall allow_all_users=yes
-}
+_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:<contact>"
 ```
-The `static` driver means there is no table file:
-all configuration is directly within this `userdb` block.
-If we don't specify `allow_all_users=yes`, then Dovecot
-will check whether users exist using the `passdb` table,
-and will conclude that the recipient is invalid.
+Where `<contact>` is an email address of your choosing.
+That's all!
+
+
+#### MTA-STS
+
+MTA Strict Transport Security (MTA-STS) tells other servers
+that you take TLS encryption of messages very seriously,
+so they should avoid sending you unencrypted email,
+and should only accept certain certificates from your side.
+
+Compared to the previously discussed DNS-based security extensions,
+MTA-STS is a bit more work to set up,
+because you'll also need an HTTP web server.
 
+The DNS part is still pretty simple:
+create yet another DNS TXT record,
+this time for the subdomain `_mta-sts`:
+```sh
+_mta-sts.example.com. TXT "v=STSv1; id=<id>"
+```
+The `<id>` should identify the version of your policy,
+so other servers can quickly see if something changed.
+I recommend using today's date.
+
+For the next part, I'll assume that you already have
+a web server running on a server with the IP address `1.2.3.4`.
+I use [nginx](https://nginx.org/) for this, running
+on the same server as OpenSMTPD and Dovecot,
+but you don't have to do the same.
+
+Create an A record which binds your server
+to the subdomain `mta-sts` (without underscore):
+```sh
+mta-sts.example.com. A 1.2.3.4
+```
+Set your web server to serve the file
+`https://mta-sts.example.com/.well-known/mta-sts.txt`
+(we'll discuss that file in a moment).
+Note that this policy file **must** be served over HTTPS,
+so you need a valid TLS certificate for that domain.
+
+The contents of the `mta-sts.txt` policy file are as follows,
+where `mx1.example.com` and `mx2.example.com` are the hosts
+mentioned in `example.com`'s DNS MX records:
+```sh
+version: STSv1
+mode: enforce
+mx: mx1.example.com
+mx: mx2.example.com
+max_age: <age>
+```
+All MX servers must be mentioned this way.
+If you're feeling cautious, you may want to set
+`mode` to `testing` in the beginning.
+This policy is valid for `<age>` seconds,
+which is recommended to be several weeks,
+but to start with, I suggest using 86400 seconds (one day).
+Finally, ensure that this file has CRLF Windows-style line endings.
+
+To correctly pass an MTA-STS test, the TLS certificate
+presented by e.g. `mx1.example.com` should be valid for `mx1.exaple.com`.
+To achieve this without needing to manage too many certificates,
+you can specify multiple domains when requesting a certificate,
+or you can use a wildcard domain (`*.example.com`).
+Note, however, that MTA-STS testing tools don't like
+the latter option, so I recommend the former.
+
+Once you're done, check your work by using either
+[ESMTP](https://esmtp.email/tools/mta-sts/)'s or [Ayke](https://aykevl.nl/apps/mta-sts/)'s
+online MTA-STS validation tools,
+ignoring any warnings about DNSSEC or DANE.
+If all is good, great!
+
+Even if you did everything correctly,
+these tools will warn you that you're not using DNSSEC/DANE.
+It might then be tempting to set that up for even more security,
+but I recommend against that for private servers: take a look at [this](https://dane.sys4.de/common_mistakes).
 
 
 
@@ -306,3 +385,27 @@ This tells Rspamd to add DKIM signatures to incoming emails,
 which in this case includes yours.
 Allowing these mismatches ensures that the messages still get signed,
 even if you're sending from an arbitrary address.
+
+
+
+## Dovecot
+
+### Catchall inbox
+
+In Dovecot, you can create a catch-all inbox that will accept all
+emails sent to your domain that don't match anyone in `/etc/dovecot/users`.
+Just add another `userdb` block *after* the first:
+```sh
+userdb {
+	driver = static
+	args = uid=vmail gid=vmail home=/var/vmail/catchall allow_all_users=yes
+}
+```
+The `static` driver means there is no table file:
+all configuration is directly within this `userdb` block.
+If we don't specify `allow_all_users=yes`, then Dovecot
+will check whether users exist using the `passdb` table,
+and will conclude that the recipient is invalid.
+
+
+