Fedora keeps sendmail — for now

I find it very telling that nobody has even mentioned mailing other users of the machine as the use case of local sendmail. The boat of local email delivery has sailed and reached it's destination at the harbour of UNIX museum. If the only remaining use of sendmail is to deliver notifications, I don't see why it should be treated different from nagios.

(To avoid the obvious arguments: yes, there are plenty of cases where you can guarantee that there's an installed MTA that will deliver mail to a user who will read it. But all of those cases involve manual configuration, and so adding "install an MTA" to the list of steps required isn't a huge imposition)

I'm not sure what you mean by your first point, though; what does an MTA queue have to do with keeping your mail client open to *check* email?

Pretty much every mail client already speaks SMTP and doesn't use /usr/sbin/sendmail and it has been that way for decades, they will also hold mail in an Outbox so aren't reliant on the local MTA for queueing. This is not just GUI clients like Evolution, KMail or Thunderbird but also PINE and mutt speak SMTP. Only crazy people are still using mailx as their day-to-day MUA 8-)

Also, local delivery to /var/lib/mail is bad for the default system because only a few utilities like mailx still can read from there, and most messages are destined to users who don't interactively log in at all. Those messages disappear down a black hole and we would all be better served if they went to syslog by default. Of course if you want cron mail, install ssmtp and configure it to go to your central mail hub.

This isn't to say that /usr/sbin/sendmail isn't an API for scripts and programs to send mail, but that is a small case which doesn't _require_ a full MTA such as sendmail or postfix, a small shim like ssmtp is more appropriate, and should be listed as a dependency for programs which require it.

I never suggested that my preferences applied universally. I stated what applied to my own system. Nothing stops people from installing and configuring an MTA on their system if that's their preferred way of handling email. I don't, however, believe that's the right default for end-user client systems, because most users will either use webmail or configure a MUA to talk directly to their real mailserver; thus, I'd argue that when installing such systems, distros should not install an MTA by default.

> queuing is still important if your network link is down, or the recipient's MTA is busy/over-loaded/greylisting or just offline for whatever reason.

My MUA does talk to a proper queuing MTA (via SMTPS) for exactly that reason; that MTA just doesn't live on my laptop. MUAs certainly shouldn't talk directly to recipient MTAs, nor would I advocate the elimination of MTAs in general; I'd simply suggest that the majority of systems want to talk to a mail server elsewhere rather than running one locally.

> it's merely crazy to think that every app that might need to send mail should speak smtp (and possibly several other protocols),

A MUA just needs to speak SMTP(S) to send mail, no other protocol. And that's no crazier than expecting every app to fork and exec sendmail to send mail; it's just different.

Any app other than the user's a MUA that wants to send mail on behalf of the user can invoke the user's MUA to do so. See https://lwn.net/Articles/562141/ , in particular the discussion about evolution as a desktop service, for some discussion of that approach.

That also fixes a major bug present when apps think they can just chat with sendmail to send mail: making sure that every outgoing mail ends up in the Sent folder in the user's MUA.

> but it's gibberingly insane to think they should maintain their own queue, routing table, and delivery scheduler.

Of course not. A MUA should not be queuing and scheduling mail; at most, a MUA might have an outbox of mail it couldn't send to the user's MTA due to being offline, and it can retry sending that mail when online again. That's not a complicated policy.

I bet that at least 90% of users have to use some form of authenticated submission to send mail these days.

A very reasonable point, but you've got it flipped around. If the user wants to run a mail client, the mail client is the thing to configure. And given the choice of configuring the mail client to talk to the user's mail server via SMTP, or configuring a local mail server to use the user's mail server and configuring the mail client to talk to that local mail server, the former ends up with far less configuration.

On top of that, with the former setup, when the user's mail client says a mail is sent, it's *actually sent*, rather than potentially sitting in a mail queue on the user's system where it might get lost without the user knowing. Not every user wants to be a mail server admin.

>> Meanwhile, mail applications still need to know how to speak
>> various mail protocols because individual user requirements
>> don't necessarily match the global system configuration

> first you argue that the MTA might not be configured correctly, and then you say that it's OK for it to be misconfigured

You've entirely missed the point of the statement you replied to. There may not be *any* valid system configuration for an MTA. The smarthost each user uses for their own mail is not necessarily suitable for use in the system configuration, either because the user may not want the system sending automated mail as them, or because the user doesn't want to store the credentials for their mail account systemwide. That's not a misconfigured MTA, that's a system where all the user's have their own mail server already and it doesn't live on the local system. If you want to argue that a user's *session* should include something similar to an MTA, that's an interesting idea, but that doesn't mean a systemwide MTA makes sense on systems that aren't the mail server for a given domain.

What you're missing is that, even though Fedora currently installs sendmail by default, Fedora doesn't configure it by default. The same is true of many other Linux distributions. A client has no way to figure out whether sendmail will actually deliver remote mail or not, and nor does it have any way to report that to the user.

So sure, you can assert that /usr/bin/sendmail should always be configured in such a way that it will deliver mail to remote users. That doesn't make it true, and when writing software it makes more sense to conform to reality than to some platonic ideal.

(does the Debian installer even configure exim by default these days? My understanding was that it doesn't)

"do you even know what a unix system is? or why the small-tools approach has worked so well for decades?"

I've been a professional admin on Linux, Tru64 and (for my sins) Irix, and I've got an actual SVR4 box around here somewhere, so yeah, I've got some experience of that. But you seem to have misconstrued my argument. Would the world be a better place if all clients used a single implementation of SMTP? Yes, I think it would. Does that mean that the single implementation of SMTP should be a globally configured daemon? No. The argument that all mail should be sent via /usr/bin/sendmail is equivalent to arguing that all browsers should be hardcoded to talking to a machine-local proxy.

"then don't. there's - slight exaggeration - a million ways for you to address your special needs that don't involve crippling distros by default."

So, first, point me at a distribution that *by default* guarantees that /usr/bin/sendmail will be (a) present and (b) correctly configured. And then describe three of those ways.