1,234
edits
Changes
→Overview
The diagram above doesn't even include reading email, but it's as simple as it gets (if you want to run an email server). You will need to learn to administer basics of all the systems in the diagram. We won't go in too much depth, only the minimum you need. But we will not (for example) go over every detail of Postfix, which on its own has a rather [https://en.wikipedia.org/wiki/Postfix_%28software%29#Architecture complex] [https://www.credativ.de/blog/postfix-architecture-overview diagram].
=== Terminology ===
The terms MTA, MDA, MUA, LDA are not 100% well defined, because few of the related services are simple and do exactly one thing. There is overlap, so if you don't find the acronyms helpful - don't worry about them. But they can help organize your thoughts when trying to keep all this in your head.
[http://wiki.dovecot.org/MailServerOverview Here's an overview] of from the Dovecot wiki, it's worth reading.
In our diagram we have:
* A user. That's the person who wants to send an email.
* An MUA (email client). This is the application the user uses to send an email. It can be a native application or a web application. We'll set up both types.
* Two MTAs. These are the servers responsible for getting your emails to the destination server.
** They are similar to routers (whcih route packets) but work on the application layer rather than the network layer.
** In our example there are only two MTAs - but there can be several.
** You connect to your MTA over a secure connection, so your emails can't be read by the operators of the network you're connected to.
** The rest of the way to the destination MTA the emails travel completely unencrypted, so anyone with access to the routers in between can read all your emails. This is why many organizations will refuse to send you confidential information over email.
* The LDA/MDA will receive the email from the MTA, and will store it on disk in some format. MailDir and MBOX are the most popular mailbox formats.