F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Fri, 19.07.13 20:22, Miloslav Trmač (mitr at volny.cz) wrote:

> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
> <mattdm at fedoraproject.org> wrote:
> > On Fri, Jul 19, 2013 at 07:37:35PM +0200, Miloslav Trmač wrote:
> >> However, having the /usr/sbin/sendmail API available to applications
> >> is valuable - it brings a significant system administration benefit of
> >> centralizing the SMTP configuration.
> >
> > What does it mean to "have available"?
> Just that.  The binary exists and does what it is expected to do.

Where "expected to do" means effectively route it to /dev/null?

> > As discussed earlier, I think it's
> > significantly better for applications to get errors (which they can handle)
> > than to think they've sent a message which really gets buried forever.
> 
> In the case I'm thinking about, application installation instructions
> just say "make sure $sendmail works" instead of "configure SMTP (and
> TLS! and SMTP auth!) in this application-specific configuration file".

If features only work after configuration (in articular non-trivial
configuration like this case) then it should not be part of the default
install. Because it is code, that claims to just work, but doesn't. That
is ver hard on the users, and simply is broken.

> > I think the way forward is to encourage applications to _log_ rather than to
> > send e-mail, via this or any other API.
> Application that want to log shoud log.  Applications that want to
> send e-mail should send e-mail.  My bank's monthly statement would be
> rather useless in the bank's splunk archive.

Sure, but your bank web site probably doesn't send its mails out with
only tools of the default install? They do with a heavily configured
installation of some OS, where they manually configured an SMTP server
and such. Only if they did this is it becomes useful. 

Let's not forget: this is not about removing software from the
distro. This is just about removing it from the default install, since
the current way it is set up by default it just eats up messages
silently, with not indication of error and no useful tools installed to
actually get the messages out of it again.

Despite that I am pretty sure that most of the stuff we currently mail
(like the log output of cron jobs) simply makes no sense as mail, and
should much rather be treated exactly like all other log output. There's
nothing special really about cron that would make it so much better
suitable for sending out its logs per mail, rather then just log them.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.