Random packaging notes debconf ~~~~~~~ Debconf handling is done in a wrong way. It should feed its initial values from the live system (from actual main.cf, etc files) instead of using values previously stored in the database, - unless there's no initial configuration found, in which case default values stored in the debconf should be used. This avoids re-setting configuration to debconf values on every upgrade, - we have multiple bugs about that. See https://bugs.debian.org/734401 alias handling ~~~~~~~~~~~~~~ up to 3.9.1 postfix postinst hardcoded hash:/etc/aliases as the only place for aliases, created this file on every upgrade (despite it might be unused or moved), and adds (or tries to add) root alias to this file too. It might as well take a look at $alias_maps. Root alias handling (root_address debconf question) logic is wrong: it adds root alias only if set by debconf, when either of the two conditions met (simplifying): either /etc/aliases does not exists, or it is a new install (not upgrade). But root_address debconf question is of "medium" priority, while default priority when first run is "high", so this question is not seen by the user. When re-configuring it, /etc/aliases exists and it is not a new install anymore, so it is not added. newaliases ~~~~~~~~~~ In debian postfix package up to 3.9.1, it was used to run newaliases if alias database contains a map type being registered. This is kinda pointless, -- yes, it helps in a situation when the user configured a new map type for alias_database which is not installed on the target system, -- now, alias database will be built automatically at map install time. But this isn't a common situation, and the user can run newaliases manually after observing errors in the logs. And it is still broken, because alias database might contain other map types, in which case newaliases will fail and the installation will stop too. A correct solution would be to add a trigger to the main postfix package and try to rebuild aliases. Or better yet, just remove whole thing and only try to run newaliases once at new install, and just tell user to re-run it manually if failed - since adding this automatic complexity is difficult (to get right) with no visible gains. There might be another case when we may want to run newaliases during upgrade: when file format has changed for some database. But this should be handled for all maps, not just aliases, and for all instances, and it is dependent on other packages, not on postifx. See https://bugs.debian.org/847242 https://bugs.debian.org/865005 https://bugs.debian.org/864609 Complex newaliases handling has been removed in 3.9.1-3, - we now try to run newaliases only once when we know we modified /etc/aliases, at the end of postfix.postinst script, and if that failed, just warn user and continue. No need to try to be smart here. postfix@ vs postfix vs postmulti service ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ See https://bugs.debian.org/1088862 - we should revisit how services are started. With systemd, there's no good way to run multiple postfix instances within a single service, since systemd wants single main process and is confused by multiple such processes. I think it would be good to have regular postfix.service to start just a single default instance. With all other instances managed as their own postfix@foo.service, where foo is a path component after /etc/postfix- prefix stripped - path-based because we need to manage unnamed instances too, but this restricts directory naming. When starting as `postfix start' (monolith multiple instances) or `postmulti -i foo -p start', these utilities might just execute the systemd service transparently instead of trying to run master(8). This way, full functionality of postmulti(1) is available to the user too, in a sane way, and we can also arrange to enable/disable the instances automatically behind the scenes. It is somewhat difficult to revert back from current multi-instance postfix.service to plain postfix.service in postinst. And since users of multi-instance postfix.service, who actually need multiple instances managed by systemd, got used to the name `postfix' to refer to multi- instance postfix service, it'd be nice to keep this single naming for users and for maintscripts too. Also, users might have other dirs besides /etc/postfix-* configured, especially like /etc/postfix/foo (within main postfix dir) - these wont be usable. chroot ~~~~~~ Debian postfix package always had chroot enabled by default. Enabling it in the first place is questionable by itself already, but enabling it by default is.. difficult, it poses a lot of unnecessary burden to the users. High percentage of bug reports in the bts are due to chroot in one way or another. We should get rid of this default at least. Offering a debconf-level choice might be a good thing, but it is very difficult to achieve, - maybe only for a new install. And we have to keep currently used chroots working, and fix the remaining bugs if possible. See https://bugs.debian.org/151692 https://bugs.debian.org/1084167 and numerous bug reports marked with "[chroot]" in the title. We copy nss stuff to chroot because this is what's used by postfix smtp client as "native" way for host lookups (smtp_host_lookup). By default it uses internal dns routines directly, which utilizes res_* functions. Also, various networking maps might use nss host lookups, but these are better to be handled with proxy: map type. Glibc does not need libresolv anymore. And picks up changes to resolv.conf immediately on next lookup. #572841 says /dev/random and /dev/urandom are needed in chroot jail to run ldaps. Is this true still? Are these device files needed for something else? In 3.9.1-5, I stopped creating /dev/random in chroot. rmail ~~~~~ Do we need rmail binary (comes from sendmail package) and a working uucp entry in master.cf in 2025? Not that it requires much though.