Jump to content

Emails not sending to any addresses at one specific domain


Joshua T M
 Share

Recommended Posts

Hi All,

We are currently experiancing an issue when attempting to send emails from hornbill service manager to a specific customers domain. The emails become stuck in the service manager outbox and remain there for all 10 re-attempts.

We do not experiance this issue when sending from our Microsoft 365 Exchange platform to which the outbound relay connects. According to the customer, they do not receive any notification of an email attempt being made. 

Please find an excert from one of the attempted sends below.
 

2020-11-24 13:33:05

Unable to connect to SMTP server. ChilkatLog: VerifySmtpConnection: DllDate: Sep 28 2020 ChilkatVersion: 9.5.0.84 UnlockPrefix: HRNBLL.CBX102021 Architecture: Little Endian; 64-bit Language: Visual C++ 2019 / x64 VerboseLogging: 0 smtpConnectAndAuthenticate: smtpConnect: smtpHostname: seg.trustwave.com smtpPort: 25 connectionIsReady: Need new SMTP connection --connectionIsReady smtpSocketConnect: socketOptions: SO_SNDBUF: 262144 SO_RCVBUF: 4194304 TCP_NODELAY: 1 SO_KEEPALIVE: 1 --socketOptions --smtpSocketConnect smtpGreeting: readSmtpResponse: SmtpCmdResp: 220 seg.mxsmtp.com ESMTP Trustwave SEG [seg-node-chi-01.trustwave.com] Ready --readSmtpResponse --smtpGreeting ehloCommand: sendCmdToSmtp: SmtpCmdSent: EHLO live.hornbill.com<CRLF> --sendCmdToSmtp readSmtpResponse: SmtpCmdResp: 250-seg-node-chi-01.trustwave.com Hello live.hornbill.com (87.117.243.10) SmtpCmdResp: 250-STARTTLS SmtpCmdResp: 250-XLHASH SmtpCmdResp: 250 SIZE --readSmtpResponse --ehloCommand This SMTP server supports STARTTLS. Automatically doing STARTTLS... startTLS: sendCmdToSmtp: SmtpCmdSent: STARTTLS<CRLF> --sendCmdToSmtp readSmtpResponse: SmtpCmdResp: 220 Ready to start TLS --readSmtpResponse clientHandshake: clientHandshake2: readHandshakeMessages: processHandshakeRecord: processHandshakeMessage: processServerHello: processKeyShareExtension: Unexpected key_share group serverRequestedKeyShareGroup: 0x18 --processKeyShareExtension sendFatalAlert: Closing connection after sending fatal TLS alert. --sendFatalAlert Invalid key_share extension --processServerHello --processHandshakeMessage --processHandshakeRecord --readHandshakeMessages --clientHandshake2 --clientHandshake Client handshake failed. (1) connectionClosed: 0 Failed to establish TLS connection. --startTLS --smtpConnect --smtpConnectAndAuthenticate Failed. --VerifySmtpConnection --ChilkatLog

2020-11-24 13:33:05

Failed to deliver message to any server in the MX records

2020-11-24 13:33:05

Failed to deliver message to target recipient.

2020-11-24 13:33:05

Failed to deliver message

2020-11-24 13:33:05

Delivery will be re-attempted at 2020-11-24 13:34:05Z (1 minutes), attempt 1/9

Link to comment
Share on other sites

32 minutes ago, Deen said:

@Joshua T M Have you set TLS encryption on the outbound mail configuration as the error appears to be TLS related? 

Hi @Deen,

 

Thanks for the response!

 

We are using the Direct Outbound configuration, which (as far as I'm aware) I am unable to set the type of encryption used as it attempts to negotiate automatically.

The below is an excerpt from the Outbound Mail Profile configuration page -

 

"When email is delivered using the Direct Outbound method, our servers will negotiate the highest level of transport encryption supported by the remote SMTP server. This is completely automatic and is negotiated each and every time a new SMTP connection is made. For more information please see here."

Link to comment
Share on other sites

  • 3 months later...

Dear Joshua
We have reviewed the above and the problem appears to be the SMTP Server behind seg.trustwave.com taking on average between 2 and 3 minutes to respond to the Start TLS command and therefore our SMTP client timing out (Normally this should be completed within seconds) . This can be seen by running the below if you have openssl installed.  At this point we would recommend contacting the Administrator of the below server and asking them to reduce the time it takes to perform the TLS handshake to < 30 seconds. 

Kind Regards

Keith Stevenson

 

openssl s_client -connect seg.trustwave.com:25 -starttls smtp
Link to comment
Share on other sites

  • 1 month later...
On 3/12/2021 at 12:27 PM, Keith Stevenson said:

Dear Joshua
We have reviewed the above and the problem appears to be the SMTP Server behind seg.trustwave.com taking on average between 2 and 3 minutes to respond to the Start TLS command and therefore our SMTP client timing out (Normally this should be completed within seconds) . This can be seen by running the below if you have openssl installed.  At this point we would recommend contacting the Administrator of the below server and asking them to reduce the time it takes to perform the TLS handshake to < 30 seconds. 

Kind Regards

Keith Stevenson

 


openssl s_client -connect seg.trustwave.com:25 -starttls smtp

Thanks Keith,

Can you please confirm this is still the case, our customer has responded to this saying "changes have been made" by Trustwave.

When I run the -starttls command it completes and returns almost immediately from my local machine. From our Microsoft 365 platform the handshake completes within two seconds.

Are you able to provide logs via a DM to display the Hornbill SMTP client time out so we can forward this on to the customer and Trustwave.

Josh M
 

Link to comment
Share on other sites

18 minutes ago, Keith Stevenson said:

Joshua. 
Thanks for the reply. That does now return instantly as we would expect.  Do you see any further failed deliveries. 

Kind Regards

Keith Stevenson

Hi Keith,

Unfortunately not as below -

 

X
Status:
 Pending
Recipient Id:
198678
Retry Count:
1
Date Log Entry
2021-04-15 08:43:19 Originating domain: X
2021-04-15 08:43:19 Originating address: X
2021-04-15 08:43:19 Performing SPF check on domain. OrigDom=hornbill.com, OrgPre=_spf, ReqInc=true
2021-04-15 08:43:19 Delivery using DNS/direct message routing
2021-04-15 08:43:19 Target address: X
2021-04-15 08:43:19 Target domain (DNS MX Lookup): X
2021-04-15 08:43:19 Resolved 1 MX records * 10=seg.trustwave.com
2021-04-15 08:43:19 Delivering message via: { }
2021-04-15 08:43:19 Connecting to: seg.trustwave.com, Port: 25, SSL: no, STLS: yes
2021-04-15 08:43:20 Unable to connect to SMTP server. ChilkatLog: VerifySmtpConnection: DllDate: Sep 28 2020 ChilkatVersion: 9.5.0.84 UnlockPrefix: HRNBLL.CBX102021 Architecture: Little Endian; 64-bit Language: Visual C++ 2019 / x64 VerboseLogging: 0 smtpConnectAndAuthenticate: smtpConnect: smtpHostname: seg.trustwave.com smtpPort: 25 connectionIsReady: Need new SMTP connection --connectionIsReady smtpSocketConnect: socketOptions: SO_SNDBUF: 262144 SO_RCVBUF: 4194304 TCP_NODELAY: 1 SO_KEEPALIVE: 1 --socketOptions --smtpSocketConnect smtpGreeting: readSmtpResponse: SmtpCmdResp: 220 seg.mxsmtp.com ESMTP Trustwave SEG [seg-node-chi-02.trustwave.com] Ready --readSmtpResponse --smtpGreeting ehloCommand: sendCmdToSmtp: SmtpCmdSent: EHLO live.hornbill.com<CRLF> --sendCmdToSmtp readSmtpResponse: SmtpCmdResp: 250-seg-node-chi-02.trustwave.com Hello live.hornbill.com (87.117.243.10) SmtpCmdResp: 250-STARTTLS SmtpCmdResp: 250-XLHASH SmtpCmdResp: 250 SIZE --readSmtpResponse --ehloCommand This SMTP server supports STARTTLS. Automatically doing STARTTLS... startTLS: sendCmdToSmtp: SmtpCmdSent: STARTTLS<CRLF> --sendCmdToSmtp readSmtpResponse: SmtpCmdResp: 220 Ready to start TLS --readSmtpResponse clientHandshake: clientHandshake2: readHandshakeMessages: processHandshakeRecord: processHandshakeMessage: processServerHello: processKeyShareExtension: Unexpected key_share group serverRequestedKeyShareGroup: 0x18 --processKeyShareExtension sendFatalAlert: Closing connection after sending fatal TLS alert. --sendFatalAlert Invalid key_share extension --processServerHello --processHandshakeMessage --processHandshakeRecord --readHandshakeMessages --clientHandshake2 --clientHandshake Client handshake failed. (1) connectionClosed: 0 Failed to establish TLS connection. --startTLS --smtpConnect --smtpConnectAndAuthenticate Failed. --VerifySmtpConnection --ChilkatLog
2021-04-15 08:43:20 Failed to deliver message to any server in the MX records
2021-04-15 08:43:20 Failed to deliver message to target recipient.
2021-04-15 08:43:20 Failed to deliver message
2021-04-15 08:43:20 Delivery will be re-attempted at 2021-04-15 07:44:20Z (1 minutes), attempt 1/9
Link to comment
Share on other sites

1 minute ago, Keith Stevenson said:

Joshua 
Thanks for the logs. The good news is that does now fail within 1 second so not the timeout issue. WIll look at why. 

Kind Regards

 

Keith Stevenson

Many Thanks Keith, keep me in the loop please.

Link to comment
Share on other sites

Joshua.
Our development team are investigating as it appears to be issue with the TLS handshake and supported TLS versions.  Weirdly out of over 6000 different email servers (2000 if you count Outlook and all its load balancers as 1)  we connect to every day to send email (Across all instances)  ,this is the only one we see this issue with (You and 1 other customer both send to a recipeint hosted on this and both fail).  

We will update you with our findings as soon as possible. 

Kind Regards 

Link to comment
Share on other sites

7 minutes ago, Keith Stevenson said:

Joshua.
Our development team are investigating as it appears to be issue with the TLS handshake and supported TLS versions.  Weirdly out of over 6000 different email servers we connect to every day to send email (Across all instances)  ,this is the only one we see this issue with (You and 1 other customer both send to a recipeint hosted on this and both fail).  

We will update you with our findings as soon as possible. 

Kind Regards 

Keith,

 

Thanks again for looking into this so promptly. I understand how frustrating such an isolated issue can be.

Link to comment
Share on other sites

10 minutes ago, Keith Stevenson said:

Joshua,
We can inform you that our developers have identified and resolved the issue which will be included in the next planform release.  We will post when this is complete. 

Kind Regards

 

Keith Stevenson

Thank you Keith,

I'll make our support team and the customer aware.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...