On Tue, Aug 24, 2010 at 08:56:21AM -0500, Chris Adams wrote:
> They can't be configured that way; they don't implement SMTP. It is a
> de-facto standard for Unix programs to send mail by piping the message
> to either /bin/mail or /usr/{sbin,lib}/sendmail. That has the advantage
> of queueing for later delivery (what if I'm off-line when mdmonitor
> detects a failure?) and such.
The problem with delivering this to a user's mailbox via an MTA is that
in the typical case it doesn't result in the user noticing anything
until they've logged in as root and find out that the "you have new
mail" message actually means "Your RAID is fucked" and not just "Here's
some random syslog spew that something you installed and forgot about
keeps generating". If the question is "How do I ensure that important
system messages get delivered to someone who can do something about them
in a timely manner", a local MTA isn't a great answer.
There's certainly a set of people who want an MTA for this - in a server
environment it's obviously far more straightforward to get mailed on
failure, and that's something that you'll probably configure when
setting up the machine in the first place. But we're talking about the
default install case, and right now the situation is that anything that
pipes directly to sendmail is almost certainly never being read by the
user. Having an MTA installed doesn't solve the problem that we want to
solve, and so dropping an MTA from the default install means a reduction
in the quantity of privileged code running on the system without any
significant reduction in functionality.
The long term fix would arguably be to provide a stub /usr/sbin/sendmail
that ties into a more generic event reporting interface, which in turn
could be configured to send mail elsewhere but would default to popping
up some sort of desktop notification.
--
Matthew Garrett | mjg59@xxxxxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
