content/blog/mail_server_alpine_postfix_dovecot_tutorial.md: add mentions of 'easier' solutions in intro and add tags

2024-11-20 21:24:28 +00:00

31 KiB

Raw Blame History

+++ date = '2024-11-19T16:29:01Z' draft = true title = 'How to Set up a Mail Server on Alpine Linux with Postfix and Dovecot' tags = ['mail server', 'alpine linux', 'postfix', 'dovecot'] +++

About mail servers

Simply put, a mail server sends and receives email. When ruby@protonmail.com emails klaasje@gmail.com, Protonmail's mail server's MTA sends the email to Google's mail server's MTA. Google's MTA then passes the email on to Google's MDA, which is responsible for storing the email. MDAs also run IMAP or POP3 servers so you can read your emails and send emails with an email client. IMAP and POP3 are protocols for email retrieval over TCP/IP. For sending email, you would use SMTP.

Or visualise it like this:

Ruby's email client via SMTP -> Protonmail's MTA -> Google's MTA -> Google's MDA -> Klaasje's email client via IMAP

A mail server is software which can be run on any computer, including yours. You can host a mail server on a server you already own that is hosting other services, so long as those other services aren't using any of the mail 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 E2EE 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.¹

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; for obvious reasons, public (as in, open to public sign-up) 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.

There are also existing solutions that aim to "simplify" the process of managing a mail server; there have always been plenty of services offering mail server hosting which is managed for you, the customer, and there are also projects like Mailcow, which is an attempt to make a user-friendly distributable mail server stack based on Docker. It has a web GUI you can use to configure your mail server. This may be an option for people who value digital sovereignty but don't want to get their hands dirty with config files. I only mention this as something you may want to look into; I have never used Mailcow and cannot recommend it personally.

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 better than anyone else's; I'm mostly writing this for my own reference so that I can recreate my own setup on new machines.

There are existing mail server tutorials for Alpine Linux, including ones for Postfix and Dovecot. This tutorial aims to be "monolithic" (i.e. covers the entire mail server setup with all its components), making it easier to follow without trying to follow different tutorials that may not be 100% compatible with each other, and to be adapted to my own specific use-cases, which may not be yours.

I am hugely indebted to LinuxBabe's mail server tutorial for Ubuntu, which is actually what I followed to set up my own server. Essentially, this tutorial could be thought of as an Alpine Linux adaptation of LinuxBabe's tutorial. If you want to set up an Ubuntu or Debian mail server, I recommend following LinuxBabe's tutorial, which is written very clearly and is easy to follow.

The mail server will be composed of the following software:

Component	Software
Mail transfer agent	Postfix
Mail delivery agent	Dovecot
DKIM authentication and signing	OpenDKIM
Spam filter	Amavis	SpamAssassin
Antivirus	Amavis	ClamAV
MDA server-side filtering	Pigeonhole

Postfix will be our SMTP server, and Dovecot will run an IMAP server for us.

Postfix and Dovecot are required for the minimum of what you'd expect from a working mail server (i.e. a user can log in through a standard SMTP/IMAP/POP3 email client, read their emails, and send emails). The rest is optional and modular, i.e. you can opt to have e.g. Pigeonhole but not Amavis.

We will end up with a small-scale mail server running on Alpine Linux with one domain, and we will use Unix user accounts as mail accounts. We will only set up IMAP, not POP3.

This tutorial was written for Alpine Linux 3.20.3, though will most likely work on other versions too.

This tutorial assumes no prior knowledge about mail servers.

You will need

A server

Any computer will do. This tutorial is for Alpine Linux specifically.

The relevant thing to consider for your server is that port 25 (the port for sending email) is not blocked. Most VPS hosts block port 25 because spammers commonly use VPSes to send spam, so you will need to find one that doesn't block port 25. Some VPS hosts block port 25 by default, but will unblock it upon request, and re-block it if they find you are spamming.

A domain name

Self-explanatory. You need a domain name and the ability to set its DNS records.

Before you start

Set up your DNS records

Firstly, pick a domain for your mail server. If you're sending emails from domain.com, mail.domain.com is a common choice.

MX record

An MX record denotes that your domain is used to send and receive email, and tells other MTAs the domain name of your mail server. We will use mail.domain.com for your MX record. For instance, my MX record looks like:

revsuine.xyz.                    14400 IN MX    0 mail.revsuine.xyz

Mail server records (A, AAAA, and/or CNAME)

Now you need to set a record stating the IP address of your mail server (mail.domain.com above). Depending on your setup, you may want to create a CNAME record pointing to domain.com if the IP address of mail.domain.com is the same as the IP address of domain.com, or an A record if the IP address is not shared with another domain.

I use a CNAME record because the IP addresses of mail.revsuine.xyz and revsuine.xyz are the same, so my record is:

mail.revsuine.xyz.               14400 IN CNAME revsuine.xyz

If you use an A record, your record may look something like

mail.domain.com.                    14400 IN A     ip.address.here

If you use IPv6, you should also add an AAAA record, e.g.:

mail.domain.com.                    14400 IN AAAA  ip:address:here::

A note on my DNS records

I use one server with one IP address for hosting several services under one apex domain. For instance, my static website is hosted at revsuine.xyz; my Nextcloud is hosted at cloud.revsuine.xyz; and my mail server is hosted at mail.revsuine.xyz. To handle this setup, I've created a subdomain master.revsuine.xyz (you can call the subdomain anything you want) with an A record (because your PTR record is expected to be an A record, not a CNAME record) to my server's IP address.

I set my server's hostname and PTR record to master.revsuine.xyz. I will also refer to this master.revsuine.xyz subdomain further down when configuring Postfix.

PTR record

A PTR record is used for "reverse DNS", or rDNS, lookup: instead of mapping a domain to an IP address, it maps an IP address to a domain. It is not managed through your DNS manager (e.g. whomever you bought your domain name from), but through whoever gives you your IP address. If you rent a server, be it a VPS or a dedicated server, your hosting provider whom you rent from will be able to manage PTR records. You may have an option to add a PTR record in the dashboard of your hosting provider, or you may have to contact their support to get a PTR record added.

For the above stated reasons, my PTR record for my single server (which hosts all my services) is master.revsuine.xyz.

If your hostname is mail.domain.com, your PTR record should be mail.domain.com.

Unblock your ports

After unblocking ports from your internet provider (e.g. if your VPS host blocks outgoing port 25), make sure the following TCP ports are open on your firewall:

Port	Usage
25	SMTP
143	IMAP
465	Email message submission over TLS
587	Email message submission
993	IMAPS (IMAP over TLS)

Obtain a TLS certificate

To enable TLS encryption, you need a certificate. Let's Encrypt provides free TLS certificates. To get a certificate from them, you can use certbot:

# apk add certbot

We will need a web server to use certbot. I'm going to use nginx for this guide, because nginx is what I use on my server, but the certbot website has instructions for a variety of setups. If you don't already have an nginx server, install nginx and set it up now.

Install certbot-nginx with:

# apk add certbot-nginx

Add the following to your nginx config (for instance, inside http {} in /etc/nginx/nginx.conf, or in a dedicated virtual host file /etc/nginx/http.d/mail.domain.com.conf):

server {
    listen 80;
    listen [::]:80;
    server_name mail.domain.com;

    root /usr/share/nginx/html/;

    location ~ /.well-known/acme-challenge {
        allow all;
    }
}

Replace mail.domain.com with the FQDN of your mail server.

The root can be set to any extant directory on your system that you're happy to publish to the web. You can just make an empty directory at /usr/share/nginx/html, or make this the directory of your website, etc.

Reload or restart nginx for the changes to take effect:

# rc-service nginx reload

Now run the following command to get your free TLS certificate:

# certbot certonly -a nginx --staple-ocsp --email your@email.here -d mail.domain.com

If you have several subdomains in your nginx config that you'd like covered by the same certificate, you can omit -d mail.domain.com and get a certificate covering all the domains in your nginx config. On my server, I have one certificate at /etc/letsencrypt/live/revsuine.xyz/ covering my apex domain and all subdomains. If you go for a certificate with only one domain name, e.g. for mail.domain.com, it will be at /etc/letsencrypt/live/mail.domain.com/.

Postfix

Postfix is a mail transport agent (aka SMTP server). In its own words:

Postfix attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.

Installing Postfix

On your server, install Postfix with:

# apk add postfix

You likely also want to have Postfix documentation:

# apk add postfix-doc

Verify that Postfix is installed by checking its version:

$ postconf mail_version

Configuring Postfix

Edit /etc/postfix/main.cf.

You should set myhostname to the hostname of your server; in my case, this is master.revsuine.xyz.

Now set mydomain to the domain you intend to send email from. For instance, my email addresses are name@revsuine.xyz, so mydomain is set to revsuine.xyz.

myorigin determines the domain name in the From: field of locally sent emails. So you could for instance set this to revsuine.xyz.

Set mydestination to the following:

mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

mydestination states the list of domains your machine will consider itself the destination for, e.g. if mydomain is set to revsuine.xyz then any emails sent to username@revsuine.xyz will be sent to my server according to the above configuration.

maillog_file denotes where Postfix's log file is. By default this is /var/log/messages; you may want to configure Postfix to have a dedicated log file like /var/log/postfix.log.

You probably want to have logrotate rotate your Postfix log. If there isn't already such a file, you want to create one at /etc/logrotate.d/postfix:

/var/log/postfix*.log
/var/log/mail*.log
{
    daily
    missingok
    notifempty
    rotate 7
}

Add the following TLS settings, replacing your.domain.com with your mail server's FQDN, or otherwise where the TLS certificate we generated would be:

# Enable TLS encryption when Postfix receives incoming emails
smtpd_tls_cert_file = /etc/letsencrypt/live/your.domain.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/your.domain.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = lmdb:${data_directory}/smtpd_scache

# Enable TLS encryption when Postfix sends outgoing emails
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = lmdb:${data_directory}/smtp_scache

# Enforce TLSv1.3 or TLSv1.2
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

# only offer authentication after STARTTLS
smtpd_tls_auth_only = yes

# disable SSL compression
tls_ssl_options = NO_COMPRESSION

# Configure the allowed cipher list
smtpd_tls_mandatory_ciphers = high
smtp_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
tls_preempt_cipherlist = yes

The allowed cipher list is from Mailcow.

If you're using this as a personal mail server, you may not want to have a mailbox size limit, so you can set:

mailbox_size_limit = 0

By default, mailbox_size_limit is 51200000. This number is in bytes. You can similarly set a message_size_limit.

Finally, here are some various hardening settings you can add to your /etc/postfix/main.conf:

# connections rate limit: no of connections allowed per unit
# `postconf anvil_rate_time_unit` will give the time unit; by default it's
# 60 seconds, so 600/60=10 connections allowed per second
smtpd_client_connection_rate_limit = 600
# messages rate limit, again over same time limit
smtpd_client_message_rate_limit = 60
# VRFY command used to check if an email address exists
# not needed and can be used to find spam recipients
disable_vrfy_command = yes
# servers that don't use HELO or EHLO are either not properly configured
# or sending spam usually
smtpd_helo_required = yes
smtpd_delay_reject = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_unknown_helo_hostname,
    permit

Send your first email

Have the postfix service auto-start upon boot, and start it during this session:

# rc-update add postfix default
# rc-service postfix start

You can now send an email with the following command:

$ echo "test email" | sendmail user@externaldomain.com

Send this email to your email account with an external server, e.g. a Gmail account. Note that Protonmail has quite stringent spam filters and this likely would be rejected by Protonmail, i.e. not even reach your spam folder.

Configure email aliases

You can configure aliases for your mail server. Edit the /etc/postfix/aliases² file.

You shouldn't receive mail as root, so configure root to have an alias to your user, e.g.

root: revsuine

You also must have a MAILER-DAEMON and postmaster alias present:

MAILER-DAEMON: postmaster
postmaster:    root

Note how you can have referential aliases; mail to postmaster is aliased to root, which is aliased to revsuine, so ultimately revsuine will get postmaster's mail.

You can continue to populate the aliases file with whatever aliases you want.

Enable Postfix submission and smtps service

To send emails from email clients, you'll need to enable Postfix's submission service so that Postfix can receive emails to send via SMTP. Edit /etc/postfix/master.cf and ensure that the following lines are present:

submission inet n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtp_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth

smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth

They may be commented out, or partially present without some options.

Restart Postfix.

# rc-service postfix restart

Dovecot

Dovecot is a popular IMAP and POP3 server which we'll be using for our MDA. Let's install it:

# apk add dovecot

Check the Dovecot version with:

$ dovecot --version

Now let's enable IMAP by editing /etc/dovecot/dovecot.conf. Find a protocols = line, or add one, and set it to:

protocols = imap

Configure how to store emails

You probably want to use the Maildir format for storing emails, where each user's mail is stored at ~/Maildir (this can be set to another location if desired).

In /etc/dovecot/conf.d/10-mail.conf, set:

mail_location = maildir:~/Maildir
mail_privileged_group = mail

mail_privileged_group tells us which group of Unix users can send mail; in this case, it's anyone in the mail group. You can create the group with:

# addgroup mail
# adduser postfix mail
# adduser dovecot mail

We want to ensure that postfix and dovecot users have the right to access mail.

To change the Maildir directory, e.g. to set it to ~/mail, you would set the following:

/etc/dovecot/conf.d/10-mail.conf:

mail_location = maildir:~/mail

/etc/postfix/main.cf:

home_mailbox = mail/

Get emails with LMTP

LMTP is a protocol which can be used for Postfix to pass incoming emails to Dovecot. To install it for Dovecot:

# apk add dovecot-lmtpd

Add lmtp to the supported protocols in /etc/dovecot/dovecot.conf:

protocols = imap lmtp

Now change the LMTP service (or add if it isn't already there) in /etc/dovecot/conf.d/10-master.conf to:

service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }

Postfix needs to be configured to use this socket. Edit /etc/postfix/main.cf with the following lines:

mailbox_transport = lmtp:unix:private/dovecot-lmtp
smtputf8_enable = no

Configuring authentication

Edit /etc/dovecot/conf.d/10-auth.conf and uncomment the following line:

disable_plaintext_auth = yes

This disables plaintext authentication unless SSL/TLS is used.

In the same file, configure auth_username_format. As the variable name suggests, this denotes the format the server expects usernames in for authentication. Setting it to %n removes the domain, so to sign in to user@domain.com you'd enter your username as user. For this setup, you should set auth_username_format to %n, because we are using Unix user accounts for email accounts; Dovecot wouldn't be able to find user@domain.com because the mailbox user is just user.

In the same file again, auth_mechanisms is a space-separated list of authentication mechanisms your server uses. Set this to

auth_mechanisms = plain login

login is mostly to support older email clients, but is optional.

Edit /etc/dovecot/conf.d/10-master.conf, and change service auth to the following:

service auth {
    unix_listener /var/spool/postfix/private/auth {
        mode = 0660
        user = postfix
        group = postfix
    }
}

Now we need to set the actual mechanism through which the server knows what password to expect, and what users exist. We will use a file at /etc/dovecot/passwd to manage this. Edit /etc/dovecot/conf.d/auth-passwdfile.conf.ext to be the following:

passdb {
    driver = passwd-file
    args = scheme=argon2id username_format=%n /etc/dovecot/passwd
}

userdb {
    driver = passwd
}

See this documentation to decide on a password scheme to use. I picked argon2id as the most secure option, however also the most expensive option, so it may be a poor option if you have many users. Dovecot recommends that, if using ARGON2ID, you set vsz_limit = 2G for the auth service. To do that with our setup, edit /etc/dovecot/conf.d/10-master.conf and add the line

vsz_limit = 2G

to the service auth {} section.

Now we want to include this file. Edit /etc/dovecot/10-auth.conf and ensure it includes this line, and that other !include lines for other auth-*.conf.ext files are commented out:

!include auth-passwdfile.conf.ext

Creating a user

Now let's create a user. We will be using a Unix user account, so create one with adduser if you don't already have one. Their Unix username will be their email username, and what appears before the @ in their email address. They should also be in the mail group. So for instance:

# adduser revsuine
# adduser revsuine mail

We will not, however, be using their Unix password for authentication. Instead, we'll set them a password dedicated for their email account. Create or edit the /etc/dovecot/passwd text file. Have a look at the following example:

revsuine:{ARGON2ID}$argon2id$v=19$m=65536,t=3,p=1$H1oyL7UdwUWiBuZGnyXorQ$3aW/cfyNdrjoHw3OK7HlOzwgKqdg61prln8QMtWJijg
muffalo:{ARGON2ID}$argon2id$v=19$m=65536,t=3,p=1$KLnLOiqlhbhOPLhmTUqllA$Raki8Rw/+eOgJzDSEXxtw0mqI+aYLyFf+gpi+MQTdfo
thrumbo:{ARGON2ID}$argon2id$v=19$m=65536,t=3,p=1$8R4rVQ2hlKmiZ0Zmyzwg0g$tkesrePjJfLAEKu1wyJY1tu6V+fR5+C6/etyKq6WJlQ

This lists three users, revsuine, muffalo, and thrumbo (those are their usernames). These will all be system users in the mail group. After the colon is the ARGON2ID hash of their password.

If you're storing passwords with ARGON2ID, to get what goes after the colon in your passwd file, run this command:

# doveadm pw -s argon2id

You will be prompted to enter a password, and then it will output exactly what to put after the colon, such as {ARGON2ID}$argon2id$v=19$m=65536,t=3,p=1$H1oyL7UdwUWiBuZGnyXorQ$3aW/cfyNdrjoHw3OK7HlOzwgKqdg61prln8QMtWJijg. Each user is their own line of the file.

Set up your /etc/dovecot/passwd file accordingly, making sure each user listed is also a system user, because we are storing their mail in their home directories.

Use your TLS certificate

Edit /etc/dovecot/conf.d/10-ssl.conf and set the following options (some should already be present, so you should just change their values):

ssl = required
ssl_cert = </etc/letsencrypt/live/mail.domain.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.domain.com/privkey.pem
ssl_prefer_server_ciphers = yes
ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305

Replace mail.domain.com with the domain you obtained your TLS certificate for. You can check

$ ls /etc/letsencrypt/live

if you're not sure.

The cipher list is from Mailcow.

OpenSSL 3.x has a FIPS provider which is incompatible with Dovecot, so it should be disabled. Edit /etc/ssl/openssl.conf and make sure the following line is commented out:

# providers = provider_sect

Configure "special" mailboxes

The file /etc/dovecot/conf.d/15-mailboxes.conf denotes "special" mailboxes, such as your spam folder. You can configure these, including setting these to auto-create, in /etc/dovecot/conf.d/15-mailboxes.conf. I have mine set to:

# NOTE: Assumes "namespace inbox" has been defined in 10-mail.conf.
namespace inbox {
  # These mailboxes are widely used and could perhaps be created automatically:
  mailbox Drafts {
    special_use = \Drafts
    auto = create
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Spam {
    special_use = \Junk
    auto = create
  }
  mailbox Trash {
    special_use = \Trash
    auto = create
  }

  # For \Sent mailboxes there are two widely used names. We'll mark both of
  # them as \Sent. User typically deletes one of them if duplicates are created.
  mailbox Sent {
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
    auto = create
  }

  mailbox Drafts {
    special_use = \Drafts
    auto = create
  }
}

You can set the auto = create option for any mailbox you want to be auto-created for users.

Now restart Dovecot. Keep an eye on terminal output, as if there's a configuration error, you'll get an error message when restarting.

# rc-service dovecot restart

Use a local email client

You are now ready to try logging in on a local email client such as Thunderbird, Evolution, Geary, KMail, etc.

To log in:

Enter your display name, email address (this is [Unix user]@[mydomain variable in Postfix config]), and the password you set for yourself in /etc/dovecot/passwd. Set the following settings:

	Incoming	Outgoing
Server type	IMAP	SMTP
Server	`mail.domain.com`, or whatever your MX record is set to
Port	993	465
Username	Your system username; this should be the contents of your email address before the `@`
Encryption	SSL/TLS
Authentication	Password	PLAIN (shows up as `Normal password` in Thunderbird)

With our setup, we are also able to use STARTTLS on port 143 (incoming) and 587 (outgoing) too.

You should be able to send and receive emails as normal now.

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 mechanisms 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, 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. ↩︎
Your aliases file will most likely be in this location by default, but you can run
```
$ postconf alias_maps
```
to find out where this file should be. ↩︎

31 KiB Raw Blame History