On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
<[email protected]> wrote:
> On Fri, 19.07.13 20:22, Miloslav Trmač ([email protected]) wrote:
>
>> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
>> <[email protected]> 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?
It's actually less similar to /dev/null than log files are - log files
are rotated and deleted, mail stays in the mail boxes until explicitly
deleted (or space runs out).
>> > 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.
That a feature needs configuration does not automatically exclude it
from the default installation - removing a package from the default
installation and telling users to install it back is just window
dressing and asking them to do unnecessary extra work.
>> > 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?
"What is in the default install" is, as argued elsewhere, also an
implicit documentation of "how things are done".
Mirek
--
devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/devel
