Re: 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
Reply to: