Update, 29th March 2016 The awesome Danny Tuppeny (@DanTup) has provided a much better solution to the problem. His question and answer are on the Unix Stack Exchange, and there's a discussion of the issue on Raspberry Pi's GitHub.
This is as much a reminder to me as it is a workaround for folks experiencing the same problem.
If you have postfix installed on a Raspberry Pi, you might experience the same problem as me - inability to send emails, with errors like this in your /var/log/mail.log file:
status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=opinionatedgeek.com type=MX: Host not found, try again)
Long story short - postfix uses its own resolv.conf file in /var/spool/postfix/etc/resolv.conf (because it chroots to /var/spool/postfix/). When postfix starts, it copies the existing /etc/resolv.conf (among other files) to the chroot location, and everything should just work.
On my Pi, it was copying over an empty resolv.conf file. My guess is that even though the dependency on the network was in the init script, some timing issue meant that postfix was copying the file before DHCP had set up the proper values in resolv.conf.
My nasty hack doesn’t solve the fundamental problem here (I’ll leave that to the experts), but just works around the problem by putting a ‘sleep’ in the postfix start command so it waits for a bit before doing the copying.
All I did was add the ‘sleep 5’ (and comment) to line 185 of /etc/init.d/postfix:
case "$1" in
# Added by Geoff, 6th March 2016, to make postfix wait until
# resolv.conf has been updated.
log_daemon_msg "Starting Postfix Mail Transport Agent" postfix
I then ran update-rc.d but I’m not sure that was necessary.
So future-Geoff, this is what you might need to do to get postfix working if something overwrites /etc/init.d/postfix. And for anyone else experiencing the problem, I hope you find this useful.