diff options
Diffstat (limited to 'content/blog/2020')
| -rw-r--r-- | content/blog/2020/email-server-extras.md | 29 | ||||
| -rw-r--r-- | content/blog/2020/email-server.md | 65 |
2 files changed, 63 insertions, 31 deletions
diff --git a/content/blog/2020/email-server-extras.md b/content/blog/2020/email-server-extras.md index 72299c9..5a72a84 100644 --- a/content/blog/2020/email-server-extras.md +++ b/content/blog/2020/email-server-extras.md @@ -7,11 +7,13 @@ draft: false # -This sequel to my earlier [guide](/blog/2020/email-server/) discusses -extra tips and tricks to extend your email setup. -This page will be updated continuously as I come up with ideas. +This sequel to my post +"[Setting up an email server in 2020 with OpenSMTPD and Dovecot](/blog/2020/email-server/)" +gives extra tips and tricks to extend your email setup. +See also the sequel's sequel, +"[Revisiting my email server in 2022](/blog/2022/email-server-revisited/)". -Last updated 2020-04-29. +Last updated on 2022-09-12. ## General @@ -220,6 +222,13 @@ but I recommend against that for private servers: take a look at [this](https:// You can configure OpenSMTPD to request a client certificate for sending emails, as a second factor for authentication. +UPDATE: When I wrote this two years ago, it worked, +but now it doesn't anymore, and I can't figure out why. +It seems OpenSMTPD always rejects the client certificates for being self-signed, +even if they can manually be verified for our CA using the `openssl` tool. +I'm leaving this tutorial here for anyone who's interested, +but it's unlikely I'll fix it anytime soon. + #### Certificates @@ -314,7 +323,17 @@ enter again when importing the certificate into the client. -### Client certificates (instead of passwords) +### ~~Client certificates (instead of passwords)~~ + +UPDATE: Don't do this. +As said above, OpenSMTPD's certificate verification is a mystery, +so for all I know, if you follow the instructions in this subsection, +you might find yourself running an *open* SMTP relay! +That would be bad, because anyone on the Internet +could send emails through your server with zero authentication. +In theory, the client certificates act as authentication, +but, again, the verification process is mysterious, +so I'm just not confident enough to say. If you really want to, you can use the client certificates as a substitute for passwords. This is especially useful diff --git a/content/blog/2020/email-server.md b/content/blog/2020/email-server.md index a683fc7..ba03fcf 100644 --- a/content/blog/2020/email-server.md +++ b/content/blog/2020/email-server.md @@ -23,11 +23,12 @@ but your mileage may vary considerably. I hope you find it useful. This guide is aimed at people who are comfortable with the Linux/*BSD command line. -When you're done, take a look at the -[sequel](/blog/2020/email-server-extras/) -for ideas to extend your setup. +When you're done (if you get that far), take a look at the sequels +"[Setting up an email server in 2020 with OpenSMTPD and Dovecot: extras](/blog/2020/email-server-extras/)" +and "[Revisiting my email server in 2022](/blog/2022/email-server-revisited/)" +for ideas on how to extend your setup. -Last content update on 2020-04-29. Last correction on 2022-07-10. +Last updated on 2022-09-12. @@ -39,6 +40,7 @@ because you need to configure not one, but *two* server programs, I'll start by explaining the general structure of a mail server setup. + ### How email works The programs involved in the exchange of emails are called [agents](https://en.wikipedia.org/wiki/Email_agent_(infrastructure)). @@ -335,14 +337,14 @@ _dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; pct=100; aspf=s; adkim=s The version tag `v=DMARC1` must come first, followed by `p=` and `sp=`, which control what to do to unverified messages coming from the main domain and subdomains, respectively. -Unsurprisingly, `reject` means that delivery should be refused, +Here, `reject` means that delivery should be refused, `none` asks to let it through anyway, and `quarantine` tells the filter to take a closer look or to put it in a spam folder. The percentage `pct=100` says how many of your emails to apply the policy to. -Next, `aspf=s` and `adkim=s` enable strict mode for both SPF and DKIM, -which blocks subdomains from passing the test. -Finally, `fo=1` asks the filter to create a forensic report -if any type of verification fails, and `ruf=` gives an address to send it to. +Next, `aspf=s` and `adkim=s` enable strict mode for SPF and DKIM, +which blocks subdomains from passing. +Finally, `fo=1` asks for a forensic report if verification fails, +and `ruf=` gives an address to send it to. If in doubt, see the [DMARC spec](https://tools.ietf.org/html/rfc7489). @@ -520,12 +522,15 @@ and we'll let Dovecot manage the details by simply writing: @ vmail ``` Then create a new file `/etc/smtpd/passwds` -and fill it in according to the following format: +and fill it in according to the following format, +where `<user>` could be anything you want, +not necessarily the same account name as in Dovecot: ```sh -name@example.com <hash> +<user> <hash> ``` Generate the password hash with this command for each user. -Be sure to use the same password for every account as in Dovecot: +Again, the password doesn't need to be the same as in Dovecot, +but for your own convenience it's probably best if it is: ```sh $ smtpctl encrypt '<password>' ``` @@ -550,8 +555,8 @@ example.com ``` Then continue in `/etc/smtpd/smtpd.conf` by importing your TLS certificate: ```sh -pki "prefet.ch" cert "/etc/ssl/certs/example.com.pem" -pki "prefet.ch" key "/etc/ssl/private/example.com.key" +pki "example.com" cert "/etc/ssl/certs/example.com.pem" +pki "example.com" key "/etc/ssl/private/example.com.key" ``` And tell OpenSMTPD which keys to use for the [Sender Rewriting Scheme](https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme), which prevents forwarded emails from breaking SPF and looking like spam: @@ -677,32 +682,40 @@ And... that's it! Of course, don't forget to start all the necessary daemons. Everything is set up now, so it's time to test. Fingers crossed! -As mentioned earlier, you can check the correctness +As mentioned earlier, you can check the validity of your DNS using the [MX Lookup](https://mxtoolbox.com/MXLookup.aspx) tool. You can use the same website to test OpenSMTPD with the [SMTP Diagnostics](https://mxtoolbox.com/diagnostic.aspx) tool. All decent email clients include an option to set the server for an email account. -This guide excludes instructions for that, +This guide doesn't include instructions for that, because it will vary a lot from client to client. If asked for your login type, choose plain/normal/unencrypted passwords. Don't worry, the client-server connection is TLS-encrypted, so nobody will be able to steal it. -Next, to test sending and receiving messages, -use the aptly-named [Is my email working?](http://ismyemailworking.com/) website. -After that, specifically test that SPF, DKIM an DMARC -are working correctly using the [DKIM validator](https://dkimvalidator.com/). +Next, to verify that you can send and receive messages, +and that your SPF/DKIM/DMARC is working, +the following websites will be useful: + +* [~~Is my email working?~~](http://ismyemailworking.com/) + UPDATE: no longer available. +* [DKIM validator](https://dkimvalidator.com/): + by sending an email, checks that SPF and DKIM are set up correctly. +* [Email deliverability tool](https://mxtoolbox.com/deliverability): + tests basically everything. + As of writing, there's a bug that causes DKIM signatures to fail verification + even if you did it right; just ignore that. +* [Learn and test DMARC](https://www.learndmarc.com/): + checks SPF, DKIM and DMARC in detail. + If everything is good so far, congratulations! Now comes the big scary final test: -sending an email to one of the "big guys", Google or Microsoft. +sending an email to one of the "big guys", like Google, Yahoo or Microsoft. Their spam filters are very strict, so if you get through, great! -Because these companies probably use AI-powered account-aware filters, -you should *not* put anything identifiable in the test email. -For example, if your name is "John Smith", -do *not* put "John" nor "Smith" in the message, -and do *not* send it from an addres like `john.smith@example.com`. +Try to write your test message so that it doesn't look like spam, +otherwise there's no point to this exercise. If something failed, then you have some investigating to do. Either one of the daemons is misconfigured, or there's a problem |