Disable Postfix server TLS for specific clients
Solution 1:
If you really wanted to work around their negligence, you could add a separate TLS-ignorant server. Have it only talk to a list of known-bad clients (as identified by ehlo or address), and only make it accessible via a higher priority value MX record or firewalling, so to not reduce the security of other clients.
How is this different from just smtp_tls_security_level=may? It will allow a client failing to establish a secure channel (after requesting so with the main MX) a second chance, where it cannot repeat its mistake because the second server does not announce STARTTLS capability.
How to do it? The publish via separate MX record route is safer as it more or less falls back to the common case when your special-case configuration inevitably goes stale, but just port-redirecting on your end needs fewer steps to setup:
- Duplicate your smtpd line in
master.cf, with a different port and extra options (tag the log lines, add a comment for a future admin to understand out why on earth this was done):
smtp inet n - y - - smtpd
10025 inet n - y - - smtpd
-o syslog_name=postfix/smtpd/badstarttls
-o smtpd_tls_security_level=none
-o smtpd_helo_required=yes
-o smtpd_helo_restrictions=pcre:/etc/postfix/helo_badstarttls_allow.pcre,reject
- Redirecting to a different port works via
-A PREROUTING .. -j REDIRECT --to-port ..in iptables; or in nftables:
tcp dport 25 ip protocol tcp ip saddr { XX.XX.XX.XX } redirect to :10025
But that is likely neither the easiest nor the right choice. Pretty much everyone out there sending mail is sending mail that should be transported securely. If you work on special accommodation for breaking best practices, you become complicit in it. Get them to fix it instead.
If they are EU-based, they will even have published a preferred contact method for a role called Data protection officer so it will not be your task to explain the priority of them fixing their setup. All you have to do is notify them of the unmaintained server processing personal data.
Solution 2:
This should only be set to may. Opportunistic TLS is the best we will get for email for a long time to come.