Downgrading didnt solve it... something f-ed up the server during upgrade.

Opening a server down ticket as we speak.

EDIT: Gmail accounts is received fine. Looks like related to office365/outlook.com emails.

It was the same mail send to multiple recipients one shot ? Or multiple mails ?

Did you check related SMTP and Delivery logs for the corresponding transactions ?

It's kinda worrying...

e have a client that has sent multiple mails from Office365 and they dont get through. According to SMTP they dont even reach the SM server.

It was one mail to 3 recipients all on the same server. Only one got through.

Nothing in the SMTP and Delivery logs.

seeing shitloads of these in the logs.

[2024.11.27] 11:17:38.448 [40.92.50.32][38523489] rsp: 220 smartermail.cloudpros.dk
[2024.11.27] 11:17:38.448 [40.92.50.32][38523489] connected at 27-11-2024 11:17:38
[2024.11.27] 11:17:38.448 [40.92.50.32][38523489] Country code: IE
[2024.11.27] 11:17:38.468 [40.92.50.93][306180] cmd: STARTTLS
[2024.11.27] 11:17:38.468 [40.92.50.93][306180] rsp: 220 Start TLS negotiation
[2024.11.27] 11:17:38.477 [40.92.50.32][38523489] cmd: EHLO EUR02-DB5-obe.outbound.protection.outlook.com
[2024.11.27] 11:17:38.479 [40.92.50.32][38523489] rsp: 250-smartermail.cloudpros.dk Hello [40.92.50.32]250-SIZE 139810133250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250-DSN250 OK
[2024.11.27] 11:17:38.508 [40.92.50.32][38523489] cmd: STARTTLS
[2024.11.27] 11:17:38.508 [40.92.50.32][38523489] rsp: 220 Start TLS negotiation
[2024.11.27] 11:17:38.578 [40.92.50.93][306180] cmd: QUIT
[2024.11.27] 11:17:38.578 [40.92.50.93][306180] rsp: 221 Service closing transmission channel
[2024.11.27] 11:17:38.578 [40.92.50.93][306180] disconnected at 27-11-2024 11:17:38
[2024.11.27] 11:17:38.653 [40.92.50.32][38523489] cmd: QUIT
[2024.11.27] 11:17:38.653 [40.92.50.32][38523489] rsp: 221 Service closing transmission channel
[2024.11.27] 11:17:38.653 [40.92.50.32][38523489] disconnected at 27-11-2024 11:17:38

When negotiating TLS it fails.

Outbound is working fine. Only inbound is affected.

Could it be that the certificate presented by your smarternail doesn't match the MX host name defined for your customer domain or is expired? 

Maybe Outlook is applying strict certificate checks and if it doesn't pass it aborts the delivery attempt? 

It should be fine. Responds as it should

I did some testing on this today under our previous public release to confirm I can receive from Outlook.com/Hotmail.com/Gmail.com/etc beforehand, then upgraded to 9091 to recheck the same deliveries and was not able to confirm these issues.

Jereming is on it Kyle. Its mega weird! Microsoft terminates the session after the TLS negotiation.

Hello, 

Looking at this snippet provided. 

[40.92.50.93][306180] cmd: STARTTLS
[40.92.50.93][306180] rsp: 220 Start TLS negotiation
[40.92.50.93][306180] cmd: QUIT
[40.92.50.93][306180] rsp: 221 Service closing transmission channel
[40.92.50.93][306180] disconnected at 27-11-2024 11:17:38

Makes me think that they do not like your SSL/TLS ciphers/version. We would throw a stack trace on our end if we did not like them but to get a cmd: QUIT after that is defiantly odd. 

A Wireshark capture should be able to track down the ciphers provided, may shed some light on the issue. 

Hey Brian, 

Given that it's quitting after trying to start TLS we can come to the assumption that something is going on causing it to fail during the TLS negotiation. A few things I would double check is that your server supports TLS 1.2 and 1.3 and it has the correct cipher suites enabled. You can use IIS crypto and click best practices. 

I looked at your server using OpenSSL, and it looks like you're missing three potential cipher suites they could use. 

Here's how you can test it yourself

openssl s_client -starttls smtp -cipher ECDHE-ECDSA-AES128-GCM-SHA256 -connect yourserverhost.com:25

openssl s_client -starttls smtp -cipher DHE-RSA-AES256-GCM-SHA384 -connect yourserverhost.com:25

openssl s_client -starttls smtp -cipher DHE-RSA-AES128-GCM-SHA256 -connect yourserverhost.com:25

I would start with enabling those and checking your TLS 1.3 support and then go from there. If all else fails you maybe able to reach out to Microsoft and ask them why they are quitting the connection. 

Kind Regards, 

Server 2016 cant run TLS 1.3. I will go ahead and check the ciphersuites. It worked yesterday. We renewed our certificate sunday.

This is what is on the server

So the 3 you have suggested is allready there running IIScrypto.

Mxtoolbox reports the server is fine and everything is working.

This is Chrome

Is it possible that Gmail / Outlook might be experimenting with stronger TLS 1.3 requirements and their fallbacks aren't working correctly ATM? 

We are in the same boat, running Windows 2016 with not 1.3 support, but haven't heard of any issues, yet. We are also running a lot of older ciphers because of legacy equipment (fax machines and such)

Hi Brian. Your ssl test above seems to check the https service, you should check the certificate presented on port 25 instead of 443. But it looks like that is not the problem in this case, but the cert presented on port 25 seems fairly new. Did you update your DANE record with the new cert hash? It seems there is a problem.

RETO!! You are a life saver! Totally forgot that when I renewed certificates.

Changed the TLSA record to the new certificate and booom. Mails arrived.

THANK YOU!!

Hi Brian, you are welcome. Good you showed the hostname to have a look into it. Now, I'm happy to upgrade to the latest version too.