Matthew Garrett wrote:
I'm pretty solidly of the opinion that email is nowhere near being the
most sensible way to get important information to a typical desktop
user. If a failure is important then the user needs to know about it as
soon as possible - mail provides no guarantees about timely delivery. We
have plenty of desktop infrastructure to give important alerts to users,
we're just failing to do so.
If local delivery of mail fails, there's no reason to think any other
notification method would have succeeded. The important point is that
the user may not be present when the event occurs, and that desktop
infrastructure may not even be running - and even if it is, the
interested party may want the notification to be forwarded elsewhere.
Local delivery of mail is a poor solution, since it provides no
indication of priority difference between "You've got spam" and "Your
hard drive is failing".
That's a solvable problem within the context of email, whereas starting
from scratch and re-inventing delivery to arbitrary user-selectable
endpoints is somewhat insane.
If there's nobody to present it to, it can be
queued and presented at login - if the user is running on their system
but doesn't have the desktop infrastructure running, then by definition
they're already outside the standard desktop usecase.
Does that mean their system should die with no attempt at notification?
Or that desktop administration should be confusingly different than
standard systems?
I'm not arguing about the utility of an MTA for various situations. I'm
arguing that for one specific and very common situation, using an MTA to
deliver system alerts is a poor way of handling it. We should fix that.
No, you should fix it so mail delivery is useful.
As a happy side effect, it removes the need for a default MTA in the
desktop install.
Unless, of course, you care to follow standards.
People who want an MTA then get to choose whichever MTA
they want and net human happiness is increased.
That has been the case for some time already. As long as the
alternative presents a command-line compatible /usr/sbin/sendmail,
standard programs will work.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
