Build your own lightweight mail server? First, understand the transmission principles!

Email Transmission Principles#

Mermaid Loading...

Note:

The gray part represents the other server
For reference only, feel free to discuss any errors in the comments!

Basic Definitions#

MUA (Mail User Agent) is the software that users use to send and receive emails. MUA communicates with MRA via IMAP or POP3 protocols.
MTA (Mail Transfer Agent) is the software on the mail server responsible for sending and forwarding emails via the SMTP protocol. MTA queries the corresponding mail server based on the domain name in the recipient's address and delivers the email to it.
MDA (Mail Delivery Agent) is the software responsible for saving emails received by MTA to local disk or specified location. MDA typically performs spam and virus scanning and provides email filtering and auto-reply functions.
MRA (Mail Retrieval Agent) is responsible for implementing IMAP and POP3 protocols and interacting with MUA. MRA helps users download or view emails from the mail server.
SMTP (Simple Mail Transfer Protocol) is a standard protocol for email transmission. It defines how to transmit and deliver emails over the internet. SMTP is a client/server protocol that uses TCP as the transport layer protocol and uses port 25 as the default port, while ESMTP uses ports 465/587.
IMAP (Internet Message Access Protocol) is a standard protocol for email storage and access. IMAP typically uses ports 143/993.
POP3 (Post Office Protocol version 3) is a standard protocol for downloading emails, allowing users to download emails from the mail server to their local computer via a mail client. It uses port 110 for transmission and works in conjunction with the SMTP protocol. The focus of the POP3 protocol is on downloading and does not support managing emails on the server.

Common MUAs include: Outlook, Apple Mail, Mutt, Fairemail

Common MTAs include: Sendmail, Postfix

Common MDAs include: procmail, dropmail, Cyrus

Common MRAs include: dovecot, Fetchmail, Getmail

Transmission Process#

The process of email transmission can be divided into the following steps:

This process will simulate "Xiao Ming" <[email protected]> sending to "Xiao Hong" <[email protected]>.

1. Sending#

Xiao Ming composes an email through MUA, specifies [email protected], clicks send, and MUA uses SMTP(s) to send the email to smtp.qq.com on port 25/465/587.

2. Delivery#

smtp.qq.com checks if the sending address belongs to that account; if it does, it continues to deliver. smtp.qq.com uses DNS to query the MX record for [email protected][^1]. After a successful query, it forwards the email to gmail-smtp-in.l.google.com.

3. Receiving#

This process is the most complex because there is no identity verification mechanism for sending emails. Therefore, to prevent spam/phishing/fraudulent emails from being transmitted, the receiving MTA performs various checks to ensure the email is trustworthy, and the MDA also scans for viruses and other processes after the MTA confirms receipt of the email. If the checks fail, the email may be rejected or classified as spam.

When receiving emails, Gmail checks DKIM/SPF/DMARC records and PTR records to ensure that the sender of the email is real, trustworthy, and that the email has not been tampered with.

DNSSEC
Subsequent checks are primarily based on the DNS system, so
the domain must support DNSSEC to prevent record tampering.

Specifically, when the receiving MTA receives an email, it verifies it according to the following process:

DKIM verification: Check if the email contains a signed DKIM header field. If it does, Gmail will use the public key to verify the message to ensure that the email is signed by the corresponding domain's private key, preventing email tampering.
SPF verification: Check if the sending server is listed in the SPF record of the sending domain. If not, the email may be considered a forged spam/phishing email.
DMARC verification: Check if the email complies with the DMARC policy of the sending domain. DMARC can specify how to handle emails that fail DKIM or SPF verification. For example, it can require these emails to be marked as spam or rejected.
PTR verification: Check if the IP address of the email matches the PTR record of the sending email's domain. PTR records are typically used for reverse DNS queries and can be used to verify the identity of the email sender.

Through the above verifications, the receiving MTA can determine whether the email comes from a trusted sender and effectively prevent spam and fraud.

4. Storage#

After gmail-smtp-in.l.google.com confirms receipt of the email, the MDA processes it, such as scanning/auto-reply, etc. It then stores it in [email protected]'s mailbox.

5. Viewing#

If Xiao Hong uses a MUA that supports Push (such as the Gmail client), she should have already received an email notification and can open it to see the email sent by Xiao Ming.

~~Please forgive me for using Xiao Ming and Xiao Hong; I'm just bad at naming.~~

Self-Built Mail Server#

Generally speaking, if you don't need a graphical interface and other additional features, a self-built mail server only needs the most basic functions of sending, receiving, and blocking spam. There is no need to use overly complex complete mail server solutions, such as iRedmail.

This section uses docker-mailserver as an example to set up a mail server. It includes services like postfix, dovecot, SpamAssassin, OpenDKIM, OpenDMARC, Fail2Ban, etc., and is simply configured to be ready to use. You can build a fully functional mail server in about half an hour.

docker-mailserver#

Prepare the Server#

Several conditions must be met:

The IP and server domain must not be blacklisted (can be checked via MX Super Tool).
Open port 25.
Configurable rDNS/PTR records (optional, but preferable).
A clean system; during installation, set the hostname to the mail server domain, such as mail.example.org.

If you are only using docker-mailserver to configure a simple mail server with a small number of users, the configuration does not need to be too high; 1c 512m is sufficient.

Of course, you need to install docker and docker-compose.

Configuration#

If your mail server is to be set up under a subdomain, such as mail.example.org, then set the hostname to the subdomain and the domainname to the apex domain[^2].

This is not where you fill in the sending domain
This only configures the domain where the mail server is located. For example, if configured as mail.example.org, then the sending domain MX records in the following sections will point to it.

If using the apex domain directly, set the hostname to example.org and remove the domainname.

version: '3.3'
services:
  mailserver:
    image: docker.io/mailserver/docker-mailserver:latest
    container_name: mailserver
    hostname: mail
    domainname: example.org
    env_file: mailserver.env
    environment:
      - SSL_TYPE=letsencrypt
    ports:
      - "25:25"    # SMTP  (explicit TLS => STARTTLS)
      - "143:143"  # IMAP4 (explicit TLS => STARTTLS)
      - "465:465"  # ESMTP (implicit TLS)
      - "587:587"  # ESMTP (explicit TLS => STARTTLS)
      - "993:993"  # IMAP4 (implicit TLS)
    volumes:
      - ./docker-data/dms/mail-data/:/var/mail/
      - ./docker-data/dms/mail-state/:/var/mail-state/
      - ./docker-data/dms/mail-logs/:/var/log/mail/
      - ./docker-data/dms/config/:/tmp/docker-mailserver/
      - /etc/localtime:/etc/localtime:ro
      - /etc/letsencrypt:/etc/letsencrypt
    restart: always
    stop_grace_period: 1m
    cap_add:
      - NET_ADMIN
    healthcheck:
      test: "ss --listening --tcp | grep -P 'LISTEN.+:smtp' || exit 1"
      timeout: 3s
      retries: 0

Environment Variables #

Here are the environment variables I use; please modify all example.org placeholders to your own configured main sending domain.

There are other options available for configuration; please refer to the documentation for the meanings of the related environment variables.

It is strongly recommended to use certbot to apply for certificates! The docker-compose.yml from the previous section is already configured to be compatible with certbot and letsencrypt; you only need to apply for an SSL certificate for a mail server domain using certbot outside the container.

For more SSL configuration methods, please refer to the documentation.

OVERRIDE_HOSTNAME=
DMS_DEBUG=0
LOG_LEVEL=info
SUPERVISOR_LOGLEVEL=info
ONE_DIR=1
ACCOUNT_PROVISIONER=
[email protected]
ENABLE_UPDATE_CHECK=1
UPDATE_CHECK_INTERVAL=1d
PERMIT_DOCKER=none
TZ=Asia/Shanghai
NETWORK_INTERFACE=
TLS_LEVEL=
SPOOF_PROTECTION=1
ENABLE_SRS=0
ENABLE_OPENDKIM=1
ENABLE_OPENDMARC=1
ENABLE_POP3=
ENABLE_CLAMAV=0
ENABLE_RSPAMD=1
ENABLE_RSPAMD_REDIS=
ENABLE_AMAVIS=1
AMAVIS_LOGLEVEL=1
ENABLE_DNSBL=1
ENABLE_FAIL2BAN=1
FAIL2BAN_BLOCKTYPE=drop
ENABLE_MANAGESIEVE=
POSTSCREEN_ACTION=enforce
SMTP_ONLY=
SSL_TYPE=
SSL_CERT_PATH=
SSL_KEY_PATH=
SSL_ALT_CERT_PATH=
SSL_ALT_KEY_PATH=
VIRUSMAILS_DELETE_DELAY=
POSTFIX_DAGENT=
POSTFIX_MAILBOX_SIZE_LIMIT=
ENABLE_QUOTAS=1
POSTFIX_MESSAGE_SIZE_LIMIT=
CLAMAV_MESSAGE_SIZE_LIMIT=
PFLOGSUMM_TRIGGER=
PFLOGSUMM_RECIPIENT=
PFLOGSUMM_SENDER=
LOGWATCH_INTERVAL=weekly
LOGWATCH_RECIPIENT=
LOGWATCH_SENDER=
[email protected]
REPORT_SENDER=
LOGROTATE_INTERVAL=weekly
POSTFIX_INET_PROTOCOLS=all
DOVECOT_INET_PROTOCOLS=all
ENABLE_SPAMASSASSIN=1
SPAMASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASSASS