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

Some proposals about the Email-subsystem, was Re: RFC: OpenLDAP and TLS/SSL



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



Reply to: