I encountered troubles with some bad server trying to send me some emails that I desperately need.

The sender always requests STARTTLS but fails to establish a TLS (v1.2+ as supported by my server) connection afterwards. Presumably, it would deliver mail unencrypted to mail servers not announcing that capability.

I can disable TLS globally using smtpd_tls_security_level, but it's really bad, so I'd like to find a setting to disable it only for a given list of remote servers that try to contact me.

Is it even possible?

EDIT: Here is the log from Postfix with smtpd_tls_loglevel = 2:

belette64 postfix/smtpd[145475]: connect from smtp.misconfigured.fr[XX.XX.XX.XX]
belette64 postfix/smtpd[145475]: setting up TLS connection from smtp.misconfigured.fr[XX.XX.XX.XX]
belette64 postfix/smtpd[145475]: smtp.misconfigured.fr[XX.XX.XX.XX]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
belette64 postfix/smtpd[145475]: SSL_accept:before SSL initialization
belette64 postfix/smtpd[145475]: SSL_accept:before SSL initialization
belette64 postfix/smtpd[145475]: SSL3 alert write:fatal:handshake failure
belette64 postfix/smtpd[145475]: SSL_accept:error in error
belette64 postfix/smtpd[145475]: SSL_accept error from smtp.misconfigured.fr[XX.XX.XX.XX]: -1
belette64 postfix/smtpd[145475]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2282:
belette64 postfix/smtpd[145475]: lost connection after STARTTLS from smtp.misconfigured.fr[XX.XX.XX.XX]

2 Answers 2


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:

  1. 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
  1. 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.

  • 1
    Thanks for your solution. I already contacted the support, even before posting this. But I'm a last-minute-guy and I need this email for today :) Anyway, adding a non-TLS server is not a bad idea, but I think I'll use it with firewall rules that redirect the bad actor, so that only them can see the non-STARTTLS header. Dec 7, 2020 at 9:26
  • 1
    Implemented! Using: 10025 inet n - y - - smtpd -o smtpd_tls_security_level=none in master.cf and some firewall rules in nftables: tcp dport 25 ip protocol tcp ip saddr { XX.XX.XX.XX } redirect to :10025 in a prerouting hook table. Don't forget to allow the port too. Dec 7, 2020 at 10:56
  • 1
    Don't forget to set a reminder on when to undo that, so to not reward the person finally fixing it with some really difficult to debug failure ;)
    – anx
    Dec 7, 2020 at 17:35

This should only be set to may. Opportunistic TLS is the best we will get for email for a long time to come.

  • Yes, I know that. I've setup DANE and MTA-STS. But an hospital is trying to send me email using SSL3, so I have to disable it, because it is unsupported in my distribution for a good reason. And I'd like to only disable it for them, not for everyone. Dec 6, 2020 at 21:53
  • 4
    Eh? You should have mentioned the SSL3 bit at the beginning. That's important. Along with any relevant configuration you've done. Though I wouldn't give them much sympathy. They are very likely not delivering to the majority of their mail recipients if they still only use SSLv3, and it really is on them to fix this. Dec 6, 2020 at 21:56
  • Been 2 weeks since I last got a non-spam message via plain smtp (and it was a newsletter nobody would have missed). Here's hoping that long time is not that long any more..
    – anx
    Dec 7, 2020 at 7:20
  • 1
    My bad @MichaelHampton I should have added server log as I did now. Dec 7, 2020 at 10:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .