From 6987dcbd64f3d4b3c3c43a8fd96a03a0ce5b56eb Mon Sep 17 00:00:00 2001 From: Prefetch Date: Mon, 12 Sep 2022 21:46:01 +0200 Subject: Post "Revisiting my email server in 2022" --- config.toml | 5 + content/blog/2020/email-server-extras.md | 29 +- content/blog/2020/email-server.md | 65 +++-- content/blog/2022/email-server-revisited/index.md | 304 +++++++++++++++++++++ .../email-server-revisited/microsoft-bounce.png | Bin 0 -> 24184 bytes .../know/concept/calculus-of-variations/index.pdc | 6 +- content/know/concept/pulay-mixing/index.pdc | 2 +- .../concept/rayleigh-plesset-equation/index.pdc | 2 +- 8 files changed, 378 insertions(+), 35 deletions(-) create mode 100644 content/blog/2022/email-server-revisited/index.md create mode 100644 content/blog/2022/email-server-revisited/microsoft-bounce.png diff --git a/config.toml b/config.toml index 3463bda..9596e57 100644 --- a/config.toml +++ b/config.toml @@ -6,3 +6,8 @@ disableKinds = ["taxonomy", "term"] [security.exec] allow = ['^dart-sass-embedded$', '^go$', '^npx$', '^postcss$', '^pandoc$'] + +[markup] + [markup.goldmark] + [markup.goldmark.renderer] + unsafe = true 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 `` could be anything you want, +not necessarily the same account name as in Dovecot: ```sh -name@example.com + ``` 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 '' ``` @@ -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 diff --git a/content/blog/2022/email-server-revisited/index.md b/content/blog/2022/email-server-revisited/index.md new file mode 100644 index 0000000..3f45993 --- /dev/null +++ b/content/blog/2022/email-server-revisited/index.md @@ -0,0 +1,304 @@ +--- +title: "Revisiting my email server in 2022" +firstLetter: "R" +date: 2022-07-25T10:56:53+02:00 +draft: false +--- + +# + +More than two years have passed since my first post about +[setting up an email server in 2020 with OpenSMTPD and Dovecot](/blog/2020/email-server/) +and [its sequel](/blog/2020/email-server-extras/). +Since then, my server been going strong, with a few minor hiccups along the way. +In this post, I'll explain some of the changes I made. + +This assumes you've followed the preceding guides: +the configuration snippets given here +should be interpreted as modifications to those guides, +*not* as complete setups! + +Last updated on 2022-09-12. + + + +## More about DMARC + +When I wrote my original guide, +I didn't properly understand how DMARC works: +I misinterpreted it as an optional wrapper around SPF and DKIM. +But oh God, I was wrong. +Simon Andrews' article "[I figured out how DMARC works, and it almost broke me](https://simonandrews.ca/articles/how-to-set-up-spf-dkim-dmarc)" +showed me the ugly truth, +and I highly recommend reading it. +Briefly, DMARC does two arguably unrelated things. + +Firstly, DMARC provides a way to diagnose issues with your SPF and DKIM configurations, +in the form of reports that get sent to the `ruf=` and/or `rua=` email address(es) +you put in the DNS record. +Without this, there's no way of knowing why +your emails are getting marked as spam. + +Secondly, it improves the trustworthiness of SPF and DKIM by enforcing *alignment*. +This means something slightly different for SPF and DKIM, +and boils down to fixing a glaring issue: + +* For some reason, in vanilla SMTP, it turns out that the email's `From:` header + doesn't need to agree with the address in the SMTP `MAIL FROM` command; + in other words, the server can claim a different sender that what's written in the message's header. + SPF only verifies the former (i.e. it takes the domain in `MAIL FROM`), + so one SMTP server can impersonate another. +* An email's DKIM signature header states the domain of the signing server with the `d=` tag, + but, once again, that doesn't need to agree with the `From:` header's domain. + DKIM doesn't look at the latter, so an SMTP server can validly sign impersonated messages. + +DMARC's alignment refers to checking whether the domains match up for SPF and DKIM, +thus ensuring that an SMTP server can't pretend to be someone else. +It sounds obvious, but nope, apparently it wasn't before DMARC was made. + + + +## DKIMproxy + +To add DKIM signatures to my messages, +I switched from Rspamd to [DKIMproxy](http://dkimproxy.sourceforge.net/). + + + +### Motivation + +To sign outgoing emails for DKIM, my original guide used Rspamd --- +an unusual choice, since it's a spam filter designed to act on *incoming* messages. +Later, in the [sequel](/blog/2020/email-server-extras/) to that guide, +I needed some ugly workarounds to compensate for Rspamd's "smartness" +when I tried to play around with authentication schemes in OpenSMTPD. +Clearly, this wasn't ideal. + +However, the reason I cut my losses and switched to another DKIM signer +was actually a bug in +MXToolBox' [deliverability tool](https://mxtoolbox.com/deliverability). +It appears that no matter what you do, +this tool claims that your email's signature fails validation. +I'm not the first to notice this issue: +see e.g. [this question](https://serverfault.com/questions/1005818/dkim-validating-but-mxtoolbox-reports-as-dkim-signature-not-verified) on Server Fault. +Other tools like the [DKIM validator](https://dkimvalidator.com/) +say that my DKIM signatures are correct. + +There aren't many open-source alternatives out there for DKIM signing: +the only ones I know of are [OpenDKIM](http://www.opendkim.org/) +and DKIMproxy. +The former is a so-called "milter", +meaning it can only interact with MTAs via the milter API, +which is only supported by [Sendmail](https://www.proofpoint.com/us/products/email-protection/open-source-email-solution) +and [Postfix](https://www.postfix.org/). +Since we're using OpenSMTPD, +our only option is DKIMproxy, +which consists of two daemons: +`dkimproxy.out` to sign outgoing mail, +and `dkimproxy.in` to verify incoming mail. +We just need the former; +Rspamd is still convenient for handling the latter's functionality. + + + +### DKIM settings + +Let's start by disabling Rspamd's DKIM signer +in `/etc/rspamd/local.d/dkim_signing.conf`: +```sh +enabled = false; +``` +Then configure `dkimproxy.out` as follows +in `/etc/dkimproxy/dkimproxy_out.conf`. +If you placed your DKIM public key +in a TXT DNS record for `._domainkey.example.com.`, +and stored your private key in `/path/to/dkim/private.key`, +then: +```sh +# Receive emails on 10027, sign them, and forward them to 10028 +listen 127.0.0.1:10027 +relay 127.0.0.1:10028 + +# Settings for email signing +domain example.com +signature dkim(c=relaxed/relaxed,a=rsa-sha256) +keyfile /path/to/dkim/private.key +selector +``` +Here, `rsa-sha256` is the signature algorithm +(this is the best available, because DKIM is ancient), +and `relaxed/relaxed` is the so-called *canonicalization* method, +which is applied before signing and verification, +to prevents failures if e.g. the email's whitespace gets changed in transit. + + + +### OpenSMTPD settings + +OpenSMTPD needs to send all outbound mail through `dkimproxy.out`. +In `/etc/smtpd/smtpd.conf`, we tell it that all emails coming from the MUA +must be relayed through `localhost:10027`, and then, after DKIM signing, +picked up again on `localhost:10028`: +```sh +# Outbound +listen on eth0 port 465 smtps pki "example.com" auth tag "TRUSTED" +listen on eth0 port 587 tls-require pki "example.com" auth tag "TRUSTED" +action "SIGN" relay host "localhost:10027" +match from any tag "TRUSTED" for any action "SIGN" + +listen on lo port 10028 tag "SIGNED" +action "SEND" relay srs +match from any tag "SIGNED" for any action "SEND" +``` +The tag name `TRUSTED` reflects that only messages from trusted +(i.e. authenticated) MUAs should be signed. +After signing, emails get the tag `SIGNED`, +and are sent to their destination as usual. + + + +## SMTP relay + +Instead of sending my emails directly to their destinations, +I now send them to an SMTP relay server, +which then passes them on to their actual destinations. + + + +### Motivation + +Large email providers such as Google, Microsoft and Yahoo +manage many user accounts, so for them it makes sense +to keep track of IP-based sender reputations. +For example, if a number of low-quality emails are sent from a single IP +to many of the accounts they manage, +it's cheaper to simply blacklist that IP entirely at the MTA level, +rather than passing each message through a computationally-intensive spam filter. + +But, as usual, Microsoft has to ruin everything with their draconic policies. +In a stroke of genius, +someone there decided to blindly ban IPs, +seemingly in blocks belonging to VPS providers. +One day, I tried to send an email to an Outlook-based account, +and OpenSMTPD reported it had been unable to make the delivery, +because Microsoft had thrown an error: + + + + + +To their credit, they seem to be offering a way out. +This approach is reasonable: preventively ban high-risk IP ranges, +and allow "trustworthy" servers at the owner's request. +I got error 5.7.511, asking me to send an email to a support address. +If you're lucky, you may have a different error, +and get the opportunity to use the slick [delist portal](https://sender.office.com/) instead. +The URL in the bounce message links to [this list](https://go.microsoft.com/fwlink/?LinkId=526653) of error codes. + +I confess, I never actually bothered to forward the message to the provided address: +my initial email was time-sensitive, +so I couldn't afford to wait for Microsoft's response. +Also, their customer support's stellar reputation precedes them, +so I chose to use my time more wisely. +Even if they would've resolved it nicely, +there's nothing preventing Microsoft (or any other provider) +from breaking my deliverability again in the future. +Instead, I opted for a compromise. + +As a result of providers' IP reputation systems, +a whole new business has appeared: SMTP relays. +They offer to take the issue out of your hands: +you send your emails through their servers, +and they do their best to deliver them to large providers. +SMTP relays are mostly used for sending marketing emails in bulk, +but are also useful to avoid small-scale problems as described above. +There are many SMTP relay services to choose from, at various prices. + +Using an SMTP relay results in more reliable delivery of your messages to large providers, +but an obvious concern is privacy: +the relay server can read all your outgoing emails (but not incoming), +so you'll have to trust the service you choose. +But it's no worse than using a major provider, +and if you're sending sensitive material, why use email in the first place? +Personally, I use [SMTP2GO](https://www.smtp2go.com/), +but I can't say how good they are; do your own research. + + + +### OpenSMTPD settings + +Once you've chosen an SMTP relay service, let's say `relay.com`, +and set up your account, +they'll let you create credentials to use their SMTP servers. +Suppose these credentials are `` and ``, +create a file `/etc/smtpd/relaypw` with contents: + +```sh +