Following on from part 2 of this series, is the requirement that e-mail must leave the system it's generated on, unless it's going to a mailbox on the local system which is actively monitored (weekly minimum, preferably every week-day or maybe even several times a day). Typically that place will only be on your actual mail server. In general, system mail must go to a real IMAP/POP/Exchange/LotusNotes/Whatever mailbox server (MDA), where someone' mail client will present it to them.
I no longer have sufficient fingers and toes to count the number of times I have discovered a Linux server with a full or rapidly filling /var partition, where on inspection /var/spool/mail/ has multi-hundred MB (or even into the GB) mail spool files for system level processes. Typically some cron job that is reporting a system error/problem, for days, weeks, or months on end, that no-one has been aware of because the mail is hiding on the local server. www-data for Apache on Debian/Ubuntu distributions is a favourite, although it's even worse when it's a real-user, who is running some important system process from cron as themselves.
There's two things needed here. Speaking specifically of Linux distributions (but also applies in some fashion to other unix variants):
- root e-mail needs to go off system, typically by adding an entry in /etc/aliases, e.g.
root: sysadmins@yourdomain.com - wildcard alias for all other users to root
Yes, specific users may go to other people; for example it's not out of the question for, say, www-data to be aliased to the developers who are best placed to fix any issues from the web application, or the postgres user to e-mail the DBA. But you need the wildcard to catch "everything else". Both exim and postfix require some specific non-default configuration to make that happen, which I'll be posting about soon.
Also on the e-mail front: the mailbox where this system mail emds up should typically be a shared one, not your own personal mailbox. If you're part of a team, then obviously keeping on top of any such messages is a shared responsibility, assuming you like taking breaks from work for more than day or two at a time. But even if you're a sole-charge sysadmin, having a separate mailbox for "system stuff" is a good separation of your personal communications from system-level messages. It also makes it easier if you end up with a team, or need to hand over the reins for a while (or quit).
So don't throw this mail away. Don't leave it languishing in local spool. And if it's annoying, then surely that's all the inspiration you need to find the source and fix it (or silence it if it's not necessary output). Remember: Silence is golden.