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

Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian



Package: tech-ctte
Severity: normal

Dear Technical committee,

the ftpteam has been thinking about the inclusion of QMail into Debian
for some time already. We feel that qmail, unless heavily patched, is
not a suitable MTA at this time and age. It is plagued by numerous bugs
(or misbehaviours, some might consider them features) and as such, in
our opinion, falls into the category of "so buggy that it is not
supportable", which is not for Debian main (Policy 2.2.1). Also, afawk,
there is no real current Upstream.

For this reason we, the ftpteam, think that QMail is not suited for inclusion
into Debian main.

Yet, we do see that there are people who want Qmail, and instead of
maintaining it in an own repository want it in Debian. As it is unlikely
that the positions of the Qmail supporters and us will change soon to
let us find a solution that works for both sides (the positions are
basically black and white here), we ask you to help resolve it,
by a ruling on this matter, following Constitution §6.1.3.


Criteria for inclusion that qmail meets:
- active maintainer (Gerrit Pape)

- security team willing to support it [1]

- license DFSG compatible


Criteria that speak against inclusion:
- no real upstream

- several shortcomings related to the MTA behaviour, including the
  backscatter spam issue, failing to use secondary MXs, ignoring
  RFC1894, and unbundling of outgoing messages (yay for traffic/resource
  waste)[2], thus being unsupportably buggy (Policy 2.2.1)

- we do have many other, way more modern and better supported,
  MTAs available.

- still, in the reupload after the initial reject[3], seems to violate
  Policy (11.6), for example by not being able to handle etc/aliases
  files as required. Needs yet another package for this.
  Here qmail-run is the MTA provider, yet it doesn't follow the must in
  policy saying "All MTA packages must come with a newaliases program".
  Instead it has a recommends on fastforward, which then provides it.

- Still seems to violate the FHS. /var/lib/qmail/queue belongs into
  /var/spool, as far as we can tell.

- Lots of symlinks in /var/lib/qmail/bin going to /usr/bin/ and/or
  /usr/sbin. This is at least sick, if not again an FHS
  violation. var/lib is for "Variable state information", not binaries
  or links to them.

- qmail-uid-gid is creating users/gids with hardcoded ids in the
  60000-64999 range. While thats allowed from policy, stating "Globally
  allocated by the Debian project, but only created on demand.", wth is
  this global registry, and is qmail registered there?
  Also seems very much 18 century to have such hardcoded lists.

- The already existing (in non-free) qmail-src package only counts
  238 installations, which doesn't seem to imply a large userbase.
  (Of course we don't know how many people have the unofficial netqmail
  packages installed)


[1] http://lists.debian.org/debian-devel/2008/11/msg00618.html
[2] http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html
[3] http://lists.debian.org/debian-devel/2008/11/msg00641.html

-- 
bye, Joerg
>Do you agree to uphold the Social Contract and the DFSG in your Debian
>work?
Absolutely.
(does anyone say "no" to this question? :) )

Attachment: pgp4Yj6WPUQad.pgp
Description: PGP signature


Reply to: