Setting relay_host in /etc/postfix/main.cf manual and the doing dpkg-reconfigured results in debconf setting (unless you set it back) the relay_host previously configured in debconf, not the one from main.cf through manual editing.

Correct.  How would you suggest that I determine which one was set last?

lamont

Oh, IIRC another is rkhunter.

Regards,

Daniel

For dpkg-reconfigure (vs initial package install) would main.cf always
be last, since debconf would come from either preseeding or debconf,
which would get always applied to main.cf?

I don't know if there is a way to tell the difference between
dpkg-reconfigure vs initial install though (I am not a DD and haven't
really delved into the intricacies of packaging).

If there is then the solution would be to add a check.

I do know that other packages, such as apt-listchanges and debsums (and
a few others I can't remember at the moment) take the info from the
configuration files over debconf - maybe they have something that will help?

Regards,

Daniel

It was suggested on the #freedombox IRC channel that my recent experience
with postfix on fbx might be related to this bug. I'll briefly relate
experience here, therefore, in case it might be useful. I hope it isn't
noise.

I had a working postfix setup on fbx 23.6.2 setup.  Because the Debian 11 ->
12 transition had frozen uploads, and because the change in the way apt
handles the labels stable and <code name (bookworm in this case)> changed in
bookworm and required making a config change to apt, I didn't get an upgrade
of my fbx package until 28 July 2023 at 01:38 UTC, which was from 23.6.2 to
23.13~bpo12+1.

Shortly after that I discovered that mail destined for users of my fbx was
being rejected by postfix with

"Diagnostic-Code: smtp; 454 4.7.1 <joedoe@mydomain.com <mailto:joedoe@mydomain.com>>: Relay access denied"

It turns out that postfix's main.cf file had been overwritten on 28 July
2023 at UTC 01:41 with no real configuration in it.  At least, there was no
mention of mydomain.com in the file anymore, nor to any fqdn, for that
matter.  On IRC I learned that the postinst script in the postfix package is
run at each upgrade.  The suggestion was that possibly the postfix postinst
script was responsible for overwriting my working main.cf

The behaviour I would like to see is as with other Debian packages that are
about to overwrite an existing config file:

* A dialogue appears explaining the situation where you can choose to let
  the package overwrite the file, saving the original with a .dpkg-old
  suffix, to keep the original file, while writing the pkg maintainers
  version to <file>.dpkg-new, or to examine the differences between the two
  files before deciding.

Fortunately I had a backup of the working main.cf, so recovery was much
simpler than figuring out why my setup had quit working.

If any interested parties would like more information about my experience,
ask,  and I will do my best to find that info for you.

I'm still not sure if my experiences with postfix on Freedombox are related.
However, no one has told me that my last message was noise. So, I will just
add that the same thing has happened again: postfix's main.cf was
overwritten somehow and didn't include my domainname in it anymore.

The result was valid incoming mail to my domain was being rejected with the
error code 454 4.7.1 and the message Relay access denied. "ls -lAF" dated
main.cf at November 11.

According to the apt logs, freedombox, freedombox-doc-en and
freedombox-doc-es were updated on November 11.

See also #620543.

In my view, what should be done in this case is - on upgrade (or on
`dpkg-reconfigure`, which is the same thing in this context), postfix
setup script should notice the difference between debconf-saved value
and actual value used in the current config file, and ask whenever to
use current value (in which case debconf-saved value is set to current)
or to override it with debconf-saved one.

The same applies to an initial install when there was no postfix package
has been installed on the system, but main.cf/master.cf exists.

This complicates things for sure, but I see it like the only way to
avoid surprises like this one.  I'd say we use debconf in a wrong way
in postfix, - it is like forcing a new conffile on upgrades which is
a complete no-go in debian.

Well, okay, there's one more possible way: to drop debconf entirely :)

Thanks,

/mjt