revsuine/revsuine.xyz
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

why run a mail server section

Browse source
This commit is contained in:
revsuine 2024-11-20 01:25:36 +00:00
parent d29600686c
commit 91303dc59a
Signed by: revsuine
GPG key ID: 3F257B68F5BC9339
1 changed files with 57 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

56
content/blog/mail_server_alpine_postfix_dovecot_tutorial.md
View file

@ -23,6 +23,35 @@ A mail server is software which can be run on any computer, including yours. You
already own that is hosting other services, so long as those other services aren't using any of the [mail already own that is hosting other services, so long as those other services aren't using any of the [mail
ports](#unblock-your-ports). ports](#unblock-your-ports).
## Why run my own mail server?
I'll cut to the chase: the main reason why you'd want to run your own mail server is for related reasons of privacy and
digital sovereignty. For privacy benefits, as much as you have control over your server, you can protect your email
from the eyes of prying server admins (given that you yourself are the admin). Even for email providers that market
themselves around privacy such as Protonmail, rely on trust that Proton are not reading your unencrypted incoming
email. This is not an issue exclusive to any particular mail provider; if information arrives unencrypted at a server,
those with access to the server (i.e. administrators) can read that information, simple as. And as nice as it would be
if everyone used GPG end-to-end encryption for email, the vast majority of emails people receive are not end-to-end
encrypted, and entirely legible to the mail servers involved. If you're not exchanging <abbr
title="End-to-End Encrypted">E2EE</abbr> email, you can't mitigate the fact that your exchange is entirely legible to
the mail server of the person you're corresponding with, but you can at least eliminate your anxieties about the mail
server you yourself are using.[^server_trust]
Running your own mail server also allows you to implement things your way, with the features you want. For instance,
[you can run a sieve filter for encrypting all incoming mail with a user's public GPG
key](https://www.grepular.com/Automatically_Encrypting_all_Incoming_Email); for obvious reasons, users of externally
managed mail servers that implement sieve do not allow users to create their own executables for sieve filters.
Hosting your own mail server is not something I would universally recommend to people. While I'm very much against
"nothing to hide, nothing to fear", a combination of that factor alongside a low state threat model (i.e. there is
little state interest in you, domestic or foreign), a lack of relevant knowledge, and a lack of interest in managing
your own server/learning how to, likely make self-hosting email not a reasonable privacy suggestion.
When you host your own mail server, you are responsible for securing the server. If you entrust Google with your email,
you can at least know that your email is secure, though not private; Google will hire people with the relevant
knowledge and skills to secure a mail server. If you are not confident in your ability to do this and not interested in
learning, you may want to find another solution.
# Why this tutorial? # Why this tutorial?
There are many tutorials on the internet about how to set up a mail server. I don't claim that mine is particularly There are many tutorials on the internet about how to set up a mail server. I don't claim that mine is particularly
@ -264,11 +293,38 @@ so ultimately `revsuine` will get `postmaster`'s mail.
You can continue to populate the aliases file with whatever aliases you want. You can continue to populate the aliases file with whatever aliases you want.
# Dovecot
[Dovecot](https://www.dovecot.org/) is a popular IMAP and POP3 server which we'll be using for our MDA.
<!-- FOOTNOTES: --> <!-- FOOTNOTES: -->
[^server_trust]: This is only true to the extent that your server is not compromised. You could say there's an order of
server trust-ability that goes:
```
VPS < rented dedicated server < server you yourself physically own, store, and manage
```
There is little that can be done to secure a VM running on a compromised host. Even with full-disk encryption, the
host can dump the encryption key from RAM, because the encryption key must be stored in memory whilst a
full-disk-encrypted system is booted.
For a dedicated server you rent, there are at least no concerns about a compromised host, but an attacker with
physical access (in this case, the untrusted people you rent the dedicated server from) can attempt evil maid
attacks. You are hopefully able to implement things to detect this, though.
There are reasons you may want to go with a rented server instead of one you own, though. For instance, if you live
in a jurisdiction known for terrible privacy laws such as a [5/14 eyes
country](https://restoreprivacy.com/5-eyes-9-eyes-14-eyes/), or if you are a political dissident with domestic
state interest in you, you likely want to go offshore for server hosting. Changing the jurisdiction can protect you
if the jurisdiction you choose won't work with your national intelligence agencies.
[^postfix_aliases_location]: Your aliases file will most likely be in this location by default, but you can run [^postfix_aliases_location]: Your aliases file will most likely be in this location by default, but you can run
```
$ postconf alias_maps $ postconf alias_maps
```
to find out where this file should be. to find out where this file should be.