Re: default MTA
On 28 May 2013 19:10, Matthias Klumpp <matthias@tenstral.net> wrote:
> Would it help if we had a desktop-component, which is able to:
> 1) Show a notification *on the desktop* if the user received new mail
> 2) Offer a GUI way to read system mails
> 3) Offer a way to delete these mails
Instead of adding *another* desktop component. Wouldn't it be better
to have the "standard" desktop e-mail reader [0] configured to read
local e-mail from the start?
Since the e-mail reader would be already nicely integrated into the
Desktop it already provides 1, 2 and 3.
> The advantage would be that these mails would be read more often,
> while on a system configured for desktop-use, no such mails would be
> send, so the users wouldn't be bothered with it.
I agree that we need to expose local e-mail more. Even end-users might
install some tools and will not receive any notification from them
unless they have their desktop e-mail client configured to read local
e-mail.
Take for example, smartmoontools [1]. Currently, if an end-user
installs smartmoontools and a hard-disk fails (i.e. smartd detects a
problem with one HD) he will *not* see any notification: the failure
is sent through local e-mail.
Regards
Javier
[0] Is there such a thing? ;-)
[1] I'm picking this package since it is installed by ~24% of the
systems reporting to popcon. Which, on a quick review, seems to be
higher than other tools using cron and reporting through e-mail.
The popcon stats do not tell me whether the systems with, e.g. gnome,
installed have also smartmoontools installed, but let's make the
assumption that some do :)
Reply to: