Postfix cannot resolve DNS if network was unavailable when it was started, such as on a laptop

I might have found the reason for this behaviour:

1) Without network connectivity, the file /etc/resolv.conf does not contain any useful information (just two comment lines).

2) After establishing network connectivity, the file /etc/resolv.conf contains 127.0.1.1 and a correct search path as received via DHCP.

3) Postfix copies the file /etc/resolv.conf to /var/spool/postfix/etc/resolv.conf upon startup. If postfix is started before the network is up, this file will not allow name resolution. Every other application uses /etc/resolv.conf and works fine.

Perhaps Network-Manager could restart postfix upon connection-up events? Can this be configured?

In light of the above the bug seems to be cause by interaction of the packages postfix, resolvconf, and network-manager by using postfix on a portable desktop machine as opposed to a server with static network configuration.

Since I am using mutt as mail client, I need a local MTA. Postfix seemed a valid choice, especially with the simple configuration using a smart host for all mail delivery. But it seems desktop GNU/Linux does not support this classic setup any more. :-(

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Importance -> Low since this doesn't affect the primary use of Postfix as a server MTA, but only with network-manager on a desktop machine.

FWIW, I use msmtp. I can't queue mails when offline, but otherwise it works fine for me.

It might be worth checking what the situation is on Debian for this use case. There may be a valid bug in Debian as well, and it would be better to follow what Debian do in this case I think.

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

Curiously, I never saw this problem on my laptop in Ubuntu versions up to and including 16.04 LTS. I'm seeing a lot of this problem ever since I upgraded to 16.10 LTS.

In the postfix service file (/lib/systemd/system/postfix.service), if you change:

After=network.target

to:

Requires=network-online.target
After=network-online.target

does that solve your problem?

Note: this is not a general solution as it breaks setups that only interface with localhost.

I'm currently testing the following workaround:

    --- /usr/lib/postfix/configure-instance.sh.orig 2016-11-14 09:24:03.832342133 +0200
    +++ /usr/lib/postfix/configure-instance.sh 2016-11-14 09:19:20.336826008 +0200
    @@ -120,6 +120,8 @@
          if [ -f /${file} ]; then rm -f ${file} && cp /${file} ${file}; fi
          if [ -f ${file} ]; then chmod a+rX ${file}; fi
      done
    + # an empty resolv.conf is useless -- ubuntu bug LP: #1519331
    + grep -q nameserver etc/resolv.conf || echo nameserver 127.0.1.1 >> etc/resolv.conf
      # ldaps needs this. debian bug 572841
      (echo /dev/random; echo /dev/urandom) | cpio -pdL --quiet . 2>/dev/null || true
      rm -f usr/lib/zoneinfo/localtime

It seems to work for me.

This is about how we integrate postfix and networking in Debian (and thus Ubuntu). It's not an upstream issue. Removing the needs-upstream-report tag.

I like the solution proposed in message #7. :-)

> This is about how we integrate postfix and networking in Debian (and thus Ubuntu). It's not an upstream issue. Removing the needs-upstream-report tag.

By "upstream", I meant Debian. I'm not aware of a separate bug tag for that. What should I be using instead of needs-upstream-report when it needs to go to the Debian BTS?

On Monday, December 19, 2016 08:58:24 AM you wrote:
> > This is about how we integrate postfix and networking in Debian (and
>
> thus Ubuntu). It's not an upstream issue. Removing the needs-upstream-
> report tag.
>
> By "upstream", I meant Debian. I'm not aware of a separate bug tag for
> that. What should I be using instead of needs-upstream-report when it
> needs to go to the Debian BTS?

In this particular case, at least one of the Debian postfix maintainers reads
Ubuntu bugs, so it's not needed.

>@Marius Gedminas (mgedmin)
>Curiously, I never saw this problem on my laptop in Ubuntu versions
>up to and including 16.04 LTS.
>I'm seeing a lot of this problem ever since I upgraded to 16.10 LTS.

I experienced the same issues when deploying Ubuntu 16.10 to a new MiniPC (opposed to Ubuntu 14.x that worked fine).

I have finally found an automated solution for this: enable the NetworkManager-wait-online.service and deploy a custom script that restarts the postfix service +-5 minutes after the machine has booted (assuming that the wireless connection is active by then).

A. Enable this.
It is a generic approach that might be beneficial for other service than Postfix as well so I keep it in the script.
````
systemctl enable NetworkManager-wait-online.service; systemctl status NetworkManager-wait-online.service;
````

B. Add a customer Systemd timer + service
@info The timer will start ONCE, {x} minutes after the machine was booted.
````
nano /etc/systemd/system/mjd-restart-postfix-after-wlan-connected.timer
    [Unit]
    Description=(timer)mjd-restart-postfix-after-wlan-connected
    [Timer]
    OnBootSec=5min
    [Install]
    WantedBy=timers.target
````
````
nano /etc/systemd/system/mjd-restart-postfix-after-wlan-connected.service
    [Unit]
    Description=mjd-restart-postfix-after-wlan-connected
    [Service]
    Type=oneshot
    ExecStart=/bin/sh -ec "systemctl restart postfix; systemctl status postfix; uname -a | /usr/bin/mailx -s \"Server (`hostname`): postfix was restarted.\" <email address hidden>"
````

````
MYUNIT=mjd-restart-postfix-after-wlan-connected
MYTIMER=${MYUNIT}.timer
systemctl enable ${MYTIMER}; systemctl status ${MYTIMER};
systemctl list-units --all | grep "${MYUNIT}"
systemctl status ${MYUNIT}
````

C. Restart
````reboot
````# wait 5 minutes

D. Check
````
MYUNIT=mjd-restart-postfix-after-wlan-connected
MYTIMER=${MYUNIT}.timer
systemctl status ${MYTIMER}
````

If the contents of these 2 config files (one of Resolve and one of Postfix) are not the same then the issue is PROBLEMATIC (Postfix started before LAN/WLAN gets connected).
cat /etc/resolv.conf
cat /var/spool/postfix/etc/resolv.conf

E. Info
@doc https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331
@doc https://wiki.archlinux.org/index.php/Systemd/Timers
@doc qshape deferred
@doc cat /var/log/syslog | egrep "NetworkManager|postfix"

It would be nice if someone who is having this problem could test 3.1.4-2 or later on Zesty to see if the problem is fixed (I think it is).

Which package was updated to fix this problem in Zesty? I could try to upgrade it only (I'm not ready to upgrade the whole distro).

On Monday, January 30, 2017 09:33:36 PM you wrote:
> Which package was updated to fix this problem in Zesty? I could try to
> upgrade it only (I'm not ready to upgrade the whole distro).

postfix

Just tried this with Zesty and Postfix 3.1.4-4. I have ipv4 dhcp, ipv6 static and resolv.conf. After reboot /var/spool/postfix/etc/resolv.conf did not have any addresses in it.

In case it helps other people, here is the workaround I use, in /etc/rc.local:
=============================
while ! grep -q nameserver /etc/resolv.conf
do
  sleep 30
done
cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
/etc/init.d/postfix restart
=============================

FWIW, I tried a bunch of different combinations of After, BindsTo, PartOf, and ReloadPropagatedFrom in /lib/systemd/system/postfix.service and none of them addressed the issue.

The only workaround I could get to work was to restart postifx on network up by adding `/etc/network/if-up.d/999local` with the following contents:

```
#!/bin/sh -e
# Called when a new interface comes up
# Local workarounds

# Fix postfix boot up issue:
# https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331
service postfix restart >/dev/null 2>&1
```

As I see it, the only reliable methods found to date are described in message #7 (https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331/comments/7), message #17 (https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331/comments/17), and message #19 (https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331/comments/19).

I like the idea of using a standard resolv.conf unless a more specific one is found on Postfix startup, as proposed in #7, but that is a hack and might lead to problems for "non-standard" DNS configurations, or changes in the Ubuntu way of configuring DNS.

A _reliable_ way of restarting on every change of /etc/resolv.conf to pick up the change would be the "right thing to do." AFAIU that should be done by placing a script in /etc/resolveconf/updated.d/. That script could possibly look just like that from message #19. I am going to try something like that, perhaps it works. I hope resolvconf still exists in the systemd world...

Thanks,
Erik

I am using the following script saved as /etc/resolvconf/update.d/postfix:

```
#! /bin/sh

# restart Postfix whenever resolv.conf changes, because Postfix creates
# a local copy of the file for use from inside its chroot

/usr/sbin/service postfix restart

```

That works reliably when changing network connectivity, e.g. going from cabled Ethernet to WLAN or vice versa. It does not always work during boot.

I use Ubuntu 14.04 LTS (and I do not dare to update my work notebook to 16.04 LTS, because it needs to actually work...).

Can confirm that this bug exists on Zesty. It occurs on my desktop machine which has network available at boot time via cabled ethernet.

I experience this on Zesty, on an always-on machine, that however relies on DHCP for network configuration.

I would argue that this is an upstream bug, or if you want a design flaw.

It is perfectly normal for resolv.conf to change at arbitrary moments. Examples are VPN and alternative redundant connectivity for a host. It seems wrong for a server to rely on a static snapshot of network configuration, because that configuration may change with time.

Had the same problem before Zesty and used some of the fixes described here to have postfix restart through rc.local file after waiting a few minutes. The bug is still persistent for me after upgrading to Zesty. What does fix it for me though is adding the "After" line to the Unit: /lib/systemd/system/postfix@.service

After=network-online.target

Note: it did not work to make this change to the postfix.service unit.

Another confirmation that this bug is still present in Zesty, and that the solution in #24 has worked fine for me so far.

Same issue here on zesty, empty /var/spool/postfix/etc/resolv.conf after reboot.

Applying solution from #24 works it around:

```
# printf "[Unit]\nAfter=network-online.target\n" | sudo SYSTEMD_EDITOR=tee systemctl edit postfix@-.service
```

Current working configuration:

```
# systemctl cat postfix@-.service
# /lib/systemd/system/postfix@.service
[Unit]
Description=Postfix Mail Transport Agent (instance %i)
Documentation=man:postfix(1)
PartOf=postfix.service
ReloadPropagatedFrom=postfix.service

[Service]
Type=forking
GuessMainPID=no
ExecStartPre=/usr/lib/postfix/configure-instance.sh %i
ExecStart=/usr/sbin/postmulti -i %i -p start
ExecStop=/usr/sbin/postmulti -i %i -p stop
ExecReload=/usr/sbin/postmulti -i %i -p reload

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/postfix@-.service.d/override.conf
[Unit]
After=network-online.target
```

I am seeing this issue on Ubuntu 17.04.

/var/spool/postfix/etc/resolv.conf is pointing at 192.168.122.1, which is the IP of my libvirt bridge - this is a result of dnsmasq interfacing with resolvconf, so that the host system can resolve local hostnames of guests on the bridge.

It's fine that 192.168.122.1 is listed (aside from the part where I've killed the dnsmasq there for unrelated reasons), but this differs from the host resolv.conf, which points to 127.0.0.53 first. We should *always* be pointing to 127.0.0.53 (systemd-resolved) on Ubuntu 16.10 and later. The fact that we aren't means postfix is racing systemd-resolved at boot.

I think it should be a sufficient fix for this bug, on 16.10 and later, to have /lib/systemd/system/postfix.service declare After=systemd-resolved.service.

I'm getting close to uploading a fix for this to Debian, so you might wait for
that.

On Mon, May 15, 2017 at 06:45:21PM -0000, Scott Kitterman wrote:
> I'm getting close to uploading a fix for this to Debian, so you might wait
> for that.

It looks like you've implemented this using the network-online.target
approach, which as you mentioned might not DTRT for the localhost-only use
case. Did you decide that this is negligible?

For the case of a server which always has a network connection, this works
fine. For the case of a standalone system with no configured network
connection, it probably also works fine. But for the case of e.g. a laptop
that sometimes has network and sometimes doesn't, if the system comes up
without network, postfix will not start and you will not have local
delivery. Is this the behavior you expect with your change?

Ultimately I want to SRU this into affected stable Ubuntu releases, so would
want a regression-free change.

I see you are also setting After=nss-lookup.target. For the bug reported
here - which is about DNS resolution specifically - would it not suffice to
have postfix declare this After=nss-lookup.target, and for systemd-resolved
to be sequenced before it?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On Monday, May 15, 2017 08:49:42 PM you wrote:
> On Mon, May 15, 2017 at 06:45:21PM -0000, Scott Kitterman wrote:
> > I'm getting close to uploading a fix for this to Debian, so you might wait
> > for that.
>
> It looks like you've implemented this using the network-online.target
> approach, which as you mentioned might not DTRT for the localhost-only use
> case. Did you decide that this is negligible?

That was the advice I got from the Debian systemd maintainers (that the impact
would be negligible).

> For the case of a server which always has a network connection, this works
> fine. For the case of a standalone system with no configured network
> connection, it probably also works fine. But for the case of e.g. a laptop
> that sometimes has network and sometimes doesn't, if the system comes up
> without network, postfix will not start and you will not have local
> delivery. Is this the behavior you expect with your change?

I tested this and if you're using NetworkManager at least there's some magic
that happens which causes systemd to restart postfix once the network is
available. Part of the reason I was having so much trouble replicating
problems others were seeing was getting NM to quit 'helping' as the test
system I was using also has a desktop installed.

> Ultimately I want to SRU this into affected stable Ubuntu releases, so would
> want a regression-free change.
>
> I see you are also setting After=nss-lookup.target. For the bug reported
> here - which is about DNS resolution specifically - would it not suffice to
> have postfix declare this After=nss-lookup.target, and for systemd-resolved
> to be sequenced before it?

According to the Debian systemd people, the systemd-resolved is superfluous.
It's nss-lookup.target that I wanted all along.

There's a very helpful (at least for me) discussion in the last few entries in
the Debian bug. Reviewing that would be better advice than I have for what's
safe/not as I cribbed from Michael Biebl's suggestions after just enough
research to be able to convince myself I wasn't cargo culting.

Scott K

Hi Scott,

Adding the Debian bug on Cc:.

On Mon, May 15, 2017 at 10:12:41PM -0000, Scott Kitterman wrote:
> On Monday, May 15, 2017 08:49:42 PM you wrote:
> > On Mon, May 15, 2017 at 06:45:21PM -0000, Scott Kitterman wrote:
> > > I'm getting close to uploading a fix for this to Debian, so you might wait
> > > for that.

> > It looks like you've implemented this using the network-online.target
> > approach, which as you mentioned might not DTRT for the localhost-only use
> > case. Did you decide that this is negligible?

> That was the advice I got from the Debian systemd maintainers (that the impact
> would be negligible).

Ok, the analysis on the Debian bug looks rather shallow to me:

> - The penalty of pulling in network-online.target is simply that for the
> local case postfix is started a bit later then necessary during boot.

There's no reason that this *should* be true for an intermittently-online
machine. The network-online.target is specifically defined so that services
are not started until the network connection is actually up; or put another
way, if a system is booted and can't get a network connection, those
services are not started. We don't just start them at some random point,
that would defeat the purpose.

So the case I described is still not handled here - a postfix setup that has
no dependency on the network interface bring-up (for binding), such as the
default config, will nevertheless be blocked from starting until there is a
network, including in cases where this is much more than a mere startup
timing distinction.

Now, you can't have a single unit config that simultaneously meets Russell's
request from the original bug report, to defer startup until a given bind
address is available, and the case I describe above, where you care about
postfix running even when the network is not up. I would argue that the
case I outlined is more important to get right out of the box, since it
requires no changes to the default postfix config whereas Russell's use case
does. But it's your decision as maintainer which to support as the default;
I just won't SRU the network-online.target change into any Ubuntu stable
releases because it would introduce a regression.

> > For the case of a server which always has a network connection, this works
> > fine. For the case of a standalone system with no configured network
> > connection, it probably also works fine. But for the case of e.g. a laptop
> > that sometimes has network and sometimes doesn't, if the system comes up
> > without network, postfix will not start and you will not have local
> > delivery. Is this the behavior you expect with your change?

> I tested this and if you're using NetworkManager at least there's some magic
> that happens which causes systemd to restart postfix once the network is
> available. Part of the reason I was having so much trouble replicating
> problems others were seeing was getting NM to quit 'helping' as the test
> system I was using also has a desktop installed.

Do you really mean that it restarts postfix when the network is available,
or is it starting postfix for the first time? The expected behavior is that
postfix doesn't start a...

On Mon, May 15, 2017 at 09:59:22PM -0700, Steve Langasek wrote:
> > - The penalty of pulling in network-online.target is simply that for the
> > local case postfix is started a bit later then necessary during boot.

> There's no reason that this *should* be true for an intermittently-online
> machine. The network-online.target is specifically defined so that services
> are not started until the network connection is actually up; or put another
> way, if a system is booted and can't get a network connection, those
> services are not started. We don't just start them at some random point,
> that would defeat the purpose.

So, I just noticed that NetworkManager-wait-online uses --timeout:

ExecStart=/usr/bin/nm-online -s -q --timeout=30

which means this delays services at most 30 seconds at boot.

And you can ignore my blather about this preventing services from running.
Sorry!

(I'm not convinced that having a timeout is actually sensible behavior, but,
well, it's what's implemented.)

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Hi,

I see two problems to solve to enable using Postfix on laptops with changing network connectivity:

1. Copy a working /etc/resolve.conf on initial Postfix start-up
2. Adjust Postfix's copy of /etc/resolv.conf in /var/spool/postfix/etc/resolv.conf

Part 1 seems to be tackled with waiting for networking to come up. A static default using 127.0.1.1 as DNS server might work as well, at least for Ubuntu 14.04 LTS.

Part 2 can be solved similar to my comment #21, i.e. restarting Postfix whenever the system resolv.conf changes by using the appropriate infrastructure for this. Just copying the new file to the change root might suffice and might be nicer.

My use case is well described by by Steve Langasek as "intermittently online" machine. I want Postfix to store e-mails if there is no network connectivity, and send them out, when network connectivity is available.

Back in the day this just worked. There was a static /etc/resolv.conf and Postfix used the system resolv.conf file. Later enhancements made /etc/resolv.conf dynamic and Postfix moved to a change root with a local copy of an /etc/resolv.conf snapshot. Those two changes do not work together correctly.

BTW, the current status on 14.04 LTS is that Postfix often copies /etc/resolv.conf before this file is created correctly. Disabling and then enabling the network (e.g. unplug cable, wait for NetworkManager to notice, plug cable back in) resolves the issue iff a hook in /etc/resolvconf/update.d/ picks up the change and updates Postfix. I use the simple, but heavy-weight script described in comment #21 for this.

Thanks,
Erik

I have just added something to the file /etc/resolvconf/resolv.conf.d/base to try to have a useful /etc/resolv.conf all the time:

```
# workaround for broken interactions with Postfix:
# fall back to the local name server 127.0.1.1
nameserver 127.0.1.1
```

Let's see how this plays out...

Thanks,
Erik

Adding the local recursive name server to /etc/resolvconf/resolv.conf.d/base (see comment #34) solved the problem of having an unusable /etc/resolv.conf at the time postfix copies it during boot. Together with restarting postfix whenever /etc/resov.conf changes solves my problems.

I would be happy to see a solution that works as well as my manual fixes added to the postfix and resolv.conf packages.

Thanks,
Erik

Marking this high; racing /etc/resolv.conf setup at boot is not just a desktop issue.

Hello Erik, or anyone else affected,

Accepted postfix into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.1.4-4ubuntu1 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 and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

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

Hello Erik, or anyone else affected,

Accepted postfix into yakkety-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/postfix/3.1.0-5ubuntu1 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 and change the tag from verification-needed-yakkety to verification-done-yakkety. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-yakkety. In either case, details of your testing will help us make a better decision.

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

Proposed package installed on zesty, workaround removed (/etc/systemd/system/postfix@-.service.d/override.conf) and rebooted.

So far so good :)

I've installed the proposed the package (on zesty), removed my workaround in /etc/rc.local, rebooted and it seems to work. Thanks!

Ran through the full test case on zesty and confirmed that this works as expected.

Test case confirmed also on yakkety.

This bug was fixed in the package postfix - 3.1.0-5ubuntu1

---------------
postfix (3.1.0-5ubuntu1) yakkety; urgency=medium

  * Use correct service dependencies in postfix@.service, to avoid racing
    systemd-resolved at boot. LP: #1519331.

 -- Steve Langasek <email address hidden> Sat, 03 Jun 2017 13:00:35 -0700

The verification of the Stable Release Update for postfix has completed successfully and the package has now been 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.

Anything in particular holding the release of this fix for Zesty?

The reason for it not being released for zesty before was that it seemed to have 3 undefined autopkgtest failures for sbuild. After looking into those now, it seems that the sbuild autopkgtests seem to be constantly failing for those 3 archs for all packages - so, (most likely) unrelated to the postfix upload. I would say that's enough for me to get it released.

On it now.

This bug was fixed in the package postfix - 3.1.4-4ubuntu1

---------------
postfix (3.1.4-4ubuntu1) zesty; urgency=medium

  * Use correct service dependencies in postfix@.service, to avoid racing
    systemd-resolved at boot. LP: #1519331.

 -- Steve Langasek <email address hidden> Sat, 03 Jun 2017 00:35:57 -0700

This bug is back in Ubuntu 20.04 postfix/focal-updates,now 3.4.13-0ubuntu1.2

I'm not certain of my analysis, but I see two services

postfix.service -----------------------------
[Unit]
Description=Postfix Mail Transport Agent
Conflicts=sendmail.service exim4.service
ConditionPathExists=/etc/postfix/main.cf

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true

[Install]
WantedBy=multi-user.target
---------------------------------------------
and
postfix@.service ----------------------------
[Unit]
Description=Postfix Mail Transport Agent (instance %i)
Documentation=man:postfix(1)
PartOf=postfix.service
Before=postfix.service
ReloadPropagatedFrom=postfix.service
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
GuessMainPID=no
ExecStartPre=/usr/lib/postfix/configure-instance.sh %i
ExecStart=/usr/sbin/postmulti -i %i -p start
ExecStop=/usr/sbin/postmulti -i %i -p stop
ExecReload=/usr/sbin/postmulti -i %i -p reload

[Install]
WantedBy=multi-user.target
---------------------------------------------
It appears the intent of postfix@.service is to delay starting postfix.service until after networking is up, but it seems that systemd doesn't accept postfix@.service as a valid service

$ sudo systemctl status postfix@.service
Failed to get properties: Unit name postfix@.service is neither a valid invocation ID nor unit name.

It's postfix@$INSTANCE. If you don't have multi-instance setup, the default instance is "-", so you would look for postfix@-, not postfix@. This is discussed in README.Debian. You should probably file a new bug for this problem if you don't get it figured out.