However, Microsoft Office 365 is rejecting a small number of connections that aren’t using TLS 1.2 as they phase out support for the older versions. On occasion, I get a send failure with the error message:
421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit https://aka.ms/smtp_auth_tls.
I can’t reproduce it regularly, because Microsoft is only rejecting a small number of connections for now.
Has anyone else seen this?
Is there reason to believe Xojo SMTPSecureSocket is not using TLS 1.2 for some reason?
Is it limited to Linux deployment?
Are you sure those are coming from your SMTPSecureSocket since it could also be some system got your password. We’ve has such messages also, but not on Xojo’s smtp sockets (when someone tried logging in with stolen details).
Check the email here: https://haveibeenpwned.com to make sure.
Or maybe xojo has a fallback even if you set it to tlsv1.2 that’s not documented ?
Yes, the way the message logs it can only be coming from the SMTPSecureSocket.
This is a SMTPSecureSocket subclass, and the connection details are set in the constructor like this:
Public Sub Constructor()
// Calling the overridden superclass constructor.
// Note that this may need modifications if there are multiple constructor choices.
// Possible constructor calls:
// Constructor() -- From TCPSocket
// Constructor() -- From SocketCore
Super.Constructor
// Setup connection details
me.Address = "smtp.office365.com"
me.Port = 587
me.SSLEnabled = True
me.SSLConnectionType = SSLConnectionTypes.TLSv12
me.SMTPConnectionType = SMTPConnectionTypes.STARTTLS
me.Username = ""
me.Password = ""
End Sub
My concern is that the Xojo implementation isn’t communicating correctly for some reason and that when Microsoft shuts off support for the older protocols the web app will no longer be able to send anything. The current interrupts are already causing a problem.
Perhaps the cert chain is not readable some times?
Do note that we have issues with microsoft servers alot more than other services. For example alot of (non-spam) is marked as spam even if proven otherwise. I couldn’t find any other about this disconnection issue… maybe they ran out of connections
We are starting to see this same issue as well with Office 365 as of about 2 weeks ago.
We are using XOJO2021 R3 in a Desktop Application on a Windows 10 and seeing the same behavior.
I’m with you it doesn’t appear to select and use TLS1.2 when sending the email even though our application is set to send it. It feels like that it is reverting to or defaulting to TLS 1.0.
Can someone check if 2021r1.1 presents this bug, or it was introduced later, or we are living with a fake TLS 1.2 for some time? If Microsoft is correct, this alone deserves a 2021r3.2 release.
The office is now closed for the holiday but this issue is important to me. I was going to wait to make a ticket and email them until Monday in January when they reopen.
I’ve been poking today and I’m able to reproduce this even debugging locally. For some reason the debugger is showing SSLConnectionType as TLSv1 = 3 even though the property has been set to SSLConnectionTypes.TLSv12 as demonstrated above.
The error is clearly telling that tls v1.2 is required. And @Tim_Parnell has it setup like that. Only xojo may give the correct answer or you can wireshark the connection and try an findout what’s happening.
And if you use SSLv23, and both sides want TLSv1.2, then TLSv1.2 is what you will get. But you are including the posssiblity of negotiating downwards if one side does not support TLSv1.2.
Microsoft will probably just work with TLSv1 or TLSV1.1 since i see it’s working mostly. I think their server have some odd setup or are not all conigured correctly but since they also support TLSV1.2 they should just connect.
…
With this in mind, starting in September 2021, we will reject a small percentage of connections that use TLS1.0 for SMTP AUTH. Clients should retry as with any other temporary errors that can occur during submission. Over time we will increase the percentage of rejected connections, causing delays in sending that more and more customers should notice. The error will be:
And my test above, set up to use TLS1.2, does it as expected. The connection is completed, and the protocol is 5 (TLS1.2) instead of auto-downgraded to 3 (as Tim found in his tests).
But… I did it using Windows and 2021R3.1
And I believe Tim P. was testing it using Linux, if this is confirmed, Xojo Linux (or Tim’s Linux environment) may have a problem.
I have Microsoft Windows clients that had problems. The cases varies, but there are 3 fixes, sometimes they need to change the smtp server endpoint in my config to smtp.office365.com because they were using some Microsoft endpoint that Microsoft retired in favor of smtp.office365.com, or they need to set the protocol to TLS 1.2, or a mix of both.
I don’t have a Linux client using it, so I have no experience in SMTP cases isolated to that platform, and it MAY be the case here.
@Andreas_Reichmann Thanks for the link. I do want to find out why SMTPSecureSocket isn’t using TLS 1.2 rather than switch to a legacy endpoint.
@DerkJ Changing the order so SSLEnabled is last did not help. Email headers, when received, show TLS 1.2 as the connection type… I think? Adding a Connect before SendMail did not help.
@Rick_Araujo I was able to reproduce the issue on macOS 11.6.1 in debug mode. The breakpoint is set in the SMTPSecureSocket.ServerError event handler. When that breakpoint is reached that’s when the SSLConnectionType is TLS1 = 3.
