Gerrit Pape <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
