[SRU] dpkg hook hostname error

[Klaus Frank]

[Impact]

/etc/resolv.conf search domain with a leading dot cause postfix.postinst to fail because it constructs a 'myhostname' with a duplicate dot.

The glibc resolver tolerates such domains and strips the leading dot from the search domain [1]. This change makes postfix.postinst do the same.

This same fix has been proposed for inclusion in Debian [2].

[1] https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;hb=HEAD#l411
[2] https://salsa.debian.org/postfix-team/postfix-dev/-/merge_requests/12

[Test Plan]

1. Start an LXD container
2. Edit /etc/resolv.conf and add search line like one of these:

     search .
     search .foo.bar
     domain .foo.bar

3. Install postfix from the archive, accept all the debconf defaults,
   and verify that postinst fails with a broken domain name.
4. Purge postfix and install the version to test (e.g. from -proposed).
5. Verify that the installation succeeds.
6. Verify that `myhostname` in /etc/postfix/main.cf is sane.

Test PPA: https://launchpad.net/~paride/+archive/ubuntu/postfix-lp1906970

[Where problems could occur]

There is no reasonable case where a user could rely on a "broken" setup, as its result is a postinst failure (= install failure) and an invalid "myhostname" in main.cf.

The regression potential is in my opinion very low and, given the scope and nature of the change, mostly due to the newer Build-Deps the package will be built with.

The postfix service is restarted on upgrades of the postfix package, so problems may also occur on systems with issues (misconfiguration, filled partitions, ...) but where Postfix has not been restarted and it's still working, but won't resume its operations on upgrade. While this is technically a "not a bug in Ubuntu" case it is also something we don't want to expose users to for no good reason.

[Development Fix]

This is fixed already in the current devel release (Impish). This SRU backports the very same fix to the stable releases.

Once [2] or equivalent gets accepted in Debian we'll be able to drop the delta and make postfix.

[Original Description]

I tried to install postfix (3.4.13-0ubuntu1) within a Dockerfile (Ubuntu 20.04.01 LTS) and it failed because there is an error in the dpkg info file.

I'm attaching the log of the 2nd time "apt install -y postfix" is executed, as it is way shorter and still shows the error message.

```
root@cc1a572af0dc:/etc# apt install -y postfix
Reading package lists... Done
Building dependency tree
Reading state information... Done
postfix is already the newest version (3.4.13-0ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up postfix (3.4.13-0ubuntu1) ...

Postfix (main.cf) configuration was untouched. If you need to make changes,
edit /etc/postfix/main.cf (and others) as needed. To view Postfix
configuration values, see postconf(1).

After modifying main.cf, be sure to run 'systemctl reload postfix'.

Running newaliases
newaliases: warning: valid_hostname: misplaced delimiter: cc1a572af0dc..
newaliases: fatal: file /etc/postfix/main.cf: parameter myhostname: bad parameter value: cc1a572af0dc..
dpkg: error processing package postfix (--configure):
 installed postfix package post-installation script subprocess returned error exit status 75
Processing triggers for libc-bin (2.31-0ubuntu9.1) ...
Errors were encountered while processing:
 postfix
E: Sub-process /usr/bin/dpkg returned an error code (1)
```

I then looked into the /etc/postfix/main.cf file and tried to manually change the hostname, but it automatically gets overwritten by dpkg when apt install is ran.

After that I was able to track the issue into the script "/var/lib/dpkg/info/postfix.postinst" more exactly the sed command in line 52. It reads the content of the search parameter from /etc/resolv.conf, and concatenates it with a "." as delimiter with the hostname, but it doesn't honor the special case of "search ." and therefore constructs an incorrect myhostname parameter for postfix of "cc1a572af0dc..".

I'd propose to remove this resolve.conf lookup entirely so that the package installation doesn't fail within docker containers...
It is a bad practice in my opinion to overwrite existing config files upon package installation.
Also I'd suggest not executing postfix after the configuration is written, so that in case of unforeseen circumstances (like this one) a user can just simply run a sed against the config file after installing the package.

And the Dockerfile for reference:
```
FROM ubuntu:latest

ENV DEBIAN_FRONTEND=noninteractive
#ENV DEBIAN_PRIORITY=low

RUN apt update \
    && echo "postfix postfix/main_mailer_type select Internet Site" | debconf-set-selections \
    && echo "postfix postfix/mailname string mysubdomain.mydomain.com" | debconf-set-selections \
    && apt install -y postfix
```

[Christian Ehrhardt  (paelzer)]

Hi Klaus,

From your log:
newaliases: warning: valid_hostname: misplaced delimiter: cc1a572af0dc..

That comes down to the initial install&configuration requiring a fully qualified domain name.
And your systems seems to have an invalid one for that use case.

There are two paths out of this.
a) fix the hostname to be a correct fully qualified domain name. Then the postinst config will use that and work.
b) when installing postfix you can select interactively to have it set up with "no config" that allows to manually configure it the way you want it and will not trigger the auto-config code that currently is breaking for you

Which way you choose depends on your preference and your control of the environment.

Fqdn's are a defined standard, and if your name would be like one it should work.
Never the less we try to catch and handle some common issues.
It might be worth for your to look at your hostname in general (report your full name here please) and the code that the install runs you can find in /var/lib/dpkg/info/postfix.postinst - check the function myfqdn for that.
If therein is an issue that could be improved to support your kind of hostname better that might be worth a talk.

[Klaus Frank (agowa338)]

This is the default name of the docker container. That's why I reported it here. For me it is a problem with the install script. It shouldn't fail to install within a default docker container.

regarding b) how do I make docker select that automatically? I wasn't able to find any way to install postfix silently except by the commands and environment variables listed above.

{quote}
Fqdn's are a defined standard, and if your name would be like one it should work.
Never the less we try to catch and handle some common issues.
It might be worth for your to look at your hostname in general (report your full name here please) and the code that the install runs you can find in /var/lib/dpkg/info/postfix.postinst - check the function myfqdn for that.
If therein is an issue that could be improved to support your kind of hostname better that might be worth a talk.
{quote}

I already provided that. The hostname is just "cc1a572af0dc" without domain. It is set by docker. I don't know how I would influence that at build time.

I also provided where in the post install script it fails and why. It fails within that function when you try to work around the missing domain part in the fqdn by appending the "search" part from /etc/resolv.conf. That part generates an invalid host name and writes that into the postfix configuration and than tries to start postfix using it which makes dpkg fail.
THe resolv.conf is also written by docker and therefore also outside of my control.

And here is an asciinema recording, maybe that helps to show what the problem is:
* https://asciinema.org/a/MszFQIxhFi5l5Agh8EQAGC26n

[Paride Legovini (paride)]

Hi Klaus,

I think the culprit is the misconfigured `search .` domain in /etc/resolv.conf. However that's not a Docker (image) default: it's just inherited by the host system. Can you please verify this is the case, try fixing it in the host system and try the postfix install in docker once again? If it still doesn't work, can you please share the /etc/resolv.conf of the host system?

I'm setting the status of this report to Incomplete for the moment. Please change it to Invalid if you end up finding this is just a configuration issue, otherwise comment back, change it back to New and we'll look at it again. Thanks!

[Klaus Frank (agowa338)]

This is the content of the hosts /etc/resolv.conf:

```
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
```

[Christian Ehrhardt  (paelzer)]

That indeed contains the offending "search .".
Since the file is managed by systemd-resolved the question becomes where exactly that comes from.

To ensure this is the case check /run/systemd/resolve/stub-resolv.conf which is the file that pushes info from systemd-resolved into resolv.conf.
There it should also have the "search ." entry.

Furthermore you can check which connection of yours is proving that.
 $ systemd-resolve --status

In my example /run/systemd/resolve/stub-resolv.con
holds "search fritz.box buildd" of which I can see in --status that "buildd" is from a VPN connection I have and "fritz.box" is from my local router (seen on lan and wlan interface).

That could be the first step to get a feeling "where it is coming from"

It could be:
- from your dhcp server that pushed this search domain
- from your local dhcp config that has an entry to append this search domain
- "search" statement via local config in /etc/netplan/*
- as config of "Domains=" in /etc/systemd/resolved.conf
- somewhere buried int he network-manager gui (If you are on a desktop)
- ... (I might have missed one)

But the next step IMHO is to find where that config really comes from to adapt/fix it there.

[Klaus Frank (agowa338)]

This is just an error in the postfix dpkg script. Having "search ." is completely valid. I also asked in IRC. In IRC we had consensus that "search ." is the catch all as it references the DNS-Root domain.

```
[root@ ~]# ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Nov 25 2019 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
[root@ ~]# ls -la /run/systemd/resolve/resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 751 Dec 9 11:23 /run/systemd/resolve/resolv.conf
[root@ ~]# cat /run/systemd/resolve/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 2a02:c205::1:53
nameserver 2a02:c205::2:53
nameserver 9.9.9.9
# Too many DNS servers configured, the following entries may be ignored.
nameserver 8.8.8.8
search .
[root@ ~]# systemd-resolve --status
Global
           Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: uplink
Fallback DNS Servers: 1.1.1.1 9.9.9.10 8.8.8.8 2606:4700:4700::1111 2620:fe::10 2001:4860:4860::8888

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 2a02:c205::1:53 2a02:c205::2:53 9.9.9.9 8.8.8.8

Link 3 (sit0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (br-4e6ai9437685)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (br-859c2b6c2616)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (br-9d44fdf2dc39)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 7 (br-055c241e7b4a)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 8 (br-915a9b534b30)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 9 (br-697dfb18ce2a)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 10 (br-591acc92bcad)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 11 (docker0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 12 (br-982c9ab14428)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 13 (br-c5eca9924b69)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 14 (br-4d8950262cec)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=n...

[Balint Reczey (rbalint)]

This also breaks installing postfix in autokgtest and holds back fixing sbuild's autopkgtest at the moment.

...
/etc/aliases does not exist, creating it.
WARNING: /etc/aliases exists, but does not have a root alias.

Postfix (main.cf) is now set up with a default configuration. If you need to
make changes, edit /etc/postfix/main.cf (and others) as needed. To view
Postfix configuration values, see postconf(1).

After modifying main.cf, be sure to run 'systemctl reload postfix'.

Running newaliases
newaliases: warning: valid_hostname: misplaced delimiter: autopkgtest..
newaliases: fatal: file /etc/postfix/main.cf: parameter myhostname: bad parameter value: autopkgtest..
dpkg: error processing package postfix (--configure):
 installed postfix package post-installation script subprocess returned error exit status 75
Setting up libslirp0:amd64 (4.4.0-1) ...
Setting up ipxe-qemu (1.0.0+git-20190125.36a4c85-5ubuntu3) ...
Setting up libasound2:amd64 (1.2.4-1.1build1) ...
Setting up librole-tiny-perl (2.002004-1) ...
Setting up libndctl6:amd64 (71.1-1) ...
dpkg: dependency problems prevent configuration of buildd:
 buildd depends on default-mta | mail-transport-agent; however:
  Package default-mta is not installed.
  Package postfix which provides default-mta is not configured yet.
  Package mail-transport-agent is not installed.
  Package postfix which provides mail-transport-agent is not configured yet.

dpkg: error processing package buildd (--configure):
 dependency problems - leaving unconfigured
Setting up ipxe-qemu-256k-compat-efi-roms (1.0.0+git-20150424.a25a16d-0ubuntu4) ...
...

[Balint Reczey (rbalint)]

The sbuild autopkgtest failure will be observable with sbuild 0.81.2ubuntu3.

[Balint Reczey (rbalint)]

The sbuild autopkgtest failure is not observable on the central Ubuntu CI infra, but it is when running the sbuild autopkgtest locally in qemu.

[Ian Johnson (anonymouse67)]

This happened to me when upgrading from Groovy to Hirsute just now, with the same symptoms as above - I had `search .` in resolv.conf, but nothing creating that entry in /etc/netplan or in /etc/systemd/resolved.conf.

I fixed the broken package by fixing the erroneous entry /etc/postfix/main.cf (removing the ".." at the end of the hostname) and then running:

sudo dpkg-reconfigure --force postfix
sudo systemctl reload postfix

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Paride Legovini (paride)]

Sergio (~sergiodj) did some digging on `search .` and found out that it should be supported after all. I'm copy/pasting here his email to <email address hidden> for future reference:

=== Message-ID: <email address hidden> ===

I think the reporter from #1906970 is right: it seems that "search ." is
indeed supported.

Interestingly, I could not find any documentation to truly back this up;
even though the manpage for resolv.conf(5) is well written (kudos to
Michael Kerrisk and the man-pages project, btw!), it is not
authoritative when it comes to defining what "search ." means. So I had
to resort to the real source of knowledge here: glibc and its resolver.

Long story short, the resolver code lives under the "resolv/" directory
on glibc. If you look at the res_search function (which performs DNS
queries taking "search" into account), you will find this excerpt here:

  https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/res_query.c;h=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;hb=HEAD#l385

When RES_DNSRCH is set, it means that the resolver will search for
hostnames in the current domain and in parent domains. Particularly,
this excerpt is interesting:

 /* __res_context_querydoman concatenates name
    with dname with a "." in between. If we
    pass it in dname the "." we got from the
    configured default search path, we'll end
    up with "name..", which won't resolve.
    OTOH, passing it "" will result in "name.",
    which has the intended effect for both
    possible representations of the root
    domain. */
 if (dname[0] == '.')
  dname++;
 if (dname[0] == '\0')
  root_on_list++;

So you see that the code takes into account the case when "search ." is
used, and interprets it as representing the root domain indeed.

[Paride Legovini (paride)]

I can reproduce the sbuild autopkgtest failure locally using autopkgtest-virt-qemu, but interestingly this doesn't happen on autopkgtest.ubuntu.com, which tests using autopkgtest-virt-ssh to an openstack instance. I imagine that platform doesn't have `search .` in /etc/resolv.conf. which is what triggers the problem.

[Paride Legovini (paride)]

My understanding now is that the resolver *tolerates* search domains starting with a ".", stripping it off. This is very visible in the code snipped posted by Sergio:

 if (dname[0] == '.')
  dname++;

and this is the reason "search ." is not really documented: it's not really useful as in practice it is not different from having no search domain at all.

However, given that "search ." is for some reason not that rare, I think it makes sense to make the postfix postinst script tolerate it. The fix only requires a small change in a regexp.

[Launchpad Janitor (janitor)]

This bug was fixed in the package postfix - 3.5.6-1ubuntu1

---------------
postfix (3.5.6-1ubuntu1) impish; urgency=medium

  * d/postfix.postinst: tolerate search domain with a leading dot
    (LP: #1906970)

 -- Paride Legovini <email address hidden> Fri, 06 Aug 2021 17:56:03 +0200

[Paride Legovini (paride)]

I verified that the landed fix also fixes the sbuild autopkgtest failure:

build-procenv PASS
unshare-qemuwrapper SKIP installation fails and skip-not-installable set
unshare PASS

[Paride Legovini (paride)]

This small patch is worth SRUing to Focal and Hirsute, I added tasks for those.

[Brian Murray (brian-murray)]

Hello Klaus, or anyone else affected,

Accepted postfix into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.5.6-1ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Klaus, or anyone else affected,

Accepted postfix into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.4.13-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Brian Murray (brian-murray)]

Hello Klaus, or anyone else affected,

Accepted postfix into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.3.0-1ubuntu0.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted postfix (3.4.13-0ubuntu1.1) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

backuppc/3.3.2-3 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#postfix

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted postfix (3.5.6-1ubuntu0.1) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

backuppc/3.3.2-3 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#postfix

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Paride Legovini (paride)]

The two regressions are not due to this SRU but due to:

https://bugs.launchpad.net/ubuntu/+source/backuppc/+bug/1936437

which has been fixed (better: worked around) in Impish but the workaround has not been backported. This is likely not a bug in backuppc, my impression is that for some reason the armhf autopkgtest testbed images are lacking the suid bit on ping6. Reinstalling the package sets it, and the the tests pass.

[Paride Legovini (paride)]

Verification done in Bionic, Focal, Hirsute as described in the [Test Plan].

[Paride Legovini (paride)]

These MPs would unblock the migration by adding force-reset-test hints:

https://code.launchpad.net/~paride/britney/+git/hints-ubuntu/+merge/407458

https://code.launchpad.net/~paride/britney/+git/hints-ubuntu/+merge/407459

[Launchpad Janitor (janitor)]

This bug was fixed in the package postfix - 3.3.0-1ubuntu0.4

---------------
postfix (3.3.0-1ubuntu0.4) bionic; urgency=medium

  * d/postfix.postinst: tolerate search domain with a leading dot
    (LP: #1906970)

 -- Paride Legovini <email address hidden> Thu, 12 Aug 2021 14:43:19 +0200

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for postfix has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package postfix - 3.5.6-1ubuntu0.1

---------------
postfix (3.5.6-1ubuntu0.1) hirsute; urgency=medium

  * d/postfix.postinst: tolerate search domain with a leading dot
    (LP: #1906970)

 -- Paride Legovini <email address hidden> Thu, 12 Aug 2021 14:39:06 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package postfix - 3.4.13-0ubuntu1.1

---------------
postfix (3.4.13-0ubuntu1.1) focal; urgency=medium

  * d/postfix.postinst: tolerate search domain with a leading dot
    (LP: #1906970)

 -- Paride Legovini <email address hidden> Thu, 12 Aug 2021 14:26:09 +0200