Learn Mailserver - Core Concepts & Main Architecture

#Introduction

Episode 1 explained why our components exist. Episode 2 answers how they work together. This is the architecture map: who does what, where messages flow, and which port each service listens on.

This map matters because every configuration in episodes 3 through 22 only makes sense if you know where it fits in the flow. You don't need to memorize every parameter — just understand the architecture, and the rest follows the pattern.

We'll cover the email flow from sender to recipient, the roles of MTA and MDA, the main components on your server, and the ports and protocols involved.

#The Email Flow: From MUA to MUA

Email flows through several "stations". Imagine sending a package through the post: you write the letter (client), drop it at the nearest post office (sending server), the post office ships it to the destination post office (relay), and then a courier delivers it to the recipient's house (mailbox). Here's the full picture:

MUA (client)  ->  MTA (send)  ->  MTA/relay (internet)  ->  MDA/LDA  ->  Mailbox  ->  MUA (read via IMAP/POP3)
     |              |                                          ^
     +--- SMTP 587 ---+                                        |
                               MX record points to             
                               recipient server on port 25     

In sequence:

1. MUA (Mail User Agent) — a client like Roundcube, Thunderbird, or a mobile email app — sends the message to your SMTP server.
2. MTA (Mail Transfer Agent) — Postfix — receives the message and forwards it to the destination server.
3. The MX record in DNS tells the MTA where to send: to the recipient's server.
4. MDA/LDA (Mail Delivery Agent / Local Delivery Agent) — on our server this is Dovecot via LMTP — places the message into the correct mailbox.
5. The recipient's client reads the email via IMAP or POP3.

Two different servers handle the two directions: the sending server transmits via SMTP, the receiving server stores via MDA and serves reads via IMAP.

#The Roles of MTA and MDA

The terms MTA and MDA are often confused. The difference is clear-cut:

• MTA (Postfix) is responsible for transporting messages between servers via SMTP. It talks to the outside world — receiving inbound email on port 25, forwarding outbound email, and handling the queue when the destination server is busy.
• MDA/LDA (Dovecot LMTP) is responsible for placing messages into the mailbox of the right user. On your server, the MDA can also write to Maildir, apply Sieve filters, and count against quotas.

Postfix itself can act as an MDA for system mailboxes (for example via mailbox_command), but for a modern architecture we hand delivery over to Dovecot LMTP — exactly what you'll assemble in episode 9.

#Main Components on Our Server

The three core components of this series occupy different positions in the flow:

• Postfix — the MTA. Listens for inbound SMTP (port 25), client submission (port 587), and SMTPS (port 465). It also runs the queue and outbound relaying.
• Dovecot — the IMAP/POP3 server and MDA in one. Listens for IMAP (port 143), IMAPS (port 993), POP3 (port 110), POP3S (port 995), and LMTP via a Unix socket. It also provides the SASL authentication socket used by Postfix.
• Roundcube — a PHP-based webmail. Not part of the SMTP/IMAP flow; it's a client that talks IMAP to Dovecot and SMTP to Postfix from the browser.

Beyond these, there are supporting components we'll install throughout the series: MariaDB/PostgreSQL for virtual users, OpenDKIM for signing, SpamAssassin, and ClamAV + Amavis for filtering.

#Ports and Protocols Involved

Each service listens on a specific port. This is the table you'll refer to constantly:

The golden rule: port 25 is only for server-to-server traffic. Your clients (Roundcube, Thunderbird, mobile apps) must use 587 to send and 993 to read. In episodes 6 and 16, this rule becomes part of both configuration and firewall policy. To see which services are listening on which ports, run ss -tlnp on the server.

#The Role of Relay and MX Records

Two networking concepts determine where messages go:

• Relay — a server willing to forward messages on behalf of other servers or clients. Outbound relaying carries your messages to the destination server; inbound relaying means accepting messages for your domain. The biggest danger — the open relay — is covered in episode 16.
• MX record — the DNS record that tells the world's MTAs: "for this domain, send email to this server". The numeric priority determines the order of attempts. Without an MX record, no other server will accept email for your domain.

Checking MX records with dig becomes a habit that will stay with you throughout the series:

dig MX example.com +short

If the output is empty, add the record in your DNS panel — episode 5 covers this in full along with SPF, DKIM, and DMARC.

One important nuance: when Postfix finds the MX record for a domain, it resolves it to a list of hosts, then tries to connect to each host according to priority. That's why a lower MX priority (for example 10) is always tried before 20. Understanding this explains a lot of seemingly mysterious "server busy" behavior in Postfix logs.

#A Mental Map for This Series

Before moving on to episode 3, take this mental map with you:

• Email inbound: port 25 Postfix → (filters) → Dovecot LMTP → Maildir.
• Email outbound: client → port 587 Postfix (authentication) → (DKIM signing) → internet.
• Client reads: IMAP 993 to Dovecot.
• Webmail displays: Roundcube talks IMAP and SMTP on behalf of the user.

Every subsequent episode simply fills in the details at a different station — Postfix in episodes 3 and 4, DNS in 5, TLS in 6, the database in 7, webmail in 8, and so on.

#Conclusion

Episode 2 is done. Key takeaways:

• Email flows from MUA → MTA → relay → MDA → mailbox → MUA.
• MTA (Postfix) transports; MDA (Dovecot LMTP) stores; IMAP/POP3 serves reads.
• Port 25 is for server-to-server traffic; clients use 587 (send) and 993 (read).
• The MX record determines the destination server; the relay carries messages in and out.
• Roundcube is a client, not part of the core SMTP flow.

Now the map is drawn. In episode 3 we start real practice: Postfix installation and basic configuration — installing the package, understanding main.cf, and getting to know the myhostname, myorigin, mydestination, and mynetworks parameters. See you in episode 3!