Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Tue, Jan 06, 2009 at 12:38:11AM +0000, Ian Jackson wrote:
> Joerg Jaspert writes ("Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian"):
> > Criteria that speak against inclusion:
> > - no real upstream
> What is required is that _someone_ is able and prepared to act as
> upstream. Is Gerrit Pape willing and able to do that ? Does he have
> the skills and experience necessary for maintaining an MTA package
> written in a somewhat-strange C dialect ? (I haven't looked into this
> question but it seems the one we need to ask.)
There's a team around 'netqmail' which is considered upstream nowadays,
http://qmail.org/netqmail/
Nevertheless, I do think I have the skills an experience to work with
the source in case upstream isn't responsible.
> This may seem like an unfair argument but I think it's valid: I think
> that if someone is so keen on Qmail that they want to add it to Debian,
> that in itself might well lead us to question their competence to deal
> with Internet email systems.
I've heard that before[*], but must confess, this still doesn't change
my mind. I know that my opinion on some matters of the Internet mail
infrastructure are not in line with, it looks so, what most other people
in Debian think. But I'm still of that opinion, and judge arguments
speaking against it differently, just as my arguments against the other
opinion are judged differently, or not properly understood.
[*] http://lists.debian.org/debian-devel/2008/12/msg00305.html
and followups
I'm using qmail on Debian, providing unofficial packages through
http://smarden.org/pape/Debian/ and developing around qmail since ages.
After qmail was released into the public domain, I've been approached by
users, asking me to make the qmail packages available officially through
Debian/main. That's what motivated me to adapt the existing package so
that they comply with the Debian policy, as the unofficial ones did
not completely.
> So at the minimum I would expect an explanation from the prospective
> maintainer. Gerrit, can you supply a list of:
> * Every criticism which (otherwise-) reasonable people have
> levelled as a serious complaint against Qmail (and I don't
> include just the complaints made by the ftpmasters);
Wow.
> * For each such criticism, what your opinion of it is and what
> if anything you plan to do about it.
That's what I read from this thread, cut down to the minimum, criticisms
that seem to be release critical:
(1) delayed bounces. By default, qmail first accepts mail injected into
the system on port 25, and, if it cannot be delivered, a separate bounce
message is injected.
(joerg, ian, russ)
(2) Andree's 'Qmail bugs and wishlist' page at
http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html
(joerg, kalle)
(3) How the suggested packages handle the 'newaliases' program
(Steve)
Other points like 'no upstream', 'FHS violation', 'better MTA already
available' don't seem to be issues or judged RC, and may be handled
through normal bug reports I think.
If I forgot additional criticisms, please followup and add to the list.
My opinion on
(1) while not agreeing completely (see beginning of the mail), after all
it's just fine with the RFCs, I'm okay with changing the packages so
that in the default install mail to unknown users received through SMTP
is rejected during the SMTP session, and doesn't cause a separate bounce
message.
(2) Only 'Part I: Bugs' seems to be relevant
1.1 doesn't apply. The prospective packages follow 'Life with qmail'
almost completely.
1.2 see (1).
1.3 qmail-qmtpd isn't enabled by default. If enabled, it's considered
a protocol to be used between machines that trust each other.
1.4 doesn't apply. Resource limits are set appropriately.
2.1 I'd suggest not to change that, it's a good compromise between
performance and reliability.
2.2 qmail's MDA qmail-local doesn't override files on name collisions,
but stops, and retries later. If there's really mail loss, some MUA
misses the required sanity checks.
2.3 I fail to see the impact.
3.1 I think it's a minor problem if at all, please see
http://lists.debian.org/debian-devel/2008/12/msg00238.html
3.2 I think it's a minor problem if at all, please see
http://lists.debian.org/debian-devel/2008/12/msg00238.html
3.3 It's news to be that MIME DSN's are mandatory these days, when has
this changed (serious question)? RFC1894, Abstract, starts with 'This
memo defines a MIME content-type that may be used by a message'...
3.4 Might be a bug, I didn't look into that deeply, didn't notice any
impact yet. pop3 isn't enabled by the prospective packages.
See also http://lists.debian.org/debian-devel/2008/12/msg00238.html
I'd prefer to not address any of these issues in the qmail packages.
The target audience of the packages are people using qmail because they
think it's the best choice for their security requirements. One way to
achieve this level of security of qmail was that the code proved to be
secure over a very long time, without changing. As soon as lots of
changes are introduced, the security, or reputation, may suffer. I'd
like to only introduce patches where really necessary.
(3) I was of the opinion that a dependency chain to a packages that
provides the newliases program is enough to conform with the Debian
policy, and, since Recommends are install by default, recommending the
fastforward package is sufficient, while preserving flexibility. I now
see that on systems where exim is installed as default MTA, installing
the fastforward package will result in a file conflict. The packages
should be adapted, so that the qmail-run package provides the newaliases
program.
Regards, Gerrit.
Reply to: