Solution (almost certainly): postfix fails to launch at boot

[Gerben Wierda]

> On 11 Jan 2020, at 19:32, Steven Smith <steve.t.smith at gmail.com> wrote:
> 
> Second, I see these two possible fixes:
> 
> • Include a little bash script in the postfix launch daemon that tests for macOS postfix being loaded, or port 25 in use, then wait a bit, and try a few times before giving up. I do this hack in the port macos-fortress-pf to make sure that PF is enabled. See this code:
> 
> https://github.com/macports/macports-ports/blob/1a27634a3f38cd7eafb2d3ecc92a402aa62b7d7f/net/macos-fortress/Portfile#L290-L292 <https://github.com/macports/macports-ports/blob/1a27634a3f38cd7eafb2d3ecc92a402aa62b7d7f/net/macos-fortress/Portfile#L290-L292>
> 
> • Edit /etc/postfix/master.cf as Gerben suggests.
> 
> My concern about the second option is that it will never give the macOS postfix a chance to do what it wants to do a boot time, and I don’t know what the unintended consequences would be. Also, every time you update the system this fix will get undone. Does macOS 10.14+ have an published approach to turn off native postfix completely?

I prefer the second option as the changes make sure there is no macOS-standard MTA running to receive mail. What the edit does is turn off the possibility to listen to SMTP calls on port 25 and 587 (in other words, provide a full mail server). Frankly, that was what Apple stopped doing in the first place by removing it from Server.app. 

We do run the risk, by the way, that at some point in the future Apple not only removes the remainders of postfix but also the users that come with postfix. Not something we need to worry about today, as so far they have kept all the standard users around for stuff that they have dropped.

G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20200111/5cfb1f37/attachment.html>