UTM SMTP TLS1.2 enabled - SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol - No NDR to sender

Hallo Dennis and welcome to the UTM Community!

You don't have to dig through the logs manually.  To get an ordered list of the rejections in March 2021, execute the following at the command line:

zgrep 'SSL23_GET_CLIENT_HELLO' /var/log/smtp/2021/03/*|grep -oP 'from .*? \['|sort -n|uniq -c

Or to just see the ones from 16 March through 22 March:

zgrep 'SSL23_GET_CLIENT_HELLO' /var/log/smtp/2021/03/smtp-2021-03-{16,22}.log.gz|grep -oP 'from .*? \['|sort -n|uniq -c

That's what I recommend doing every week or two after enabling a minimum of TLS v1.2.  I just tried that on our SMTP Proxy and see that mails from almost 200 entities have been rejected so far in March - every one likely would have been stopped by anti-spam.  When you see a customer/supplier in the list, email them about their exposure so that they know they need to upgrade.  You'll be doing them a favor since TLS v1.2 has been required in Germany and all of the EU for years as a part of GDPR.

Cheers - Bob

Hi Bob,

thanks for hint using zgrep. I did it old school and downloaded the archived log files for march and worked through it with notepad++.

Anyway, i would just described what i did and what further questions came up with this:

I have searched for  SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol through march and got about 54.000 results. After removing plain IP's Blacklisted Domains and other stuff i could reduce this to about 40 domains (so i had 40 external sender and 40 internal receivers). So my understanding up to this point was, that everyone of this domains is dropped because they are using older protocols. Then i took every of the 40 domains (senders) and then run again a search against march. The result was that for every domain there were at least 1 or more successful email deliveries (email passed) between sender and receiver using TLS1.2 (accept for the Customer domain we initially started). So the question would be, why are some connections are dropped where others are being successfully established from one email domain?  

 One thing i didn't think of:  

 My colleague was the one in contact with the said customer. After some troubleshooting my colleague created an SMTP exception (EMail Protection - SMTP - Exceptions) for the customer domain and skipped every check. After doing this, the customer was able to send mails. I didn't think of this in the beginning but skipping checks shouldn't solve TLS Protocols errors. So why did this happens or do i misinterpret  the errors  mentioned above?

Dennis

Domains will often use multiple servers.  It's not unusual for one or two to be missed for a TLS upgrade.  Were the delivered emails from the same IPs as ones that were rejected?

Cheers - Bob

Hi Bob,

i have picked the following mail domain mail.universa-hh.de as a sample (without checking all the others). My understanding is, that the first connection is dropped as Harsh said, but then the connection is established using TLS1.2 without falling back to plaintext. 

There are a lot more samples for this domain. The first connection is always dropped, then the connection is established right after and the email is passed.

Dennis

For incoming mail, recovery from this event is the responsibility of the remote server.   If it chooses to fall back to unencrypted and you have that allowed, the message will be accepted.  If they simply retry with another STARTTLS session, the message will fail repeatedly until the sending server gives up.

The U.S. still has a lot of sloppy senders, so running with either mandatory encryption, or encryption optional with TLS1.0 disabled, caused lost traffic that my users want.

Doug and I are in the USA, Dennis, so TLS v1.2 is not a requirement for us.

I asked the question I did because I thought you were experiencing random rejections of mail from a domain and might see different sending IPs on different days.

In the sample you showed us, it appears that the server at 80.147.160.223  Isn't configured to use only TLS v1.2.  The postmaster for UNIVERSA Hausverwaltungsgesellschaft might not be aware of that.

Cheers - Bob

Doug and I are in the USA, Dennis, so TLS v1.2 is not a requirement for us.

I asked the question I did because I thought you were experiencing random rejections of mail from a domain and might see different sending IPs on different days.

In the sample you showed us, it appears that the server at 80.147.160.223  Isn't configured to use only TLS v1.2.  The postmaster for UNIVERSA Hausverwaltungsgesellschaft might not be aware of that.

Cheers - Bob