Mail Server Series — Part 2

This article is Part 2 of the Mail Server series.
In Part 1, we looked at the overall architecture and major service components.
In this part, we focus on the foundational architecture required for a modern, secure, multi-domain mail server:

Why correct DNS + Certificates + Ports determine whether mail delivery succeeds
How to design a multi-domain Postfix/Dovecot system inside Docker
How to use SNI (Server Name Indication) for multi-domain SMTP/IMAP
Firewall rules and networking considerations
Common issues and troubleshooting guidance

This article provides the architectural foundation for the upcoming implementation chapters.

1. High-Level Network Architecture

Below is the actual deployment structure used in this series:

                    +----------------------+
                    |   Public Internet    |
                    +----------------------+
                             |  (MX)
                         [Firewall]
                             |
                 +-----------------------------+
                 |   Docker Host (172.18.0.1)  |
                 |   intranet-net (external)   |
                 +-----------------------------+
                             |
   -------------------------------------------------------------------------
   |          |             |             |                 |
Postfix    Dovecot      Amavis       ClamAV           SpamAssassin
25/587   110/995/143   10024/10026      3310                 783
   |
 pilermilter (33333)
   |
 Piler Archive  +  Manticore (full-text index)
   |
 Roundcube Webmail

🧩 Key Principle: All services run inside the same Docker Network (`intranet-net`)

Benefits:

Containers can resolve each other by name (e.g., postfix → dovecot)
No extra NAT / port forwarding required inside the network
Firewall rules remain centralized on the host
Internal communication stays isolated from the public Internet

✨ Why the Docker Host (172.18.0.1) matters

Many services communicate through the host, for example:

Roundcube → Dovecot (TLS/IMAP & ManageSieve)
Postfix → Dovecot SASL → SpamAssassin → Amavis → ClamAV
Piler → Manticore → Memcached

If Host firewall rules block traffic, containers will fail unexpectedly.

Recommended rule (very important):

iptables -I DOCKER-USER 1 -s 172.18.0.0/16 -d 172.18.0.1 -j ACCEPT

2. Ports Used by the Mail Stack

Mail servers require many ports; missing any one of them causes failures.
Below is the port reference table used in this architecture:

Service	Port	Description
Postfix	25	Public inbound mail (MX), outgoing SMTP
	587	Submission with TLS + SASL
	465	SMTPS (optional)
Dovecot	110/995	POP3 / POP3S
	143/993	IMAP / IMAPS
	24	LMTP for Postfix delivery
	4190	ManageSieve
Amavis	10024/10026	Inbound filtering / outbound reinjection
ClamAV	3310	Virus scanning
SpamAssassin	783	spamc/spamd
Piler	2525	Internal archive transport
Manticore	9306/9312	SQL / Search
pilermilter	33333	Envelope-recipient expansion

3. DNS Requirements (Most Common Cause of Mail Failures)

To run a modern mail system, DNS configuration must include:

✔ A Records

it.demo.tw → Public IP
mail.it.demo.tw → Public IP
webmail.it.demo.tw → Public IP
archive.it.demo.tw → Public IP

✔ MX Records

it.demo.tw.    MX 10 it.demo.tw.

MX must point to an A record, not a CNAME.

✔ SPF Example

Strict version:

"v=spf1 ip4:x.x.x.x -all"

More flexible:

"v=spf1 ip4:x.x.x.x include:_spf.google.com ~all"

✔ DKIM

Generated by Amavis:

/etc/amavis/dkim/it.demo.tw.mail2025.pub

DNS record:

mail2025._domainkey.it.demo.tw    TXT   "v=DKIM1; k=rsa; p=...."

✔ DMARC

Recommended initial policy:

_dmarc.it.demo.tw   TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Later you may upgrade to:

p=quarantine
p=reject

✔ Reverse DNS (PTR)

Critical for Gmail/Outlook delivery:

Public IP → it.demo.tw

Without correct PTR, major providers will treat your server as suspicious.

4. Web HTTPS & Let’s Encrypt Architecture

All web services (PostfixAdmin, Roundcube, Piler) are routed through Apache:

Public → Apache HTTPS → container (HTTP)

Advantages:

Centralized certificate management
Renewal does not require container rebuild
Postfix and Dovecot can mount /etc/letsencrypt directly
ACME challenge handled cleanly by Apache

This approach is recommended for multi-service mail stacks.

5. Postfix Server-Side SNI Architecture

Postfix supports server-side SNI.
This means:

Incoming SMTP connections can be served with different certificates
depending on the domain the client requests.

Useful for deployments hosting:

it.demo.tw
nuface.tw
ho-tso.tw
awin.idv.tw
…all on the same server.

SNI Map Example

smtpd_tls_server_sni_maps = lmdb:/etc/postfix/tls_sni

tls_sni:

it.demo.tw /etc/letsencrypt/live/it.demo.tw/privkey.pem /etc/letsencrypt/live/it.demo.tw/fullchain.pem
nuface.tw /etc/letsencrypt/live/nuface.tw/privkey.pem /etc/letsencrypt/live/nuface.tw/fullchain.pem

Build the LMDB:

postmap -F lmdb:/etc/postfix/tls_sni

Important Note

Outbound SMTP does not use SNI.
SMTP servers present certificates based on their own hostname.

6. Dovecot SNI (IMAP/POP3/ManageSieve)

Dovecot allows per-domain certificate selection:

local_name it.demo.tw {
    ssl_cert = </etc/letsencrypt/live/it.demo.tw/fullchain.pem
    ssl_key  = </etc/letsencrypt/live/it.demo.tw/privkey.pem
}

Critical Pitfall

The IMAP/SMTP client must connect using the certificate’s CN/SAN.

❌ Wrong:

tls://dovecot
tls://172.18.0.1

✔ Correct:

tls://it.demo.tw

Otherwise Roundcube / Outlook / Thunderbird will report certificate validation failures.

7. Typical Issues and Troubleshooting

Issue 1 – TLS peer name mismatch

Symptoms:

Roundcube login fails
Outlook rejects the IMAP connection
openssl s_client shows hostname mismatch

Cause:

Certificate CN = it.demo.tw
Client connects using internal hostname (e.g., dovecot)

Issue 2 – Containers can’t reach each other

Cause:

Host firewall blocks traffic from Docker → Host

Fix:

iptables -I DOCKER-USER 1 -s 172.18.0.0/16 -d 172.18.0.1 -j ACCEPT

Issue 3 – DKIM fails

Common causes:

Wrong selector name
DNS automatically adds quotes or semicolons
Key too long → DNS broken into invalid chunks

Issue 4 – SPF syntax errors

Common mistake:

-spf1 include:example.com-all

Missing spaces.

Correct:

v=spf1 include:example.com -all

Issue 5 – Submission (587) authentication fails

Checklist:

Dovecot auth service is listening
Postfix correctly configured:

smtpd_sasl_path = inet:dovecot:12345

Issue 6 – Amavis reinjection problems

Check:

master.cf 10024/10026 routing
10025/10027 reinjection
firewall between amavis ↔ postfix

🎉 Conclusion

This chapter explained the essential foundations required before building the full mail stack:

Docker network architecture
Required ports and service flows
DNS fundamentals (A/MX/SPF/DKIM/DMARC/PTR)
HTTPS architecture using Apache + Let’s Encrypt
SNI with Postfix and Dovecot
Common pitfalls and troubleshooting

These concepts provide the groundwork for all remaining articles.

Network Architecture, DNS Configuration, TLS Design, and Postfix/Dovecot SNI Explained

Mail Server Series — Part 2

1. High-Level Network Architecture

🧩 Key Principle: All services run inside the same Docker Network (`intranet-net`)

✨ Why the Docker Host (172.18.0.1) matters

2. Ports Used by the Mail Stack

3. DNS Requirements (Most Common Cause of Mail Failures)

✔ A Records

✔ MX Records

✔ SPF Example

✔ DKIM

✔ DMARC

✔ Reverse DNS (PTR)

4. Web HTTPS & Let’s Encrypt Architecture

5. Postfix Server-Side SNI Architecture

SNI Map Example

Important Note

6. Dovecot SNI (IMAP/POP3/ManageSieve)

Critical Pitfall

7. Typical Issues and Troubleshooting

Issue 1 – TLS peer name mismatch

Issue 2 – Containers can’t reach each other

Issue 3 – DKIM fails

Issue 4 – SPF syntax errors

Issue 5 – Submission (587) authentication fails

Issue 6 – Amavis reinjection problems

🎉 Conclusion

1 thought on “Network Architecture, DNS Configuration, TLS Design, and Postfix/Dovecot SNI Explained”

Mail Server Series — Part 2

1. High-Level Network Architecture

🧩 Key Principle: All services run inside the same Docker Network (intranet-net)

✨ Why the Docker Host (172.18.0.1) matters

2. Ports Used by the Mail Stack

3. DNS Requirements (Most Common Cause of Mail Failures)

✔ A Records

✔ MX Records

✔ SPF Example

✔ DKIM

✔ DMARC

✔ Reverse DNS (PTR)

4. Web HTTPS & Let’s Encrypt Architecture

5. Postfix Server-Side SNI Architecture

SNI Map Example

Important Note

6. Dovecot SNI (IMAP/POP3/ManageSieve)

Critical Pitfall

7. Typical Issues and Troubleshooting

Issue 1 – TLS peer name mismatch

Issue 2 – Containers can’t reach each other

Issue 3 – DKIM fails

Issue 4 – SPF syntax errors

Issue 5 – Submission (587) authentication fails

Issue 6 – Amavis reinjection problems

🎉 Conclusion

1 thought on “Network Architecture, DNS Configuration, TLS Design, and Postfix/Dovecot SNI Explained”

🧩 Key Principle: All services run inside the same Docker Network (`intranet-net`)