Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Raphael Hertzog <hertzog@debian.org> writes:
> On Thu, 01 Jan 2009, Joerg Jaspert wrote:
>> - 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)
> All those are good reasons to not choose the software as a user but not
> to not include them in Debian. We don't know how our users are going to
> use it and there might be use cases where those shortcomings are not
> problematic.
At this point, I think backscatter spam goes beyond buggy and into a
security issue. It allows people to abuse your mail server to resend
spam. Introducing a package into the archive with a known security issue
due to a design flaw that's unlikely to be fixed seems like something
worth thinking twice about.
Although maybe I'm wrong that it would be unlikely to be fixed. There are
replacements for qmail-smtpd that do not have this problem --
qmail-qpsmtpd, for example. A qmail package made with one of those
replacements would, to me, be a lot more compelling.
>> - 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.
> I'm don't know the rationale of this requirement in policy, adding aliases
> automatically is not really in the spirit of the policy that preserves
> configuration files.
/etc/aliases is something of a special case. It's not owned by a package,
it's created by different mail-transport-agent packages, and other
postinst scripts do add aliases to it automatically (logcheck and
debarchiver, for example).
The rationale is that packages that provide mail-transport-agent need to
have a consistent interface. This is as much for unbundled scripts and
tools, and for the system administrator, as it is for other Debian
packages. It's a goal of Policy to dictate the required functionality and
interfaces of packages that satisfy primary virtual packages such as
mail-transport-agent.
> Anyway, changing the recommends to depends might be a solution.
Yes.
>> - 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.
> Not sure about this one, some investigation needed.
The qmail user and group IDs are already registered. See
/usr/share/doc/base-passwd/README.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: