I was going to make this same comment as a joke, but if you read his reply to the decision, it's totally accurate. He would totally implement email in systemd if it meant Fedora would boot faster. He just decided that getting rid of email altogether would be even faster than that, and falling short of his campaign to "modernize" the distro, decided he'd find new ways around the body that makes these decisions.
You mean a single-user host? Mainly just reporting critical issues to the user.
Mail is a store-and-forward reliable messaging service that individuals and services can take advantage of. The primary way Ubuntu, RedHat, etc have used it for years is to allow the user to receive notifications of critical incidents in a way that they will see regularly. Things like disk usage reports, hacker attacks, packages upgraded/installed, cron job errors, etc.
The problem is everyone stopped using native e-mail clients years ago and now everyone uses webmail. So nobody ever checks their mailbox to find out the problems going on in their own host.
--
This is different than logging, by the way. Logs are intended to provide an archival record of events that the applications think you might need to know about. They do nothing to report to the user what is going on right now. Ideally you will get both a log and an e-mail when something bad happens, so you can delete the e-mail and keep the log.
This could all be solved by a very thin application that pops up when a new message arrives in the mail spool, highlighted in bold if it came from the local host. The user could be notified of critical issues in real time and have a built-in system to manage the reports (export/forward, sort, search, etc).
As far as it filling up your disk, mail spools don't get rotated, for obvious reasons. The simple compromise would be to either compress or rotate mail spools rather than get rid of them entirely - but that's too sensible a compromise for most :-)
Right now in one server I work on there are 9,961 messages in root's mail spool. You know how many of those message subjects are unique? 10. Do you know what they all have in common? They're all cron jobs that had some minor error that could have been corrected by me the first time I saw it. But I never saw it, because I don't log in as root, and as they pile up i'm less interested in digging through them.
A smart e-mail client could solve duplicate messages and console alerts. Some process optimization on the part of the distros could fix this whole mess. Removing the mail just buries it.
> You mean a single-user host? Mainly just reporting critical issues to the user.
(Yes, I read the rest of your comment :))
This is exactly what syslogs are supposed to do. Logs are just so insanely much simpler to get right as implementation artifacts. The key is no not log to a dozen different files scattered across /var/log, but to do it in a centralized manner (syslog, journal, whatever you want to call it).
It would be trivial (heck, someone's probably alread done it) to just listen for anything reported at "CRITICAL" level to the syslog and report that in a UI. Why on earth would you implement something as complicated as SMTP just to do that?
If you're concerned about monitoring X number of machines, having them send e-mail is decidedly not the way to do it. You'd use something like syslog forwarding (see rfc5424) and central aggregation/metrics.
EDIT: If there were a standard format for "syslog-over-email" then I could at least partially understand, but as it is you're going to get arbitrarily formatted messages from arbitrary programs. Not very useful.
You mentioned about 6 different topics in response to a need for telling a user about critical events on a single host. You might be over-thinking this :) The user just needs a user-friendly reminder that something needs to be addressed. The multiple machine thing is a separate issue.
Just preempting usual comebacks that I tend to see :). I argue too much about technology on the interwebs.
I don't think "a user-friendly reminder" == email these days. It might have been in the days of centralized servers and *NIX mainframes, but it that doesn't work any more.
A daemon is not necessary. You only need a binary called sendmail and a configuration file saying where emails should go (i.e., local files or submitted to some external mail server).
It's not a bad idea to have an (outbound only) daemon for the sake of reliability. If the remote server is down at the moment your "command | mail user@remote" job runs, you want it to queue locally for later delivery so that the mail command can return immediately.
If you're after reliability, the default config is probably not what you want. For the default config though, it may be preferable to keep things simple. Note that a cron setup could still work without an MTA daemon.
You're right, a daemon isn't necessary. It's just an artifact of the design of SMTP. The MTA is designed for both sending and receiving messages over a network. A daemon is the only way to meet all those requirements.
For the single-user host you just need a suid-root MDA that can change users to deliver mail into different spools. The daemon is doing the same thing, except it's an MTA that calls an MDA and it uses IPC. The IPC method is technically superior for many reasons, but as you say, not necessary.
https://plus.google.com/+LennartPoetteringTheOneAndOnly/post...