[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: Making mail-transport-agent Priority: optional

I recently booted up a Debian Live "standard" image on a test system,
and noticed that it included a running instance of exim.  Curious why a
live system would need an MTA, I found Debian Live's policy that the
"standard" image contains everything installed as part of a standard
Debian system (and similarly, the desktop images include everything
installed by the corresponding tasks or metapackages).  This seems like
a sensible policy, but it reminded me again that Debian still has an MTA
in standard.  I'd like to change that.

Not every system needs an MTA, and I'd argue that today most systems
don't.  End-user systems (desktops, laptops) typically handle mail via
one or more smarthosts elsewhere, driven by MUAs that know how to talk
SMTP.  Other tools which send mail have learned to send SMTP as well,
and tools that cannot still have the option of recommending or depending
on an MTA without needing one in standard.  And many servers don't need
an MTA either, unless they run programs which need to send mail by
calling sendmail.

I realize that some people use a personal mail configuration which
involves a local MTA, even on a laptop or desktop.  However, this
represents a less common configuration, and one which requires somewhat
more difficulty for a single user to set up than the configuration of a
MUA (given that they normally need to do the latter as well).  It also
introduces an extra layer end-users would have to monitor to ensure that
mail gets sent, even when their MUA says "sent"; MUAs don't know how to
do that monitoring themselves.  I don't think having an MTA in priority
standard makes such a setup any easier for the people who want it; we
have a marvellous packaging system that makes it easy for users to
install the numerous packages they want above-and-beyond standard to
reach a system with everything they expect, and I doubt many users who
use a local MTA will otherwise remain entirely satisfied by the contents
of standard with no other additions.

I also understand that many developers have an attachment to having a
properly configured local MTA.  Debian has had an MTA in standard for a
long time, and people feel that MTA ought to actually know how to send
email.  Traditional UNIX multiuser systems had a local MTA, and I enjoy
thinking of the days when people regularly sent email to addresses
without an '@' in them.  I've certainly observed a certain level of "fix
your MTA" in response to users who rely on smarthosts instead.  However,
I think we need to consider how our users actually *use* their systems
today, and I don't think most of our users really want or need a local
MTA on their systems by default.

Popcon shows that ~65-70% of Debian systems have exim4 installed.  How
many of those users really use a local MTA, and how many just have a
forlorn MTA checking an empty queue for mail that will never appear?
30-35% of users cared enough to remove exim, and another 7% or so seem to
have configured their systems to stop running it (at boot or otherwise)
without actually removing it.  How many more just don't notice one more
process starting at boot time, and don't bother removing it even though
they'll never use it?

I checked into what packages we have with priority >= standard that want
an MTA.  Turns out that only bsd-mailx (also standard) has a Depends on
an MTA, but bsd-mailx seems exactly as "standard" as an MTA in the first
place; if you don't have one you don't need the other.  (And from what I
can tell, most scripts which want to send mail use sendmail directly,
not mail; either way, someone can always install bsd-mailx if they need
a "mail" command.)  People do sometimes use mail/mailx as a personal
MUA, but installing bsd-mailx seems just as easy as installing the
numerous MUAs in optional, and I don't think anyone will argue that more
people use mailx than one of the more user-friendly MUAs. :)  I'd
propose moving bsd-mailx to priority optional as well.

The following 6 packages with priority >= standard have a Recommends on
an MTA:

- apt-listchanges, which has the option of mailing changelogs or news to
  root.  However, apt-listchanges can just as easily display those
  changes at install time, and many end-users will never see mail sent
  to root or any other local user.  Perhaps apt-listchanges should just
  Suggests an MTA.

- procmail: Normally only needed if you actually process mail locally on
  a system using more than just a MUA; also, procmail has an alternative
  recommends on fetchmail, and will work easily enough with any other
  means of getting mail on a system.  Easily installed by anyone using
  it.  (May want to move to optional as well, by the same arguments,
  since it primarily goes with an MTA-based mail setup.)

- cron and at, which really want to send mail rather than just logging.
  The output of these can potentially prove useful, but only if it goes
  somewhere that will actually get read.  Many end-users will never see
  mail sent to root or any other local user.  We don't currently help
  users forward mail for root off to an email address they'll actually
  read, so they'll only see if it they know to configure forwarding
  themselves, or they run a MUA which looks at the local mail store,
  which most MUAs don't.  I've personally run cron for years without an
  MTA; the few times I've written a cron job whose output I cared about,
  I piped its output to logger or otherwise captured it in a logfile.
  Anyone counting on cron to send them mail for their own cron jobs need
  only fire up apt and install an MTA, which does not seem particularly

- mutt, which also knows how to speak SMTP, POP, and IMAP.  Seems like
  mutt should just Suggests an MTA.

A couple other packages in standard and above which might care:

- bsdmainutils contains "calendar", as well as a disabled-by-default
  daily cronjob to mail users about events on their calendar.  Anyone
  enabling that cronjob and using calendar can always install an MTA.
  Perhaps bsdmainutils should suggest an MTA.

- reportbug suggests an MTA.  However, reportbug knows how to speak
  SMTP, and it has a very sensible default configuration using
  reportbug.debian.org, which works without either a local MTA *or*

Regarding people seeing local mail, Joey Hess wrote:
> there are three types of systems: 1. local mail is read, active admin
> (a DD's own box). 2. local mail is forward, active remote admin (a
> DD's family or work box) 3. everybody else
> and 1 and 2 need knowledgeable people for whom apt-get install postfix
> is not exactly hard while they're editing the aliases file, QED

Based on all of the above, I'd like to propose the following changes:

- Change exim4-daemon-light, bsd-mailx, and possibly procmail to
  Priority: optional.
- Change apt-listchanges, mutt, cron, and at to Suggests: default-mta |
  mail-transport-agent, rather than the current Recommends.  (In
  addition to reflecting the concerns above, this change also needs to
  happen to avoid pulling in an MTA by default anyway via the Recommends
  of standard packages.)

What would it take to make this change?  Have I missed any important
points?  Would any other packages need changes, other than the ones I've
mentioned above?

I will happily work to coordinate this transition.

- Josh Triplett

Reply to: