Why is postfix running on my Mac?

I never installed postfix on my computer, and I never saw it before installing MacOS 12. But now it’s posing a problem: I operate my own CommuniGate Pro mail server, and it conflicts with postfix. postfix terminates itself, but like the Energizer bunny, the service keeps popping up (respawning) despite attempts to kill it.

launchd (1) is the parent process of root process master; master in turn is the parent process of both qmgr and pickup, both of which run as user _postfix.

Can anyone point me toward a safe method for removing it? Could it be as simple as deleting (or renaming) these two items?


What about the usr/libexec/postfix directory? All this postfix stuff appears to have been installed on 14 July 2022—at 3:48 a.m.! No idea why; maybe a system update?

Thanks in advance for any insight!

Postfix is a popular e-mail server app.

Most Unix-like systems (including macOS) include some kind of mail server, either running in the background or on demand. If you don’t do anything to configure it for sending Internet mail, then it will only be used for delivering mail between the users on the single computer it is running on.

Why would you want this? Primarily because background system services sometimes send reports to the local “root” account, and there needs to be some piece of software to deliver that message.

It is a common practice, when installing a new Unix-like system to configure the root account (with a .forward file) to forward all of its e-mail to someone who might find it relevant (e.g. you, if it is your computer).

On macOS, by default, these messages are just deleted. You can see this by viewing the root account’s .forward file:

>sudo cat ~root/.forward

Forwarding to /dev/null causes all mail for root to be deleted. You can change this to (for example) your account’s short user ID. Then you will receive the messages. (Type mail from a terminal window to launch the legacy mailx app to access it. Type man mail to view its documentation.)

But for all this to work, some mail server needs to be installed and running and Apple has (at least for recent macOS releases) chosen to use Postfix.

(If you want to get really fancy, you can configure Postfix for sending Internet e-mail and then put a proper e-mail address in the root account’s .forward file. Then all of root’s mail will get sent to that address. This may not be an easy thing to do, however, depending on your Internet service provider, so I’m not going to discuss it any further. :slight_smile: )

Does anyone know if you can configure Apple’s Mail.app to access your local Unix mail spool file (what mailx accesses)?

1 Like

That’s interesting, thanks. But it doesn’t address my question. Since my output is also /dev/null, can I safely delete the offending items from LaunchDaemons?

If there is no mail server running, then apps that try to send mail will and up writing the messages to an mail queue, which will never be processed.

Even if that processing simply results in deleting the file (as is the case if the recipient is forwarding to /dev/null), it must be done.

If your own CommuniGate mail server is able to process these local mail queues, then I see no reason why you can’t disable Postfix. I’m a bit surprised, however, that CommuniGate’s installer doesn’t automatically do this. (Maybe it did when it was first installed, and then a new macOS installation re-activated it?)

I would suggest that the next step should be to ask in CommuniGate’s support forums to see what the recommended solution is.

Right, that’s what I want to do. But how do I accomplish that?

I just configured a new Mac mini running MacOS 12.2, so I took a peek and none of those postfix processes was running. According to an older version of CGP’s installation instructions:

Note: The Installer packs the startup directory /System/Library/StartupItems/Sendmail into the /System/Library/StartupItems/Sendmail.tar, and the /System/Library/StartupItems/Postfix directory into the /System/Library/StartupItems/Postfix.tar archive, so the legacy sendmail and postfix daemons will not auto-start.

However, I think something about startups has changed in MacOS 11+, because that folder is empty. Instructions for Linux and FreeBSD don’t lead to usable steps to stop postfix.

So how do I disable postfix from starting up?

Hmmm…Let me ask differently: would it safely solve my problem to just pack up these two files?


That may not be possible. I note that these files (on my big Sur system) have large inode numbers:

$ ls -li /System/Library/LaunchDaemons/*postfix*
1152921500312373849 -rw-r--r--  1 root  wheel  578 Jan  1  2020 /System/Library/LaunchDaemons/com.apple.postfix.master.plist
1152921500312373851 -rw-r--r--  1 root  wheel  554 Jan  1  2020 /System/Library/LaunchDaemons/com.apple.postfix.newaliases.plist

This (combined with the fact that they’re in /System/Library) means that these files belong to the signed system volume. Which means they can’t be edited by anything short of a macOS system updater.

In which case, CommuniGate may need to release an update that allows it to work with (or alongside) Postfix.

But before I conclude there’s nothing you can do, let’s see if maybe we can do something without deleting the Launch Daemon. Looking at the LaunchDaemon file on my system, I see:

$ cat /System/Library/LaunchDaemons/com.apple.postfix.master.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

A breakdown of the above (type man launchd.plist from a terminal to see documentation for the contents) is:

  • Label. Identifies the app
  • Program. This is what gets executed: /usr/libexec/postfix/master
  • ProgramArguments. The parameters passed to the program.
    In this case, it is running /usr/libexec/postfix/master -e 60, telling the master Postfix master process to quit after 60 seconds of idle time. Any child processes (for actually processing mail) will quit on their own when they finish what they are doing.
  • QueueDirectories. This is a directory that, when not empty, will direct launch service to keep the process alive. In this case, it means it will run whenever there is something in /var/spool/postfix/maildrop.
  • AbandonProcessGroup. When a job dies, launchd normally kills any remaining processes in the same process group. Setting the key to true prevents that (so the child processes won’t be killed when the master terminates).

So, what all this means is:

  • Whenever there is something in the /var/spool/postfix/maildrop directory, the Postfix master process will start. It will process the contents (probably spawning child processes as necessary) and will quit when done (after 60 seconds).
  • I’m not sure if it will auto-launch at bootup. It might.

So, check your /var/spool/postfix/maildrop directory. If there are any files in there, move them elsewhere or delete them. That will probably stop Postfix from running.

Of course, there is still the question about why it is constantly running. I can only guess that there is some message in that maildrop directory that it can’t process (maybe sent to an Internet address and there is no valid configuration for Internet mail delivery) and can’t bounce back (maybe from an Internet address?) so it just sits there with Postfix repeatedly trying and failing to process it.

And then there is the “newaliases” launch daemon:

$ cat /System/Library/LaunchDaemons/com.apple.postfix.newaliases.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">

This launch daemon will launch itself whenever either:

  • The file /etc/aliases.db does not exist
  • The file /etc/postfix/aliases is modified

When one of these conditions is true, it will run /usr/bin/newaliases, which generates the /etc/aliases.db database from the contents of /etc/postfix/aliases.

Unless you are modifying /etc/postfix/aliases, this shouldn’t run at all, (after the first bootup after system installation, so it can create the initial version of the database).


Wow! Thorough answer, thank you!

22-08-10 17:30 iGib 🍸 sudo sudo ls -la /var/spool/postfix/maildrop
total 0
drwx-wx---   6 _postfix  _postdrop  192 Aug 10 12:00 .
drwxr-xr-x  16 root      wheel      512 Jul 14 03:48 ..
-rw-r--r--   1 root      _postdrop    0 May 21  2021 04D7D2B78F35
-rw-r--r--   1 root      _postdrop    0 May 21  2021 6F3612B78CF0
-rw-r--r--   1 root      _postdrop    0 May 14  2021 8AC2B29EEF50
-rw-r--r--   1 root      _postdrop    0 May 14  2021 9848D29EE3EA

Since they were zero-length, I just got annoyed and summarily decided to delete them:

22-08-10 17:32 iGib 🍸 sudo rm /var/spool/postfix/maildrop/04D7D2B78F35
22-08-10 17:33 iGib 🍸 sudo rm /var/spool/postfix/maildrop/6F3612B78CF0
22-08-10 17:34 iGib 🍸 sudo rm /var/spool/postfix/maildrop/8AC2B29EEF50
22-08-10 17:34 iGib 🍸 sudo rm /var/spool/postfix/maildrop/9848D29EE3EA
22-08-10 17:34 iGib 🍸 sudo ls -la /var/spool/postfix/maildrop
total 0
drwx-wx---   2 _postfix  _postdrop   64 Aug 10 17:34 .
drwxr-xr-x  16 root      wheel      512 Jul 14 03:48 ..

I still had to force-quit CommuniGate Pro (which was the original symptom/problem), but after I relaunched it, I no longer see those pesky processes, nor do I see anything else with user _post*. Time will tell, but I think that did it, thank you very much!


Disable the Postfix launchdaemons. You cannot alter the plists directly thanks to SIP, of course, but you can still set up overrides to disable them:
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.postfix.master.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.postfix.newaliases.plist

For your purposes this is sufficient: the daemons no longer listen to the network and your other MTA can now run. Postfix does not restart to service the postdrop queue, which usually happens when the sendmail binary is invoked to submit mail locally. Of course, now you must ensure that this does not happen so that mail gets queued and then forgotten about; run sudo /usr/bin/mailq to see what your queue looks like now (ignore the warning about the system being down). If you are not comfortable doing that for any reason, then you could also alter /etc/postfix/master.cf and comment out the smtp inet and submission inet lines, which will keep the rest of the machinery running so sendmail still works. This is the absolute minimum; if you need anything more complex, then I refer you to the fabulous documentation included in the man pages on the system and in /usr/share/doc/postfix or on the www.postfix.org website.

Postfix was a keen upstart when it was introduced, with Sendmail and Exim for its main (credible) competition, and Apple made the right choice in using it for its server product, but now it just looks absurdly heavy and tired in light of always-on connections and big, popular free mail providers, on single-user systems. IMNSHO they should replace it with OpenSMTPD, leaving configuration entirely up to the admin. It is far, far easier to use than Postfix for the sorts of things people do with MTAs in common cases, and the default really cannot be improved upon for a directly-connected Internet host. (The default Postfix configuration, too, will do end-to-end delivery, with all the problems that entails for remote delivery on most consumer ISPs.) It’s too bad that SIP protects the newaliases, sendmail and mailq binaries, and mailwrapper(8) (or a similar system using symlinks) isn’t supported, so that OpenSMTPD (or another mailer of your choice) can’t be installed manually and set up as the default MTA; the best you can do is reconfigure your applications to use the sendmail binary for the MTA installed at an alternate location. This precludes using any included programs in macOS, which hardcode the Postfix binary location at /usr/sbin/sendmail. (Please reference FB9578556 if you send feedback about this, thanks.) Anyway, it’s clear that Apple aren’t updating it; the version of Postfix in macOS 12.5 is 3.2.2, which was also shipped with Mojave. If they don’t want to maintain a big MTA with the system, they should ship a smaller one and/or let the user replace it.

AFAIK, no Mac MUA reads local spools. I remember discussion about MailMate getting support for that, and I’d love at least maildir support, but so far it’s not there. One does not normally see use of the “sendmail” command at all on macOS, unless one spawns mail or uses cron, which I suppose qualify as sufficiently off-road to be expected. There are other choices for sendmail besides full-blown MTAS; for instance, ssmtp is just a sendmail interface that passes mail directly off to a configured SMTP server, with no daemon, alias file, or queue. Most textmode MUAs, like mutt and alpine, already have built-in SMTP support. (I am now using mblaze(7), which doesn’t, for essentially philosophical reasons.) If you want a (native) GUI mailer to work with a locally-configured MTA, you’ll have to install a POP3 or IMAP daemon as well (dovecot, cyrus, Courier, solid-pop, etc).


Thanks for your in-depth response!

Empty! And no sign of processes master, qmgr, or pickup, nor any with user _postfix. I think with all the help here, I’ve tamed the beast. Many thanks to both of you.

1 Like

Sadly, this seems to be true. Mozilla Thunderbird removed “Movemail” support (the mechanism for accessing local spools) in version 91.0 (August 2021).

I suppose you could install the previous version (78.14.0) and not upgrade if you require support. But I would be concerned about security problems that could result from using an old mail app.

It’s probably best (until/unless something better comes along) to just use the command-line mail command or (as you suggest) install an IMAP daemon if you need access to your local spool.

1 Like

Blimey, I didn’t realise it was that recent! This Mozilla bug makes for very painful and tragic reading, but on the positive side, it does look as though common sense has ultimately prevailed and they’ll bring the feature back, so soon you’ll have an option that doesn’t require installing yet more software. I’d forgotten, too, that GNU mailutils comes with daemons that you could use as well, albeit that they are rudimentary compared to more robust options.

1 Like