
This shows a bunch of bullshit:
log show --last 1d --predicate 'processImagePath contains "postfix"' --debug
But nothing useful like, for example, any lines relating to messages being received, queued, or delivered.
macOS 10.13 or 10.14. And note that /System/
Haven't run it on Mac for a couple of years, but I recall the default location was /var/log/mail.log .
Though I was using postfix from MacPorts. YMMV.
If it's not there, give this a go: http://www.postfix.org/MAILLOG_README.html
Nope.
Have you tried:
log stream --predicate '(process == "smtpd") || (process == "smtp")' --info
You may need to reset logging for postfix:
sudo serveradmin settings mail:postfix:log_level = “debug”
sudo serveradmin settings mail:postfix:mail_events_log_level = “debug”
Yeah this is the right answer, or at least the start. I had to do a similar command on my parents Mac to log ssh attempts so I could watch for attacks and such. Welcome to the new unified log in macros that’s going the same route as systemd (and windows) with binary logs by default and no plain text ones unless you enable them.
Wait until you hit Catalina and find things like how most of ‘ is mounted read-only, broke. H auto mount setup. Finally got that working by mounting under /System/Volumes/Data/autofs now but the damn /etc/auto_master file still gets reset every reboot.
Yes, I did try the first google hit. No, "serveradmin" does not exist on 10.13 or 10.14.
serveradmin
only exists as part of macOS Server, which used to be its own OS install, but is now a $200 add-on to regular macOS and available in the Mac App Store. It has a slick albeit simplistic management GUI for things like Postfix, and when you install it, it points the postfix binaries at a different config that is generated by the management app.serveradmin
is a cli for that management app.i'm going to add this here in the doofus thread because it's probably also doofus and "works for me". but there is one thing in your problem statement which does not appear to be completely universal:
$ sw_vers
ProductName:Mac OS X
ProductVersion:10.13.6
BuildVersion:17G8030
$ ls -l /System/Library/LaunchDaemons/com.apple.postfix.master.plist
-rw-r--r-- 1 root wheel 578 Feb 18 2018 /System/Library/LaunchDaemons/com.apple.postfix.master.plist
u+w or not, you can't touch the contents of /System.
joshua@bruges:~$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.6
BuildVersion: 18G4032
joshua@bruges:~$ ls -l /System/Library/LaunchDaemons/com.apple.postfix.master.plist
-rw-r--r-- 1 root wheel 578 Feb 22 2019 /System/Library/LaunchDaemons/com.apple.postfix.master.plist
joshua@bruges:~$ sudo touch /System/Library/LaunchDaemons/com.apple.postfix.master.plist
touch: setting times of '/System/Library/LaunchDaemons/com.apple.postfix.master.plist': Operation not permitted
Although, I guess, you could disable SIP, and then you can write to /System to your heart's content...
It's a hassle, but that's intentional, and is the clean approach. Disable SIP while fiddling to figure the right changes, reenable once you're happy with it.
That suggestion is so completely impractical as to be worthless. "Disable SIP" means ether "and then never upgrade your software again", or "boot single-user and re-apply your changes every time you update". And you can't boot single-user remotely, either, so that's fun.
cool. sorry for the interruption
I solved this in 10.15 by disabling the postfix that comes with macos and installing postfix via homebrew and launch it via
/usr/local/libexec/postfix/master -c /usr/local/etc/postfix/ wrapped up in a plist stuffed under /Library/LaunchDaemons.
Before that, in 10.13 I had it working by using launchctl to stop the System launch agent and then loading and starting my own copy of the plist pointing to the config files I wanted. You can copy the com.apple.postfix.master.plist from /System/Library/LaunchDaemons to /Library/LaunchDaemons/org.postfix.master.plist and then use launchctl to load that one. /Library/LaunchDaemons can be modified.
sudo launchctl stop /System/Library/LaunchDaemons/com.apple.postfix.master.plist
sudo launchctl remove /System/Library/LaunchDaemons/com.apple.postfix.master.plist
sudo launchctl load /Library/LaunchDaemons/org.postfix.master.plist
First You'll need to work out the program arguments in the plist, this might help:
https://apple.stackexchange.com/questions/110644/getting-launchd-to-read-program-arguments-correctly
Copy _everything_ from /etc/postfix/ to /usr/local/etc/postfix/
You will need to _unload_ and _reload_ after every system update.
i forgot to mention, after using the homebrew version, maillog_file in main.cf works to set /var/log/mail.log
postconf is still broken because...shrug.
I only use this so all mail from mail.app and from mailx will be smart routed to my mailer, I am not getting mail in this config.
ymmv
Here on 10.15.2, this works:
~/.logrc
Then
log stream --predicate postfix
gives me what I would have expected from maillog. This is really just a variation on what you're already doing, but I also ransudo log config --reset
to make sure I don't have any top-level filters going. It looks likesyslogd
or whateversyslog()
is sending to is stripping away 'mail' as the log facility, so the output oflog show --style json
looks like:The only reasonable thing I see to filter on in there is
processImagePath
, which you are already trying. I would have expectedsubsystem
to becom.apple.mail
or something, because that's what/etc/asl/com.apple.mail
calls itself while matching onFacility = mail
.The only thing I can think of is that maybe there was a more aggressive push to migrate from
asl
to the “unified logging system” AKAos_log()
on 10.15, such that callingsyslog()
is more directly translating to anos_log()
call without going throughsyslogd
, but in that case I would expect those logs to hit/var/log/mail.log
viaasl.conf
.I didn't change the local postfix config at all, and I just did
sudo postfix start
and thendate | mail -s test sethk
. That won't exercisesmtpd
, but at least I see the local delivery logs.asl stopped working completely a few years ago (the API calls return -1/ENOTSUPP). I think in 10.13?
In that case, I wonder whether current
syslogd
is even reading/etc/asl.conf
anymore. Anyway, I would be surprised if Postfix delivery logs are somehow falling through the cracks and 10.13 or 10.14, but I guess I've been surprised before.Meant to say in 10.13 and 10.14.