A temporary work-around might be to set "tls_required_enable = no".
with
$ postconf mail_version
mail_version = 3.10.5
i've a relay from this postfix server, to another
$ cat master.cf
...
relay-ofc unix - - n - - smtp
-o syslog_name=postfix/relay-ofc
-o smtp_helo_name=relay-ofc.mx10.example2.net
-o smtp_bind_address=$var_ip03
...
-o smtp_tls_loglevel=1
-o smtp_tls_security_level=encrypt
-o smtp_tls_wrappermode=yes
-o smtp_tls_policy_maps=lmdb:/etc/postfix/relay_tls_policy
-o smtp_tls_fingerprint_digest=sha256
-o inet_protocols=ipv4
...
$
with that, i recently noticed queued system messages piling up.
normal/external mail flows as usual.
troubleshooting, found this thread.
different use case, but seems it's a relevant issue.
here
$ postqueue -p
Mail queue is empty
sending a test
$ sendmail -t <<EOF
To: [email protected]
From: [email protected]
Subject: test-notice-trigger
body
EOF
adds to queue
$ postqueue -p
----Queue ID----- --Size-- ---Arrival Time---- --Sender/Recipient------
4dFS0H0GHHz6b* 356 Mon Nov 24 08:51:11 [email protected]
[email protected]
-- 0 Kbytes in 1 Request.
$
logs
$ /bin/tail -n 50 /var/log/postfix/postfix.log | grep -E
'relay-ofc|invalid-user-that-does-not-exist'
2025-11-24T08:51:11.188770-05:00 svr01 postfix/relay-ofc/smtp[23672]:
Verified TLS connection established to int.mx1.example.net[10.0.1.100]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519
server-signature ECDSA (secp384r1) server-digest SHA384 client-signature ECDSA
(secp384r1) client-digest SHA384
2025-11-24T08:51:14.585454-05:00 svr01 postfix/relay-ofc/smtp[23672]: 4dFS0H0GHHz6b:
to=<[email protected]>,
relay=int.mx1.example.net[10.0.1.100]:25, delay=3.6, delays=0.06/0.01/0.36/3.1, dsn=5.1.1,
status=bounced (host int.mx1.example.net[10.0.1.100] said: 550 5.1.1
<[email protected]>: Recipient address rejected: undeliverable
address: host pxf-lmtp.int.mx1.example.net[private/dove-lmtp] said: 550 5.1.1
<[email protected]> User doesn't exist:
[email protected] (in reply to RCPT TO command) (in reply to RCPT TO
command))
2025-11-24T08:51:14.749045-05:00 svr01 postfix/relay-ofc/smtp[23672]:
Verified TLS connection established to int.mx1.example.net[10.0.1.100]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519
2025-11-24T08:51:18.105843-05:00 svr01 postfix/relay-ofc/smtp[23672]:
4dFS0L4TQPz6c: to=<[email protected]>,
relay=int.mx1.example.net[10.0.1.100]:25, delay=3.5, delays=0.02/0/0.19/3.3,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4dFS0P6kT3zWf7C)
$
and won't flush.
adding
-o tls_required_enable=no
to the `relay-ofc` stanza does, in fact, seem to workaround the queueing
$ postfix reload
$ postsuper -d ALL
$ sendmail -t <<EOF
To: [email protected]
From: [email protected]
Subject: test-notice-trigger
body
EOF
$ postqueue -p
Mail queue is empty
logs
$ /bin/tail -n 50 /var/log/postfix/postfix.log | grep -E
'relay-ofc|invalid-user-that-does-not-exist'
2025-11-24T09:01:47.168394-05:00 svr01 postfix/relay-ofc/smtp[26875]: 4dFSDV60hnz6b:
to=<[email protected]>,
relay=int.mx1.example.net[10.0.1.100]:25, delay=0.35, delays=0.06/0.01/0.2/0.08, dsn=5.1.1,
status=bounced (host int.mx1.example.net[10.0.1.100] said: 550 5.1.1
<[email protected]>: Recipient address rejected: undeliverable
address: host pxf-lmtp.int.mx1.example.net[private/dove-lmtp] said: 550 5.1.1
<[email protected]> User doesn't exist:
[email protected] (in reply to RCPT TO command) (in reply to RCPT TO
command))
2025-11-24T09:01:47.343816-05:00 svr01 postfix/relay-ofc/smtp[26875]:
Verified TLS connection established to int.mx1.example.net[10.0.1.100]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519
2025-11-24T09:01:47.597523-05:00 svr01 postfix/relay-ofc/smtp[26875]:
4dFSDW1b6xz6c: to=<[email protected]>,
relay=int.mx1.example.net[10.0.1.100]:25, delay=0.37, delays=0.02/0/0.19/0.16,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4dFSDW3DhBzWf2h)
and queue, again, can be reliably flushed
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
