El jue, 22-08-2002 a las 12:47, Roland Bauerschmidt escribió: ... > How about moving postfix to priority important and exim to optional? :) > LDAP support in postfix is already split off into a separate package. ...
I planned to start an elaborate proposal for the mailing-subsystem, however real-live has it busy on my and it will have to wait a while to polish it. However, hooked on Rolands remark and Bdale's anouncment of a policy rewrite at least I want to throw it in in quality of short remarks: - Opcional MTA's: Not every system uses an MTA, in fact a wealth of end-user PC's (the mayority) would be just fine with local delivery, and eventually utilities to fetch mail from a remote box, and pipe a queue of messages to a remote server. On the other hand there are various popular alternatives for MTA's so a general choice in a lot of cases fails. Proposal: By default no MTA will be installed. - Configurable Local Delivery: The default mail delivery method is to a unix-style mbox in /var/mail/<user>. MH-, and even more, Maildir-delivery are often chosen as an alternative (Maildir is of my interest here). Almost all MTA's and MUA's can nowadays deal with them, however reconfiguration of the Mail system is painful. Proposal: At some point in the installation process a choice of the default delivery method can be made. The choice is recorded e.g. in /etc/defaults/maildelivery Al MTA's and MUA's take into account the systems mail delivery method upon post-installation and configure themselves acordingly, or give a warning if it is not supported. ---------------------------------- This two proposals are of high priority in my opinion, now some proposals which have their "issues" in one or the other way: - MUA Configuration: Good old plain-text MUA's almost always support tilde- or environment variable-expansion, and hence allow to elaborate global- or pre-made user-configuration files (in /etc/skel), which contain references relative to the user's home directory. In "modern" MUA's like Balsa, and Evolution (correct me if I'm right) absolute path's have to be given in the configuration, requiring a manual setup of the mail system for every single user. Proposal: MUA's in Debian should be patched, or upstream be bothered to do so, so that they allow tilde and/or environment variable expansion in the respective configuration files or databases. MUA's which don't support this features should have a corresponding note in README.Debian and eventually a popup (with low priority) at pre-configuration. - Qmail Interoperability: Qmail installations grow fast and a lot of Debian Users choose it as their MTA. There are source packages *in* Debian, and there are License compatible binary packages on the net, however they can not be part of the Debian Distribution because of conflicts with Debian Policy (binary re-distribution is restricted, in short: no modifications to author's version allowed). Qmail's security concept requires seven different unix accounts and two groups to be created. Qmail - mailqueues on two systems where the uid's of these users are different are incompatible - an issue when migrating, re-installing and with distributed servers with nfs-mounted spools. Proposal: Fixed assigned Qmail-users uid's/gid's. - Mailservice-switch: The current Internet Mail System is giving increasingly trouble by inherent problems. Alternatives exist (qmtp) and are developed (im2000, as well as others) and in the future a System Administrator (or user) may want to change the way messages are sent and received in it's system. Also, the actual way of installing an alternative MTA on a Debian system is "take it or leave it" - there is only one MTA installed at one time and it has to be removed to install an alternative. An "alternatives" system could be provided by Debian, that reduces the MTA's installation/configuration responsabilities from "conflicting" to cooperating, by dropping sendmail compatiblity on a package level and introducing it on a global configuration level. This can be done in a homebrew-fashion with alternatives, or taking into account the /etc/mta/ configuration switch proposal found at http://cr.yp.to/etc-mta.html (of course adapted to FHS ;->) Proposal: MTA's provide a set of generic, sendmail-compatible executables in /usr/lib/<MTA>/ either as binaries or as symlinks The actual chosen MTA will be selected by an "alternatives" like method. ------------------------------------------------- Best Regards, Jorge-León
