Let's write a system admin friendly mail server packaging system
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear everyone,
1/ Briefly, who am I
====================
My first Debian package was for the web hosting control panel (a web
interface) that my company released in open source. I'm the main
programmer of it.
The first time I tried to have it enter in Debian, it created a huge
controversy, with (I heard) a 70 post thread in -private after it got
sponsored. The reason was that my package goal is to have an
over-simplified system, so that the user of it doesn't have to touch
anything to the system configuration, everything has to be automated
(which is the goal of my app).
In Debian, by policy, a package cannot touch another package's
configuration file. While I believe this policy is a good one, but it
prevented me from having my postinst to do a successful setup without
breaking the policy. The result is that what should have been sent to
the postinst of my package has then been sent to a userland script (with
often, users not starting the script an complaining about it in my
forum). It doesn't make this script less ugly if running in userland
rather than in the maintainer scripts (it is REALLY an ugly script, and
I'm quite not proud of it), but at least it respects the policy.
As I am soon to become a Debian Developer (if the DAM accepts me, after
my AM wrote his report), I believe it is now time to get even more
involved in Debian, and try to solve that issue once and for all. Even
if for a reason or another, I'm rejected (which I don't think will
happen), I still want to start the below discussion.
2/ The problematic
==================
What happens here is that, if you take a normal Debian system, then
install postfix, then let's say amavis, they don't talk to each other.
In the same way, if you add dkimproxy (that I maintain), or clamsmtp, or
tumgreyspf (that I maintain as well), you end up with a system that is
not configured at all. None of these mail server components are aware of
each other, and a system administrator has to spend a great deal of time
to make it work.
Truth is, in today's world, it is totally unrealistic to believe that
just postfix is enough for setting up a mail system. There's just too
much spams. It is also totally unrealistic to say that it's up to the
system administrator to configure everything by hand. If, like me, you
do at least one setup a day, it takes too much time for no reason, and
it has to be automated in some way.
There's loads of howtos available in many places that describe in 10
pages or more how to have a successful setup. This is really a pain.
This is the reason why I'm writing this today: I want to (with the help
of other maintainer of the concerned packages, if they agree) change
that fact.
3/ Goal description
===================
In the ideal world, a command like this:
apt-get install postfix-mysql clamav clamav-daemon clamav-freshclam
spamassassin tumgreyspf
would create a mail toaster with postfix and all the above apps
configured correctly so that the mail system would do like this:
1- postfix gets a mail, does some basic domain checkings (domain MX
existance, etc.)
2- postfix asks tumgreyspf to check for SPF and greylisting
3- (see later)
4- postfix forwards the email to amavis
5- amavis does clamav and spamassassin checks with header tagging
6- amavis forwards the email to postfix
7- postfix sends the email to maildrop for delivery
Let's say now that I add dkimproxy, I would do:
apt-get install dkimproxy
and then the sequence would become:
3- postfix sends the email to dkimproxy for DKIM signature checkings
4- dkimproxy forwards the email to amavis
I don't see any reason why it shouldn't be as easy to use as what I
wrote above. The complexity of this kind of setup MUST be done on our
side, and not rely on the system administrator knowledge.
The above is what we currently use, but of course, this could be
extended to DSPAM (I read it's better than spamassassin), clamsmtp, some
milter checks, some alternative MDA, etc. And of course, this could be
extended as well to other mail servers (exim4 anyone?).
That's for the problematic. Now, how to achieve this, I'm not sure how
to do it yet, but I have couples of ideas.
4/ Few ideas, and what I believe should happen
==============================================
First thing we could do, would be a special postfix package that would
have the above packages as dependency. Let's say we call it
postfix-toaster, and it would have the configuration already made so
that it would be already configured for using other packages. But that's
not really idealistic, because of so many possibilities that we have.
The second idea would be to have some kind of triggers, a bit like we
have for generating the mandb and others. The trigger would ask the MTA
scripts to do the reconfiguration process, for example, giving it as
argument a list of packages that it should use. But the MTA is not the
only one to modify here, for example we might have to change the listen
and relay port of dkimproxy and amavis, depending if each others are
present on the system or not. I am quite in the favor of this system,
but it means that we should involve everyone. But I'm not sure how this
should be implemented in order to avoid the ugliness of a >5000 lines sh
script that I currently maintain.
Also, as this might be annoying for some system admins in some case, we
could have this set as an optional feature (disabled by default?), that
would be selected through debconf.
5/ Who should get involved
==========================
I want to insist here, that what I'm proposing can only happen if
everyone is willing to participate. The first thing we should do, is
gather a list of package that should talk to each other for the
reconfiguration system. Here's the list I have for the moment:
dpam, dkimproxy, spamassassin, amavis, clamsmtp, clamav, cyrus-sasl,
cyrus, postfix, qmail, courier (many packages), (courier-)maildrop,
exim, sendmail, spfmilter, spamass-milter, milter-greylist, dk-filter,
greylistd, bogofilter, citadel-mta, dovecot, qmail, .
These are what I have identify with few apt-cache search, and my own
knowledge, but there MUST be some more. Is there an easy way to list
them all? And to list maintainers?
6/ Call for help and open discussion
====================================
That's about it for my thoughts, I'm now calling for ideas of others.
Please, reply to this thread in -devel if you are maintaining a mail
server package, at least to tell that you are there, and willing to
implement whatever will come out of this discussion that I wish to be
open to as many ideas as possible... and fun! (Debian should be fun! :)
Thomas
P.S: Should I send this through another list than -devel as well? Maybe
Cc: all the above package maintainers? I'm not sure here... The
maintainer of postfix, LaMont Jones <lamont@debian.org> is as Cc:,
because postfix is the most important one to tweak here, I believe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkv9HiQACgkQl4M9yZjvmknQYQCg7lOJe4Wftfmp2gfCv1PZyvK8
ACUAoNnhGB4/RvBrqKuxn3+3NH0rsmiC
=euXY
-----END PGP SIGNATURE-----
Reply to: