Re: RFC: Making mail-transport-agent Priority: optional
Steve Langasek wrote:
> On Wed, Oct 12, 2011 at 08:34:52PM -0700, Josh Triplett wrote:
> > 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.
>
> Does Debian Live use insserv with parallel booting? Granted, I/O is the
> bottleneck for booting from CD, so there's still going to be some impact;
> but on my systems (which all use postfix - so you can count me among the 20%
> of popcon users who have uninstalled exim to install postfix), MTA startup
> time is pretty small - on the order of 1.5s according to my bootcharts,
> which is hardly anything on the systems in question.
As far as I know, it uses insserv; I don't know if it uses parallel
booting or not. I suspect it uses the default configuration, which
means it uses parallel booting. However, even with parallel booting,
the login prompt does not become available until all the init scripts
finish. exim4 took several seconds to start, and the login prompt did
not appear until it finished.
I was booting from a USB disk, and not a particularly fast one, which
may have contributed to how long exim took. I can say that it took a
nontrivial fraction of the total boot time.
On the flipside, getting to the point where the system only takes a
couple of seconds to boot means eliminating everything unnecessary.
> > - 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.
>
> Running an MTA does not imply accepting mail from outside the machine for
> delivery. We could address this by configuring our standard MTA to only
> accept from localhost by default, or to only accept submissions via
> /usr/sbin/sendmail by default.
If the MTA didn't listen on any ports by default (localhost or
otherwise), only accepted submissions via sendmail, and didn't run a
daemon, then I'd care a lot less about getting it out of standard.
> > - 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.
>
> That's absolutely a bug in the MUAs for requiring additional configuration
> instead of working with the default.
I've already found out via this thread that exim4 now defaults to
local-only delivery, and asks no questions at startup, 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.
>
> I think you're reaching with this one.
The primary bottleneck when installing Debian consists of waiting for a
large number of packages to download and install. Making that process
take less time, multiplied across the huge number of people installing
Debian, seems worth it. This holds particularly true for slower
Internet connections.
> > - Running a daemon all the time, which takes up RAM.
>
> You're worried about this on a desktop system running firefox?
So we should make it that much worse for everyone? Every bit of RAM
used by a program represents that much less disk cache. Plenty of
people work on making Firefox and other programs use less RAM; let's not
contribute to the problem.
Also, exim4, as a daemon that doesn't wake up often, is a pretty
good candidate for swapping out, which makes for that much more of a
performance hit when it needs to swap back in.
(Oh, and one reason I forgot: waking up periodically also makes systems
use marginally more power.)
> Your proposed benefits become more outlandish from there, so <snip>
I listed every reason I could think of here, rather than pruning at the
point where I felt it already far outweighed the cost of requiring mail
server administrators to type one command to install a mail server.
- Josh Triplett
Reply to: