F20 System Wide Change: No Default Sendmail

[Billy Crook]

On Mon, Jul 22, 2013 at 11:41 AM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> On Fri, 19.07.13 13:17, Billy Crook (billycrook at gmail.com) wrote:
>> Sendmail stays in Default unless there is compelling reason to switch to
>> postfix, exim, meta1, etc.  Those users who wish to remove it are welcome
>> to do so.  Nobody is stopping them. The default configuration of sendmail
>> poses no problem to users who are unaware of it.
>
> Not true. I eats my cron logs and other stuff and I have no way to get
> the stuff out of it again with the core install...

If that's not hyperbole, then please clarify what "eats" refers to.
Or just take the 30 seconds or so to setup the MTA correctly, and all
of that stuff will be waiting for you in your inbox.  If you don't
want it mixed with human-originated mail, as some have complained,
then use filters to auto sort your mail.


>> Please voice yourself at meetings in #fedora-devel if this is important to
>> you.
>
> Yes, please, post a lot of "+1" messages. They contribute so positively
> (I mean, literally!) to any discussion. "+1" messages are really good
> for making a point as they contain so much additional arguments nobody
> has heard or read before. It's almost as constructive posting "+1"s, as
> it is posting sarcastic comments about their pointlessness...

There's not much else to do when it seems a lot of otherwise very
intelligent people still don't get it.  I'm certain that you are all
aware of how useful an MTA can be.  Choosing to cut it off rather than
properly configuring it, is rather un-fedora-like.  Why not remove
ipv6 support, since gosh it's hard too and who configures it?  And it
doesn't work for most people without explicit configuration.

Removing it (even just from the Default install) is wrong.


On Mon, Jul 22, 2013 at 12:28 PM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> On Mon, Jul 22, 2013 at 06:53:24PM +0200, Nicolas Mailhot wrote:
>> What makes cron and smtpd work well together is that they both perform
>> async background computing. And many cron messages are not "logs" they're
>> notifications of an event the cron is polling for, or submission of job
>> results.
>
> Honest, non-loaded question here. Do you really find them default cron
> output mode helpful? You suggested earlier that I dislike cron's e-mail
> output, and while I hadn't brought up likes or dislikes before, I really
> don't find it so great. To me, it just fills up my mailbox with:
>
>    Jul 02 Cron Daemon        Cron <root at hpc> ionice -c3 run-parts /etc/cro
>    Jul 02 Anacron            Anacron job 'cron.daily' on bigcomputer.home.
...
>    Jul 02 Cron Daemon        Cron <root at hpc> ionice -c3 run-parts /etc/cro
>
> If I did want e-mail output -- which I used to, before I had proper alerting
> set up, so as I mentioned before I totally recognize that use case -- I
> really would like it with a meaningful subject line, which means even when
> running out of cron, the jobs should actually call sendmail or /usr/bin/mail
> directly with pretty-formatted output. (And thus, have an explicit
> dependency on an MTA, and also basically have the expectation that they're
> running on a system which will be properly configured for its environment,
> however that happens.)

If you are getting a message from a cronjob, it is a pretty good
indicator that something went wrong, and you need to take action to
correct it.  So yes.  It's pretty important.    Depending on cronjobs
to send notifications on their own failures, is poor design because if
they have failed, they could easily fail to notify.  This is why
cron's (albeit ugly) notifications when a job turns up stdout/err, are
valuable.


On Mon, Jul 22, 2013 at 1:58 PM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> I do not
> think cron jobs that output something every time they are run just in case
> are nice.

I agree.  Those are usually, crappy cronjobs and should be fixed to
work like most unix tools, and output only on failure.

> I do not think the way we let systems install without a configured smtp
> backend is good. If cron mails were actually pushed by default the bad
> crons would be fixed before doing any real damage. A lot of the problems
> people complain of here are the direct product of not configuring the smtp
> backend a install time for years.

EXACTLY.  Improving the INSTALLER and firstlogin experience is what is
needed here, NOT removing MTA.

> I do not think the default cron message envelope is any good. It does not
> make enough effort to identify the system and cron job which is failing,
> and is not localized.

This is another area to improve.  Again NOT removing MTA, but using it smarter.

> I do think the only widely deployed vendor-agnostic remote messaging
> infrastructure is the mail infrastructure. All the other solutions require
> always-on receiving nodes, that end-users can not afford.
> https://admin.fedoraproject.org/mailman/listinfo/devel

Mail has its faults, but is the best option that is universally
available.  Let's build upon it rather than abandoning it.

i.e.: If message authentication is a concern, the system should sign
the messages before sending.


On Mon, Jul 22, 2013 at 2:00 PM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> If you argue from the viewpoint of how universially available an API is
> to make it "standard", then I would like to remind you that there are
> probably more Ubuntu installations in the world thatn Fedora
> installations, and they haven't included any MTA by default in 6 years
> or so.

Good to know.  I see not how that is relevant.  If anything, knowing
that only further demonstrates what a horrific idea No Default MTA is.


On Mon, Jul 22, 2013 at 2:15 PM, Nicolas Mailhot
<nicolas.mailhot at laposte.net> wrote:
> Le Lun 22 juillet 2013 20:52, Lennart Poettering a écrit :
>
>> This is not a valid argument. We cannot keep extending the core all the
>> time by adding more and more redundant components to them, just because
>> we believe this will cause APIs to be tested.
>
> No one is asking to extend the core. You are asking to redefine it that's
> not the same.
>
>> Also, what kind of a picture does this paint of the Fedora project
>> anyway? Only stuff we install by default matters and is tested?
>
> Not configuring what we install does not paint a good image of the
> project. OTOH, the MTAs themselves are several orders of magnitude more
> robust than all the other bits we install (including, right now, systemd).

I would love to see the day systemd is as polished, ubiquitous, and
robust as smtp.  But until that happens, nobody is helped by removing
MTA from the default install.  We're not there yet, and theres no
guarantee we ever will be.  Init systems come and go every few years.
Sendmail and MTAs in general have been around to witness them all.
SMTP has been around longer than Linux, and it will still be in use
when systemd is obsoleted by the next big thing.