💾 Archived View for going-flying.com › ~mernisse › 29.gmi captured on 2024-02-05 at 09:33:39. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
E-mail is one of the oldest user applications on the Internet, only slightly younger than news and in this day and age most people leave it up to either Microsoft or Google to provide them with an e-mail address. There are real privacy concerns about giving up what has become a core of your online identity to a company like Google but that's not in scope for this article. One of the lesser known facts about e-mail is how important it is when taking care of UNIX-y infrastructure at any scale.
More on security and privacy as it relates to your public e-mail
At some point if you end up in something like systems administration at any scale you will find yourself taking care of computers that do things without user intervention. More often than not this is done by using a facility called cron(8). The default notification method of any errors in running jobs is for cron to send e-mail to the job owner's username at the system's hostname, though in most cases you can specify a variable in the cron job configuration file (called a crontab(5)) to override the destination address. There are other system features (such as sudo(8)) that will send e-mail alerts out as well so it is critical to make sure you see them. For this to happen at the very least you need a functioning MTA on the system.
E-mail flow can be complex. There are several parts to the system with which you should understand. Mail flow typically starts and ends at a MUA or Mail User Agent. This is what you use to compose and read e-mail. Think Outlook, or Mail (macOS / iOS), or the GMail app. Once you have composed a message it gets handed off to a MSA or Mail Submission Agent. This is often built in to the MUA but doesn't have to be (in the case of an MUA like mutt for example it is not). In the case of automated administrative alerts the system will call an installed MSA binary to send the message. The MSA's job is to get the e-mail into an MTA or Mail Transport Agent. This is Exim, or Postfix or Sendmail (or others). It's job is to take the message and get it to wherever it is addressed to. Typically there is an MTA responsible for each domain name. Finally a MDA or Mail Delivery Agent takes mail handed off from an MTA and puts it into some form of storage so a user can get it. Often this is a file on disk somewhere. Some MUAs like mutt can read those directly while others use a protocol like IMAP or POP to interface with the mailbox. In many cases the MDA (like Dovecot) will provide both the ability to write messages to storage AND access them over IMAP/POP.
So with the basic terms out of the way, we will start at the beginning of our hypothetical cron alert. The system is going to generate the destination e-mail address by taking the job owner's username and stuffing the system's hostname on the end. The system that I'm writing this on would send mail to mernisse@kitsune.internal.ub3rgeek.net for example. Not all users wish to have e-mail sitting on every system they interact with though so every system has a concept of e-mail aliases. This is a mapping of usernames to e-mail addresses that the system can use to look up where to deliver mail. This is usually stored in /etc/aliases and is documented in the aliases(5) manpage. At the very least you should map the root user on any system you control to an address you will check. In my case root@ goes to a mailing list so all the people involved in maintenance of the systems gets a copy of the notices.
Upon reviewing the aliases manpage you may also notice that the aliases file can be used to make a rudimentary e-mail list. This can be extremely useful if for example you want to notify yourself at multiple addresses (say your regular e-mail and one that alerts your phone).
There are several popular MTA packages out there. Postfix, Sendmail and Exim are the most popular. These days I maintain a hub and spoke model for Internet e-mail. My hosts (all Debian Linux) run the default install of Exim configured to smarthost e-mail to my main Internet facing mail server which is running Postfix. The Exim setup is straightforward enough, when the package installs it asks you what mode you want to run it in and you select 'mail sent by smarthost'. This essentially says that the local system delegates all mail handling for some other host. If you have already configured exim on your Debian system you can simply run `dpkg-reconfigure exim4-config` to get back to the initial install questions.
Now that you have systems pointed to a central mail server you have some decisions to make. Exim is a perfectly capable Internet MTA so you could configure it to relay mail or you could use Postfix like I do. There are pros and cons to both, I ended up using Postfix mostly out of inertia. At the time it was more flexible and I wanted a robust anti-SPAM system in place because I use it for not just administrative notifications but to run several mailing lists and provide Internet e-mail for several domains that I own. The specifics of configuration are left up to the reader in this case as each use-case is going to be different.
At the very least I'd suggest getting mail setup well enough that you can deliver alerts to somewhere that you will check. That may mean keeping them in a mailbox on your smarthost and then using a MDA like Dovecot to provide an IMAP interface to the mailbox and then picking it up with your MUA. You could even get fancy at this point and use one of the fine programming languages like Python that provide IMAP and POP capability to poll your mailbox and convert the messages into alerts using a service like Twilio or Pagerduty or bridge them into IRC, Discord, or Slack.
Because I provide my own mail as well as wanting all the administrative mail working I have a slightly more complex system than many will need but it may serve as a useful illustration of what you can build starting with these simple building blocks.
-
+------+ +------+ +------+ \
| host | | host | | host | |
| exim | | exim | | exim | |
+------+ +------+ +------+ |
| | | \
v v v / x3
+---------------+ |
| site-hub | |
| exim | |
+---------------+ /
| -
v
+---------------------+ +---------------+
| Internet hub |->| Mailing Lists |
| Postfix + rspamd |->| mailman |
+---------------------+ +---------------+
^ |
| v
_v _ +-----------+
( ` )_ | Mailboxes |
( INTERNET `) | dovecot |
(_ (_ . _) _) +-----------+
The only hard part is managing delivery to the big e-mail providers these days. You will need to learn technologies like DMARC, DKIM and SPF to make that work. You will also need to understand DNS as that is how e-mail federates in the wider Internet world. If you start doing mailing lists you will need to learn ARC as well. Thankfully there are tools like rspamd and mailman that can help you on your way and will integrate with the pieces we've talked about.
Understanding e-mail flow and making sure your systems can use it is an important component of the infrastructure in any UNIX-like world. Many people have pushed e-mail into a dark corner of their lives, but if you are going to take responsibility for caring for the machines you will need to rediscover one of the oldest user-facing applications on the Internet. In the long term you can gain enough knowledge and experience to take back control of your e-mail from the centralized service that likely owns it today.
🚀 © MMXX-MMXXIII matt@going-flying.com