Re: Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
Gerrit Pape <pape@dbnbgs.smarden.org> writes:
> Hi, I'm not sure I'm reading policy correctly. Is it okay to provide
> such a newaliases program
> #!/bin/sh
> cat >&2 <<EOT
>
> qmail on Debian by default doesn't support the /etc/aliases database,
> but handles mail aliases differently, please see
> http://lifewithqmail.org/lwq.html#aliases
>
> EOT
> exit 1
> which will be diverted and replaced by a fully functional version if the
> fastforward package is installed? This way users would be able to
> choose which alias mechanism to use easily.
My reading of Policy is that an MTA should, by default, correctly handle
aliases defined in /etc/aliases. The MTA may require that newaliases be
called after changes to that file to update internal databases, or
newaliases may be a no-op if the MTA reads the file directly, but either
way modifications made to that file followed by a call to newaliases must
be honored by default.
It's certainly okay for a sysadmin to indicate that they don't want to use
that mechanism and want to use the qmail native mechanism instead.
If I were you, I'd probably use a debconf question asking whether or not
to enable /etc/aliases handling, with the default answer being yes, so
that people who want the native qmail behavior can disable it. I'm sure
that's not the only solution to the problem, though, and I've only thought
about it for a couple of minutes.
I agree that the Policy wording could be less ambiguous about the
requirements placed on the MTA. Right now, it reads mostly as
requirements placed on agents editing /etc/aliases and the statement about
what /etc/aliases is for is presented as a definition rather than as a
requirement. I think the above was the intention, though.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: