FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-13-2011, 09:04 AM
Reinhard Tartler
 
Default RFC: Making mail-transport-agent Priority: optional

On Do, Okt 13, 2011 at 00:41:43 (CEST), Bjørn Mork wrote:

> Josh Triplett <josh@joshtriplett.org> writes:
>
>> What would it take to make this change?
>
> Changing the LSB. Or you need to keep the sendmail interface. Which is
> what mail-transport-agent provides.

Why does LSB need to be fulfilled in 'standard'?


--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ehyh8dom.fsf@faui43f.informatik.uni-erlangen.de">http://lists.debian.org/87ehyh8dom.fsf@faui43f.informatik.uni-erlangen.de
 
Old 10-13-2011, 10:02 AM
Luca Capello
 
Default RFC: Making mail-transport-agent Priority: optional

Hi there!

On Thu, 13 Oct 2011 05:34:52 +0200, Josh Triplett wrote:
> Bjørn Mork wrote:
>> Josh Triplett <josh@joshtriplett.org> writes:
>>> Have I missed any important points?
>>
>> You forgot to explain the upside, reason, why, gain, whatever.
>
> Re-reading my original mail, you're right, I do seem to have missed
> covering that point explicitly. Thanks.
>
> The main reasons to stop having an MTA in standard:
>
> - Starting a daemon at boot time, which slows down booting. This led me
> to notice the problem in Debian Live: it took a non-trivial amount of
> time for the boot process to finish starting exim and move on.

I experienced the same in the past on non-live Debian systems, but IIRC
only when there was no network connection, is this a bug in exim?

> - Listening on ports by default, which exposes the system to any
> potential vulnerabilities, as well as potentially allowing the sending
> of spam. I've checked, and out of all the packages with priority
> standard or above, only exim and isc-dhcp-client listen on ports by
> default. Removing an MTA significantly reduces the attack surface of
> a default Debian system.

On a tasksel's "standard" squeeze, by default exim listens only to port
25 (both IPv4 and IPv6) and for local connections, so no external
connections are allowed:
=====
root@debian:~# debconf-show exim4-config
exim4/dc_other_hostnames: debian
exim4/dc_eximconfig_configtype: local delivery only; not on a network
exim4/no_config: true
exim4/hide_mailname:
exim4/dc_postmaster: rescue
exim4/dc_smarthost:
exim4/dc_relay_domains:
exim4/dc_relay_nets:
exim4/mailname: debian
exim4/dc_readhost:
exim4/use_split_config: false
exim4/exim4-config-title:
exim4/dc_localdelivery: mbox format in /var/mail/
exim4/dc_local_interfaces: 127.0.0.1 ; ::1
exim4/dc_minimaldns: false
root@debian:~#
=====

And BTW it seems you missed portmap and rpc.statd/nfs-common in your
list of packages with priority standard ;-)

FWIW, on a tasksel's "desktop" squeeze there is only one more daemon
listening by default: it is cupsd, again only for local connections.

> - Asking configuration questions via debconf at install time, which
> increases the amount of work and complexity required to install
> Debian.

Which "install time" are you referring to? During a squeeze
installation there are no questions asked about the MTA, either with
tasksel's "standard" or "graphical system" choices.

> For most users, these questions will duplicate the process
> they later go through to configure their MUA.

. o O (simply because these MUAs do not use the local sendmail)

> - Taking time to download and install, which increases the time and
> bandwidth needed to install or upgrade a Debian system.
>
> - Taking up space on disk, as with any other package installed but not used.

Actually, in a clean and up-to-date sid chroot I think ~9MB for
exim4-daemon-lightz2 or postfix (including dependencies) is way less
than other crap you get because of Recommends: on by default:
=====
(sid)root@gismo:/# apt-get install exim4-daemon-light
[...]
The following NEW packages will be installed:
adduser cron exim4-base exim4-config exim4-daemon-light libgcrypt11
libgnutls26 libgpg-error0 libp11-kit0 libpcre3 libtasn1-3 netbase
0 upgraded, 12 newly installed, 0 to remove and 0 not upgraded.
Need to get 3792 kB of archives.
After this operation, 8812 kB of additional disk space will be used.
Do you want to continue [Y/n]? n
Abort.

(sid)root@gismo:/# apt-get install postfix
[...]
The following NEW packages will be installed:
adduser libsasl2-2 libssl1.0.0 netbase openssl postfix ssl-cert
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.
Need to get 3710 kB of archives.
After this operation, 9055 kB of additional disk space will be used.
Do you want to continue [Y/n]? ^C
(sid)root@gismo:/#
=====

>>> Would any other packages need changes, other than the ones I've
>>> mentioned above?
>>
>> all packages with cron jobs,
>
> ...which produce output to somewhere other than a log file, in some
> scenario other than "being buggy and accidentally producing output", and
> which expect end users to read their output, and which therefore expect
> that the end user has configured root's mail to go somewhere they'll
> actually read. In any case, cron can still suggest an MTA, and any
> package which absolutely needs a working MTA can depend on one (and add
> giant warnings that they require a *working* MTA configuration, which a
> depends does not guarantee).

Please remember that the default MTA configuration works for *local*
delivery, so at least these emails from cron jobs are saved somewhere,
which is not the same WRT to logs, which at some point could be lost
(think about logrotate...).

>> all 3rd party applications assuming an UNIX
>> environment, ++
>
> By which you mean having a sendmail binary?
[...]
> And on top of all of that, nothing guarantees that the sendmail binary
> can actually send mail outside the local system. The admin will still
> need to know that the program they install wants to send mail with
> sendmail, so that they know not to say "local delivery only".

I think you are mixing two situations: local and external deliveries.
As I wrote just above, the former will work in any case by default (and
AFAIK is mandatory on a UNIX system), the second must be configured.

>> The reasons are all explained in the release notes.
>
> Which release notes do you mean? I don't see anything about exim or
> mail-transport-agent in the Debian squeeze release notes (other than the
> large table of various package versions in Debian, which includes
> notable packages of many different priorities).

The installation-guide explains the situation in the "§ 8.5. Setting Up
Your System To Use E-Mail" section:

<http://www.debian.org/releases/stable/amd64/ch08s05.html.en>

Thx, bye,
Gismo / Luca
 
Old 10-13-2011, 11:03 AM
"Bernhard R. Link"
 
Default RFC: Making mail-transport-agent Priority: optional

* Luca Capello <luca@pca.it> [111013 12:02]:
> > - Starting a daemon at boot time, which slows down booting. This led me
> > to notice the problem in Debian Live: it took a non-trivial amount of
> > time for the boot process to finish starting exim and move on.
>
> I experienced the same in the past on non-live Debian systems, but IIRC
> only when there was no network connection, is this a bug in exim?

I think that is trying to determine the hostname. Usually because of
exim4 supporting ipv6 and most hosts not having a statically configured
ipv6 address.

Adding

disable_ipv6 = true

to exim4.conf always made it go away for me...


Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013110331.GA11511@server.brlink.eu">http://lists.debian.org/20111013110331.GA11511@server.brlink.eu
 
Old 10-13-2011, 11:39 AM
Simon McVittie
 
Default RFC: Making mail-transport-agent Priority: optional

On Thu, 13 Oct 2011 at 10:17:38 +0200, Bernhard R. Link wrote:
> * Josh Triplett <josh@joshtriplett.org> [111013 05:51]:
> > Users can easily install an MTA; why do they need one *by default* on
> > every Debian system they install?
>
> Because the system is not in a useful state without. If you want to
> cripple your system, just deinstall it.

(TL;DR: I agree with Josh.)

My parents' Debian systems (a laptop and a desktop) are perfectly useful
without a local MTA - they use Thunderbird^WIcedove for email via IMAP and
authenticated SMTP. In some ways, this configuration is better than a
local MTA with a smarthost - the SMTP authentication authenticates the user,
not the machine (whereas a local MTA would have to either use a particular
person's credentials, or have credentials for a shared account named after
the machine, able to send but not receive mail).

For that matter, my mobile phone is loosely Debian-based (an N900 with Maemo)
and has no use for a MTA at all :-)

I realise there's no correct answer for everyone, but the sort of people who
need an MTA can easily install one (or get one installed via dependencies),
whereas the sort of people who don't need an MTA often don't know that they
don't need one, don't know that they have one, don't know how to get
rid of it, and don't know how to read any messages that it might have left
for them.

It seems to me that if we do need an MTA in standard it's for cron jobs and
similar system notifications, where Exim is overkill - esmtp-run or dma would
be quite sufficient. (I thought we also had an MTA that didn't speak SMTP at
all, and only delivered addresses without "@" locally via an MDA, but I can't
see such a thing in aptitude - either I'm misremembering, or it got removed.)

I'm not really convinced of the usefulness of a local mail spool to notify
non-server users about anything, though - a typical user of Icedove, KMail,
Evolution or whatever will never see things that get left in /var/spool/mail.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013113949.GB4082@reptile.pseudorandom.co.uk"> http://lists.debian.org/20111013113949.GB4082@reptile.pseudorandom.co.uk
 
Old 10-13-2011, 05:13 PM
Bob Proulx
 
Default RFC: Making mail-transport-agent Priority: optional

Luca Capello wrote:
> I disagree on that, according to popcon we have 19.27% of users has
> postfix installed, which could mean that ~90% of users has an MTA
> installed.

Doesn't popcon itself send reports by email? Meaning that 100% of all
reports from popcon have an MTA installed?

Bob
 
Old 10-13-2011, 05:59 PM
Wouter Verhelst
 
Default RFC: Making mail-transport-agent Priority: optional

On Thu, Oct 13, 2011 at 11:13:47AM -0600, Bob Proulx wrote:
> Luca Capello wrote:
> > I disagree on that, according to popcon we have 19.27% of users has
> > postfix installed, which could mean that ~90% of users has an MTA
> > installed.
>
> Doesn't popcon itself send reports by email? Meaning that 100% of all
> reports from popcon have an MTA installed?

No, popcon can also report through HTTP.

--
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013175905.GS4414@grep.be">http://lists.debian.org/20111013175905.GS4414@grep.be
 
Old 10-13-2011, 08:06 PM
Josh Triplett
 
Default RFC: Making mail-transport-agent Priority: optional

On Thu, Oct 13, 2011 at 12:02:11PM +0200, Luca Capello wrote:
> On Thu, 13 Oct 2011 05:34:52 +0200, Josh Triplett wrote:
> > Bjørn Mork wrote:
> >> Josh Triplett <josh@joshtriplett.org> writes:
> >>> Have I missed any important points?
> >>
> >> You forgot to explain the upside, reason, why, gain, whatever.
> >
> > Re-reading my original mail, you're right, I do seem to have missed
> > covering that point explicitly. Thanks.
> >
> > The main reasons to stop having an MTA in standard:
> >
> > - Starting a daemon at boot time, which slows down booting. This led me
> > to notice the problem in Debian Live: it took a non-trivial amount of
> > time for the boot process to finish starting exim and move on.
>
> I experienced the same in the past on non-live Debian systems, but IIRC
> only when there was no network connection, is this a bug in exim?

Possibly. The system I booted Debian Live on also had no network
connection. But either way, exim takes a non-zero amount of time to
start; sometimes it takes a significantly larger time, which makes the
issue worse. Either way it has a cost every time the system boots.

> > - Listening on ports by default, which exposes the system to any
> > potential vulnerabilities, as well as potentially allowing the sending
> > of spam. I've checked, and out of all the packages with priority
> > standard or above, only exim and isc-dhcp-client listen on ports by
> > default. Removing an MTA significantly reduces the attack surface of
> > a default Debian system.
>
> On a tasksel's "standard" squeeze, by default exim listens only to port
> 25 (both IPv4 and IPv6) and for local connections, so no external
> connections are allowed:

True, though that still potentially allows local escalation.

Also, if people blindly follow the recommendation of reconfiguring exim
to allow it to send external mail, they can end up with a system that
does support external connections.

> And BTW it seems you missed portmap and rpc.statd/nfs-common in your
> list of packages with priority standard ;-)

If I'd seen "portmap" in the list I would have recognized it as a
listening daemon, but it apparently changed names to "rpcbind", which I
didn't recognize. Also, I didn't realize nfs-common listened either.
Thanks.

> > - Asking configuration questions via debconf at install time, which
> > increases the amount of work and complexity required to install
> > Debian.
>
> Which "install time" are you referring to? During a squeeze
> installation there are no questions asked about the MTA, either with
> tasksel's "standard" or "graphical system" choices.

I stand corrected. I haven't allowed tasksel to install "standard" in
quite a while, due to exim and a few other packages. Glad to hear that
it at least doesn't ask questions anymore.

> > For most users, these questions will duplicate the process
> > they later go through to configure their MUA.
>
> . o O (simply because these MUAs do not use the local sendmail)

Few MUAs even have that option. And why should they, when they can talk
directly to the user's mail server rather than to a local MTA acting as
intermediary and passing mails to the user's mail server? More
importantly, MUAs assume (correctly) that most local MTAs don't
necessarily know how to send external mail, if they exist at all.

> > - Taking time to download and install, which increases the time and
> > bandwidth needed to install or upgrade a Debian system.
> >
> > - Taking up space on disk, as with any other package installed but not used.
>
> Actually, in a clean and up-to-date sid chroot I think ~9MB for
> exim4-daemon-lightz2 or postfix (including dependencies) is way less
> than other crap you get because of Recommends: on by default:

"other things are worse" is not an argument against dropping
exim4-daemon-light from standard.

> >>> Would any other packages need changes, other than the ones I've
> >>> mentioned above?
> >>
> >> all packages with cron jobs,
> >
> > ...which produce output to somewhere other than a log file, in some
> > scenario other than "being buggy and accidentally producing output", and
> > which expect end users to read their output, and which therefore expect
> > that the end user has configured root's mail to go somewhere they'll
> > actually read. In any case, cron can still suggest an MTA, and any
> > package which absolutely needs a working MTA can depend on one (and add
> > giant warnings that they require a *working* MTA configuration, which a
> > depends does not guarantee).
>
> Please remember that the default MTA configuration works for *local*
> delivery, so at least these emails from cron jobs are saved somewhere,
> which is not the same WRT to logs, which at some point could be lost
> (think about logrotate...).

That's a problem, not a feature. logrotate exists to make sure the disk
doesn't fill with logs; no such mechanism exists to make sure the disk
doesn't fill with mails. One of many reasons to log rather than sending
mail. And having two independent logging mechanisms seems suboptimal at
best.

Would you object less if cron had an option to log to syslog instead of
sending mail, and used that option automatically if it didn't find a
sendmail?

> >> all 3rd party applications assuming an UNIX
> >> environment, ++
> >
> > By which you mean having a sendmail binary?
> [...]
> > And on top of all of that, nothing guarantees that the sendmail binary
> > can actually send mail outside the local system. The admin will still
> > need to know that the program they install wants to send mail with
> > sendmail, so that they know not to say "local delivery only".
>
> I think you are mixing two situations: local and external deliveries.
> As I wrote just above, the former will work in any case by default (and
> AFAIK is mandatory on a UNIX system), the second must be configured.

Most third-party programs I've seen that use sendmail do so to send
external email. I haven't encountered third-party programs which want
local mail delivery, for which I'd expect them to do logging instead. I
can believe that such programs exist, but as far as I can tell the use
of sendmail for external email seems more common, and that case requires
configuration to work.

> >> The reasons are all explained in the release notes.
> >
> > Which release notes do you mean? I don't see anything about exim or
> > mail-transport-agent in the Debian squeeze release notes (other than the
> > large table of various package versions in Debian, which includes
> > notable packages of many different priorities).
>
> The installation-guide explains the situation in the "§ 8.5. Setting Up
> Your System To Use E-Mail" section:
>
> <http://www.debian.org/releases/stable/amd64/ch08s05.html.en>

Good to know. As far as I can tell, that only says that some programs
want to send local mail. I'd point out that of the programs mentioned
in the footnote, aide and logcheck both depend on a local MTA, so they
don't care if the MTA is standard. The quota package has quite a few
uses apart from sending warning emails, and it could easily enough
suggest an MTA and include a note saying "if you want to send quota
warnings by email, you'll need a local MTA" (wishlist bug filed); in any
case those quota warning mails seem unlikely to provide benefit unless
users on the system already have a local mail system from which they
actually read the mail.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013200648.GA15052@leaf">http://lists.debian.org/20111013200648.GA15052@leaf
 
Old 10-13-2011, 08:06 PM
Josh Triplett
 
Default RFC: Making mail-transport-agent Priority: optional

On Thu, Oct 13, 2011 at 12:02:11PM +0200, Luca Capello wrote:
> On Thu, 13 Oct 2011 05:34:52 +0200, Josh Triplett wrote:
> > Bjørn Mork wrote:
> >> Josh Triplett <josh@joshtriplett.org> writes:
> >>> Have I missed any important points?
> >>
> >> You forgot to explain the upside, reason, why, gain, whatever.
> >
> > Re-reading my original mail, you're right, I do seem to have missed
> > covering that point explicitly. Thanks.
> >
> > The main reasons to stop having an MTA in standard:
> >
> > - Starting a daemon at boot time, which slows down booting. This led me
> > to notice the problem in Debian Live: it took a non-trivial amount of
> > time for the boot process to finish starting exim and move on.
>
> I experienced the same in the past on non-live Debian systems, but IIRC
> only when there was no network connection, is this a bug in exim?

Possibly. The system I booted Debian Live on also had no network
connection. But either way, exim takes a non-zero amount of time to
start; sometimes it takes a significantly larger time, which makes the
issue worse. Either way it has a cost every time the system boots.

> > - Listening on ports by default, which exposes the system to any
> > potential vulnerabilities, as well as potentially allowing the sending
> > of spam. I've checked, and out of all the packages with priority
> > standard or above, only exim and isc-dhcp-client listen on ports by
> > default. Removing an MTA significantly reduces the attack surface of
> > a default Debian system.
>
> On a tasksel's "standard" squeeze, by default exim listens only to port
> 25 (both IPv4 and IPv6) and for local connections, so no external
> connections are allowed:

True, though that still potentially allows local escalation.

Also, if people blindly follow the recommendation of reconfiguring exim
to allow it to send external mail, they can end up with a system that
does support external connections.

> And BTW it seems you missed portmap and rpc.statd/nfs-common in your
> list of packages with priority standard ;-)

If I'd seen "portmap" in the list I would have recognized it as a
listening daemon, but it apparently changed names to "rpcbind", which I
didn't recognize. Also, I didn't realize nfs-common listened either.
Thanks.

> > - Asking configuration questions via debconf at install time, which
> > increases the amount of work and complexity required to install
> > Debian.
>
> Which "install time" are you referring to? During a squeeze
> installation there are no questions asked about the MTA, either with
> tasksel's "standard" or "graphical system" choices.

I stand corrected. I haven't allowed tasksel to install "standard" in
quite a while, due to exim and a few other packages. Glad to hear that
it at least doesn't ask questions anymore.

> > For most users, these questions will duplicate the process
> > they later go through to configure their MUA.
>
> . o O (simply because these MUAs do not use the local sendmail)

Few MUAs even have that option. And why should they, when they can talk
directly to the user's mail server rather than to a local MTA acting as
intermediary and passing mails to the user's mail server? More
importantly, MUAs assume (correctly) that most local MTAs don't
necessarily know how to send external mail, if they exist at all.

> > - Taking time to download and install, which increases the time and
> > bandwidth needed to install or upgrade a Debian system.
> >
> > - Taking up space on disk, as with any other package installed but not used.
>
> Actually, in a clean and up-to-date sid chroot I think ~9MB for
> exim4-daemon-lightz2 or postfix (including dependencies) is way less
> than other crap you get because of Recommends: on by default:

"other things are worse" is not an argument against dropping
exim4-daemon-light from standard.

> >>> Would any other packages need changes, other than the ones I've
> >>> mentioned above?
> >>
> >> all packages with cron jobs,
> >
> > ...which produce output to somewhere other than a log file, in some
> > scenario other than "being buggy and accidentally producing output", and
> > which expect end users to read their output, and which therefore expect
> > that the end user has configured root's mail to go somewhere they'll
> > actually read. In any case, cron can still suggest an MTA, and any
> > package which absolutely needs a working MTA can depend on one (and add
> > giant warnings that they require a *working* MTA configuration, which a
> > depends does not guarantee).
>
> Please remember that the default MTA configuration works for *local*
> delivery, so at least these emails from cron jobs are saved somewhere,
> which is not the same WRT to logs, which at some point could be lost
> (think about logrotate...).

That's a problem, not a feature. logrotate exists to make sure the disk
doesn't fill with logs; no such mechanism exists to make sure the disk
doesn't fill with mails. One of many reasons to log rather than sending
mail. And having two independent logging mechanisms seems suboptimal at
best.

Would you object less if cron had an option to log to syslog instead of
sending mail, and used that option automatically if it didn't find a
sendmail?

> >> all 3rd party applications assuming an UNIX
> >> environment, ++
> >
> > By which you mean having a sendmail binary?
> [...]
> > And on top of all of that, nothing guarantees that the sendmail binary
> > can actually send mail outside the local system. The admin will still
> > need to know that the program they install wants to send mail with
> > sendmail, so that they know not to say "local delivery only".
>
> I think you are mixing two situations: local and external deliveries.
> As I wrote just above, the former will work in any case by default (and
> AFAIK is mandatory on a UNIX system), the second must be configured.

Most third-party programs I've seen that use sendmail do so to send
external email. I haven't encountered third-party programs which want
local mail delivery, for which I'd expect them to do logging instead. I
can believe that such programs exist, but as far as I can tell the use
of sendmail for external email seems more common, and that case requires
configuration to work.

> >> The reasons are all explained in the release notes.
> >
> > Which release notes do you mean? I don't see anything about exim or
> > mail-transport-agent in the Debian squeeze release notes (other than the
> > large table of various package versions in Debian, which includes
> > notable packages of many different priorities).
>
> The installation-guide explains the situation in the "§ 8.5. Setting Up
> Your System To Use E-Mail" section:
>
> <http://www.debian.org/releases/stable/amd64/ch08s05.html.en>

Good to know. As far as I can tell, that only says that some programs
want to send local mail. I'd point out that of the programs mentioned
in the footnote, aide and logcheck both depend on a local MTA, so they
don't care if the MTA is standard. The quota package has quite a few
uses apart from sending warning emails, and it could easily enough
suggest an MTA and include a note saying "if you want to send quota
warnings by email, you'll need a local MTA" (wishlist bug filed); in any
case those quota warning mails seem unlikely to provide benefit unless
users on the system already have a local mail system from which they
actually read the mail.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013200648.GA15052@leaf">http://lists.debian.org/20111013200648.GA15052@leaf
 
Old 10-13-2011, 08:25 PM
Josh Triplett
 
Default RFC: Making mail-transport-agent Priority: optional

On Thu, Oct 13, 2011 at 10:17:38AM +0200, Bernhard R. Link wrote:
> * Josh Triplett <josh@joshtriplett.org> [111013 05:51]:
> > Users can easily install an MTA; why do they need one *by default* on
> > every Debian system they install?
>
> Because the system is not in a useful state without. If you want to
> cripple your system, just deinstall it.

I find my Debian system remarkably useful. "not in a useful state"
doesn't say much, except that you're rather attached to having a local
MTA. Perhaps you could provide a concrete reason why you want an MTA
installed *by default*? Again, a user can easily install one, and other
packages can depend on an MTA if they absolutely need one, or recommend
or suggest one if they would benefit from one; no different than any
other daemon.

> > The main reasons to stop having an MTA in standard:
> >
> > - Listening on ports by default, which exposes the system to any
> > potential vulnerabilities, as well as potentially allowing the sending
> > of spam. I've checked, and out of all the packages with priority
> > standard or above, only exim and isc-dhcp-client listen on ports by
> > default. Removing an MTA significantly reduces the attack surface of
> > a default Debian system.
>
> Last I checked, exim does not listen to things on the outside by
> default. (Though I had nothing against it no longer listening
> on tcp, as long as it still accepts mails)

It does indeed listen on localhost by default; however, that still
provides an avenue for local privilege escalation, via vulnerabilities
like DSA-2131-1. Also, Debian encourages users to reconfigure exim so
that it supports sending non-local mail, and that reconfiguration can
end up with exim listening for outside connections.

> > - Asking configuration questions via debconf at install time, which
> > increases the amount of work and complexity required to install
> > Debian. For most users, these questions will duplicate the process
> > they later go through to configure their MUA.
>
> People have different needs here. There really is no "one size fits
> all". Your whole argument of not wanting one being started at most
> means there is one option missing.

Luca Capello just informed me that exim thankfully no longer asks
configuration questions at install time, so feel free to ignore this
point.

> > - Taking time to download and install, which increases the time and
> > bandwidth needed to install or upgrade a Debian system.
>
> Please drop the "upgrade". If you deinstall it there is no cost at
> upgrading.
>
> > - Running a daemon all the time, which takes up RAM.
>
> Then do not start it.
>
> > - Taking up space on disk, as with any other package installed but not used.
>
> Then deinstall it.
>
> > - Taking up space in the process listing; the more programs a system
> > runs that it doesn't use, the longer it takes to look over the output
> > of "ps auxf" or top.
>
> Then do not start it.
>
> > - Similarly, taking up space in the list of installed packages, the
> > apt-listchanges output, and so on. Any package installed but not used
> > incurs a small but non-zero amount of mental overhead.
>
> Then deinstall it.

Every point you just stated applies equally well to every daemon we
don't install by default; you haven't given any reason why an MTA needs
to exist by default.

> Please note that an MTA perfectly fits into the
> 'If the expectation is that an experienced Unix person who found it
> missing would say "What on earth is going on, where is foo?", it must
> be an important package.' criterion. So only having priority standard
> is already a compromise (and I guess historically due to there being
> alternative implementations).

Given the prevalence of LAMP, quite a few people might say "What on
earth is going on, where is mysql?". They then promptly install it,
without inflicting it on people by default.

More seriously, "what on earth is going on, where is foo?" applies quite
well to things like ps, a pager, an editor, and many other things
hard-wired into people's command-line finger memory. Why does an MTA
fall in that category? Remembering the good old days of multiuser
systems with vibrant local mail conversations will not bring them back.
Local mail exists primarily for historical reasons and inertia, and we
can fix the former. Your mail demonstrates rather a lot of the latter.

> I'm all for having minimal dependencies to make deinstalling stuff one
> does not like or want easier. But defaults should be something
> reasonable.

Since we clearly disagree about what "reasonable" means, let's stick to
more concrete points.

- Josh Triplett


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111013202551.GB15052@leaf">http://lists.debian.org/20111013202551.GB15052@leaf
 
Old 10-13-2011, 08:34 PM
Bob Proulx
 
Default RFC: Making mail-transport-agent Priority: optional

Wouter Verhelst wrote:
> Bob Proulx wrote:
> > Doesn't popcon itself send reports by email? Meaning that 100% of all
> > reports from popcon have an MTA installed?
>
> No, popcon can also report through HTTP.

Ah... Very good. I stand corrected. And what's more, looking it
over it appears that using http is now the default.[1]

Thanks!
Bob

[1] In the /usr/share/doc/popularity-contest/FAQ.gz file:

Q) How can I prevent popularity-contest from sending reports via email?

A) This is not recommended. Reports are sent by email only when the HTTP
submission fails, which is generally caused by a temporary lack of internet
connectivity. By contrast, reports sent by email are stored in the mail server
queue until the internet connectivity is back.
 

Thread Tools




All times are GMT. The time now is 10:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org