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 difficult. - 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* smarthost. 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111012213912.GB1964@leaf
