Emails not sending

ruf-r
(jmccollum) #1

Recently (in the last few weeks, I am not sure exactly when), Octopus has stopped being able to send emails through Office 365. When I attempt to send a test email, I get the following result:

Task ID:        ServerTasks-162298
Related IDs:    
Task status:    Failed
Task queued:    Friday, 07 June 2019 7:38:55 AM -05:00
Task started:   Friday, 07 June 2019 7:38:55 AM -05:00
Task completed: Friday, 07 June 2019 7:38:55 AM -05:00
Task duration:  less than a second
Server version: 2019.5.7+Branch.tags-2019.5.7.Sha.b471c047e851f3a34ed998ddf3d82616ef948fd9
Server node:    BUILDSERVER

                    | Failed: Send test email
07:38:55   Verbose  |   SMTP host: smtp.office365.com
07:38:55   Verbose  |   SMTP port: 587
07:38:55   Verbose  |   SSL enabled: True
07:38:55   Verbose  |   SMTP login: [redacted]
07:38:55   Verbose  |   SMTP password: ********
07:38:55   Verbose  |   From: [redacted]
07:38:55   Verbose  |   To: [redacted]
07:38:55   Info     |   Sending test email...
07:38:55   Fatal    |   An error occurred while attempting to establish an SSL or TLS connection.
                    |   One possibility is that you are trying to connect to a port which does not support SSL/TLS.
                    |   The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons:
                    |   1. The server is using a self-signed certificate which cannot be verified.
                    |   2. The local system is missing a Root or Intermediate certificate needed to verify the server's certificate.
                    |   3. The certificate presented by the server is expired or invalid.
                    |   See https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate for possible solutions.
                    |   MailKit.Security.SslHandshakeException
                    |   at MailKit.Net.Smtp.SmtpClient.ConnectAsync
                    |   at MailKit.Net.Smtp.SmtpClient.Connect(String host, Int32 port, SecureSocketOptions options, CancellationToken cancellationToken)
                    |   at MailKit.MailService.Connect(String host, Int32 port, Boolean useSsl, CancellationToken cancellationToken)
                    |   at Octopus.Core.Util.SmtpClient.SmtpClientWrapper.CreateSmtpClient(SmtpConfiguration configuration, CancellationToken token)
                    |   at Octopus.Core.Util.SmtpClient.SmtpClientWrapper.Send(SmtpConfiguration configuration, MailMessage message, CancellationToken token)
                    |   at Octopus.Server.Orchestration.ServerTasks.TestEmail.TestEmailTaskController.Execute()
                    |   at Octopus.Server.Orchestration.ServerTasks.RunningTask.RunMainThread()
                    |   --Inner Exception--
                    |   The handshake failed due to an unexpected packet format.
                    |   System.IO.IOException
                    |   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
                    |   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
                    |   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
                    |   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
                    |   at MailKit.Net.Smtp.SmtpClient.ConnectAsync
                    | 

I did find a couple other threads that appear to be the same, however:

  • I have confirmed the password for the sending account has not changed
  • I have confirmed that the host and port configuration is correct
  • I have confirmed that the certificate on the server is still valid (and is outside our control anyway)
  • I have attempted to use mailtrap.io to see if it is directly related to Office 365 or not. I receive the same message
(Shannon Lewis) #3

Hi,

Thanks for getting in touch, and unfortunately this is a known issue. We did release a patch to address this recently but found that it didn’t work for all providers, including Office 365. See this issue on GitHub. Another update has been made and will be available in 2019.5.9, which should ship in the next day or so.

Apologies for the inconvenience caused.

Regards
Shannon

(jmccollum) #4

Thanks for the reply.

I’ve been able to update Octopus to 2019.5.10, but I am still having issue, with the same error message. It also seems to still be the case with mailtrap.io:

Task ID:        ServerTasks-163491
Related IDs:    
Task status:    Failed
Task queued:    Thursday, 13 June 2019 9:51:00 AM -05:00
Task started:   Thursday, 13 June 2019 9:51:01 AM -05:00
Task completed: Thursday, 13 June 2019 9:51:01 AM -05:00
Task duration:  less than a second
Server version: 2019.5.10+Branch.tags-2019.5.10.Sha.5ecc2b36ef84c4aa9573836bcf49eb77376b88ec
Server node:    BUILDSERVER

                    | Failed: Send test email
09:51:01   Verbose  |   SMTP host: smtp.mailtrap.io
09:51:01   Verbose  |   SMTP port: 587
09:51:01   Verbose  |   SSL enabled: True
09:51:01   Verbose  |   SMTP login: [redacted]
09:51:01   Verbose  |   SMTP password: ********
09:51:01   Verbose  |   From: [redacted]
09:51:01   Verbose  |   To: [redacted]
09:51:01   Info     |   Sending test email...
09:51:01   Fatal    |   An error occurred while attempting to establish an SSL or TLS connection.
                    |   One possibility is that you are trying to connect to a port which does not support SSL/TLS.
                    |   The other possibility is that the SSL certificate presented by the server is not trusted by the system for one or more of the following reasons:
                    |   1. The server is using a self-signed certificate which cannot be verified.
                    |   2. The local system is missing a Root or Intermediate certificate needed to verify the server's certificate.
                    |   3. The certificate presented by the server is expired or invalid.
                    |   See https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate for possible solutions.
                    |   MailKit.Security.SslHandshakeException
                    |   at MailKit.Net.Smtp.SmtpClient.ConnectAsync
                    |   at MailKit.Net.Smtp.SmtpClient.Connect(String host, Int32 port, SecureSocketOptions options, CancellationToken cancellationToken)
                    |   at MailKit.MailService.Connect(String host, Int32 port, Boolean useSsl, CancellationToken cancellationToken)
                    |   at Octopus.Core.Util.SmtpClient.SmtpClientWrapper.CreateSmtpClient(SmtpConfiguration configuration, CancellationToken token)
                    |   at Octopus.Core.Util.SmtpClient.SmtpClientWrapper.Send(SmtpConfiguration configuration, MailMessage message, CancellationToken token)
                    |   at Octopus.Server.Orchestration.ServerTasks.TestEmail.TestEmailTaskController.Execute()
                    |   at Octopus.Server.Orchestration.ServerTasks.RunningTask.RunMainThread()
                    |   --Inner Exception--
                    |   The handshake failed due to an unexpected packet format.
                    |   System.IO.IOException
                    |   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
                    |   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
                    |   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
                    |   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
                    |   at MailKit.Net.Smtp.SmtpClient.ConnectAsync
                    |
(Shannon Lewis) #5

I’d missed this line in the stack trace previously, The handshake failed due to an unexpected packet format.. So this could be a slightly different issue to the one I mentioned.

I found a MailKit issue related to that message which points at port numbers. Would you be able to try changing the port number from 587 to 465?

Regards
Shannon

(jmccollum) #6

Using port 465 with Mailtrap results in the same message with SSL enabled, and appears to work if I disable SSL, though I think with my configuration things are being blocked on delivery.

Office 365 seems to get a little further, but results in a connection timeout, regardless if SSL is enabled or not.

07:04:54   Info     |   Sending test email...
07:05:57   Fatal    |   A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 52.96.9.178:465
                    |   System.Net.Sockets.SocketException
                    |   at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
                    |   at MailKit.Net.SocketUtils.ConnectAsync
                    |   at MailKit.Net.SocketUtils.ConnectAsync
                    |   at MailKit.MailService.ConnectSocket
                    |   at MailKit.Net.Smtp.SmtpClient.ConnectAsync
                    |   at MailKit.Net.Smtp.SmtpClient.Connect(String host, Int32 port, SecureSocketOptions options, CancellationToken cancellationToken)
                    |   at MailKit.MailService.Connect(String host, Int32 port, Boolean useSsl, CancellationToken cancellationToken)
                    |   at Octopus.Core.Util.SmtpClient.SmtpClientWrapper.CreateSmtpClient(SmtpConfiguration configuration, CancellationToken token)
                    |   at Octopus.Core.Util.SmtpClient.SmtpClientWrapper.Send(SmtpConfiguration configuration, MailMessage message, CancellationToken token)
                    |   at Octopus.Server.Orchestration.ServerTasks.TestEmail.TestEmailTaskController.Execute()
                    |   at Octopus.Server.Orchestration.ServerTasks.RunningTask.RunMainThread()

If it helps, the settings documented by O365 indicate that SMTP is only over port 587, with a STARTTLS encryption method.

(jmccollum) #7

Going down that thread a little further, it appears disabling TLS in Octopus allows O365 to work again, which is a bit counterintuitive.

I suppose as long as it works now, I won’t really argue with how it needs to get there. Thanks for the assistance!

(Shannon Lewis) #8

Sorry, we found out late on Friday that the fix that had gone in to 2019.5.9 had been accidentally reverted in 2019.5.10. The fix will be reapplied in 2019.5.11.

With the fix, having the SSL unchecked will mean the Octopus falls back to TLS if it can, so the communication is still secured.

Apologies for the mix up.

Shannon

(system) closed #9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.