F20 - Unintended consequences of no default MTA - How best to fix

[Chris Murphy]

On Jan 2, 2014, at 12:26 PM, "Lars E. Pettersson" <lars at homer.se> wrote:

> On 01/02/2014 08:09 PM, Chris Murphy wrote:
>> On Jan 2, 2014, at 11:45 AM, "Lars E. Pettersson" <lars at homer.se> wrote:
>>> It delivers mail, so it certainly does something. It is not an idle process doing nothing.
>> 
>> I've never seen it do anything since I started using Fedora, except cause longer boot times.
> 
> Strange, what kind of install do you have?
> 
> Long boot time would be it waiting for network, otherwise it starts quickly.
> 
> 9.093s postfix.service (my mailserver)
> 64ms sendmail.service (my desktop)

In the Fedora 19 era it was ~ 30-60 seconds according to systemd-analyze blame. There was a bug on it in the bugzilla which was blocking the "why we boot so slow" tracker for systemd. I think it's since been fixed, not sure, but now that the glory of no sendmail by default is here with Fedora 20 I don't need to think about that bug anymore.


>>> A user only needs to know how to edit /etc/aliases, i.e. add a line 'root: <username>' to it, run newaliases (or something in the line of my proposal earlier), and to setup the mail client to read that mail. Not more esoteric than to setup ordinary mail.
>> 
>> It's a minority use case.
> 
> How can it be a minority use case?

Really? In the whole world of computing you don't see this is a tiny tiny minority use case? It's so small it's not even really an edge case, it fell off the edge years ago. Even if we look at just linux derived systems, no Android system even has root enabled by default, let alone an MTA. It has a modern way of informing me of problems rather than sending me useless spam, without notifications of such.


>>> Not having a MTA leads to lost mail, this has to be addressed and solved before the MTA is removed.
>> 
>> Presumably if it's that important, an error is generated due to the lack of an MTA? If not, then it's not important. If ithere is an error, then at least it's being logged somewhere where it might be seen,
> 
> Someone sent a question about how to read mail to root without the MTA delivering it. It was logged that cron had a problem, but the output from cron, usually sent as a mail, was lost.
> 
> Exactly this question I asked Lennart Poettering on the devel list, but sadly got no answer.
> 
> How do we solve this problem without an MTA? (cron output lost)

yum install sendmail?

So you think a majority of users use cron?

> 
> > rather than the sendmail by default case which is the silent accumulation of emails in /var/spool/mail/root that most users have *no idea* is happening, and even if you managed to inform a majority of users this is happening,
> 
> This was the reason behind my proposal, to make it more obvious to the user that (possible) important mails from the system show up in spool mail.

After quite some time of accumulation of these unnotified emails, I found all of them to be totally useless, and not nearly as entertaining as get rich quick spam.

> 
>> the majority (like me) still have no idea how to retrieve, redirect, or stop them from being unnecessarily generated.
> 
> In what way unnecessary? If cron has problems, do you not want to know the output of that cron job, to be able to solve the problem?

I don't use cron. Probably in five years or so we can have a conversation on it not being installed by default.


Chris Murphy