summaryrefslogtreecommitdiff
path: root/content/blog/2020
diff options
context:
space:
mode:
authorPrefetch2022-07-17 09:06:31 +0200
committerPrefetch2022-07-17 09:06:31 +0200
commitd6f086e33d143ec6e84b0058e7d8832c166f4427 (patch)
treebefdd527a76b3ee3f9c2ec5b084b91dcf173b89e /content/blog/2020
parent2677f9bd104515b598fa49d1ae78fa112d879e8d (diff)
Minor fixes
Diffstat (limited to 'content/blog/2020')
-rw-r--r--content/blog/2020/email-server.md18
1 files changed, 9 insertions, 9 deletions
diff --git a/content/blog/2020/email-server.md b/content/blog/2020/email-server.md
index 3b7f439..a683fc7 100644
--- a/content/blog/2020/email-server.md
+++ b/content/blog/2020/email-server.md
@@ -27,7 +27,7 @@ When you're done, take a look at the
[sequel](/blog/2020/email-server-extras/)
for ideas to extend your setup.
-Last content update on 2020-04-29. Last correction on 2021-02-20.
+Last content update on 2020-04-29. Last correction on 2022-07-10.
@@ -215,7 +215,7 @@ using the [MX Lookup](https://mxtoolbox.com/MXLookup.aspx) online tool.
To inform the rest of the Internet that your server is an email server,
create an MX (Mail eXchanger) DNS record for your domain.
Note the dot at the end of the domain name:
-```
+```sh
example.com. MX 42 example.com.
```
When a message is sent to an email address ending in `@example.com`,
@@ -231,7 +231,7 @@ The sender will try MX records with *lower* numbers first,
and if that server is unavailable, it will try a higher number.
If you have multiple mail servers (which is a good idea),
you can thus declare those as follows:
-```
+```sh
example.com. MX 13 mx1.example.com.
example.com. MX 42 mx2.example.com.
```
@@ -256,7 +256,7 @@ SPF works by specifying which IP addresses are authorized
to send emails from your domain name.
You must publish this information in a
TXT-type DNS record (**not** SPF-type, which also exists!) with the following contents:
-```
+```sh
example.com. TXT "v=spf1 mx -all"
```
Everything after the version `v=spf1` is a list of *verification mechanisms*
@@ -305,7 +305,7 @@ for a while so old emails can still be verified.
Your DKIM policy must be published in a TXT record
as follows, where `<pubkey>` is the public RSA key `MI...AB`
stored in `/path/to/dkim/public.key`, with the newlines removed:
-```
+```sh
<selector>._domainkey.example.com. TXT "v=DKIM1; t=s; h=sha256; p=<pubkey>"
```
Here, `v=DKIM1` is the version and must be the first tag.
@@ -329,7 +329,7 @@ similarly to DKIM, **must** belong to the subdomain `_dmarc.example.com`,
and give it the following contents,
where `<admin>` is an email address of your choosing,
which may or may not belong to your domain:
-```
+```sh
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; pct=100; aspf=s; adkim=s; fo=1; ruf=mailto:<admin>"
```
The version tag `v=DMARC1` must come first,
@@ -424,7 +424,7 @@ You can therefore optionally remove one of the two
Next, we need to inform Dovecot which email addresses it should handle,
and what to do with their messages. Create a file `/etc/dovecot/users` for this,
which describes a user on each line in a similar format as `/etc/passwd`:
-```
+```sh
user:password:uid:gid::homedir
```
In this guide, we're using the `vmail` user for all accounts,
@@ -516,12 +516,12 @@ To begin, delete the contents of the `/etc/smtpd/aliases` file,
if it exists, which maps recipient addresses to system users.
In our case, we're using `vmail` for everyone,
and we'll let Dovecot manage the details by simply writing:
-```
+```sh
@ vmail
```
Then create a new file `/etc/smtpd/passwds`
and fill it in according to the following format:
-```
+```sh
name@example.com <hash>
```
Generate the password hash with this command for each user.