On Mon, 6 Apr 2020 at 09:44, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote: > > On Mon, Apr 06, 2020 at 08:21:32AM +0100, Dominic Raferd wrote: > > > Using setting 'smtp_tls_security_level = may' (postfix 3.3.0) is there > > a reliable way to see from log which outgoing emails were sent in the > > clear i.e. *not* using TLS? > > Yes, provided you don't lose too many log messages[1], and your logging > subsystem does not reorder them[1], set: > > smtp_tls_loglevel = 1 > > and use "collate": > > https://github.com/vdukhovni/postfix/tree/master/postfix/auxiliary/collate > > whose output you'd send to the attached Perl script. On my system for > example: > > # bzip2 -dcf $(ls -tr /var/log/maillog*) | perl collate | perl tlstype.pl > > -- > Viktor. > > [1] If your system is suffering under the yoke of systemd-journald, you > should strongly consider enabling the built-in logging in recent > versions of Postfix to bypass systemd's broken logging subsystem. > > - It is single-threaded, performs poorly on multi-cpu servers and > may not be able to keep up with all the messages generated on a > busy multi-cpu system. > > - By default has low message rate limits, dropping messages > that exceed the limits. > > - Listens on stream socket rather than a dgram socket, which > breaks message ordering from multi-process systems like > Postfix.
Thanks Viktor, collate.pl and tlstype.pl work perfectly for this task, and show that there are very few such messages (and hardly any that are not automated replies to low-quality incoming mails). I will keep in mind what you say about systemd and logging. The only 'systemd:.*suppress' messages I see are very occasionally in the system log and don't relate to any mail activity, but our mail servers are not heavily loaded. Our mail log file, where postfix messages end up, is also a destination for logs from other mail-related services, all handled by (systemd via) rsyslog, and I guess if postfix was doing direct logging it should have exclusive rights to a log file?
