Symantec Messaging Gateway (SMG) may defer connections from remote MTAs following a TLS negotiation failure. In some cases, if secure TLS communication cannot be negotiated, the sending mail server will immediately attempt a reconnect to deliver the message in plain text. In some cases, the Connection Classification feature in SMGThis appears to be caused by incorrect handling by remote MTA of following:
SMTP TLS session
Certificates verification process
Cleartext fallback mechanism implemented in case of TLS connection failure
Some mail servers will immediately retry sending a message in plain text if the negotiation of secure delivery via SMTP TLS fails. When the Connection Classification feature in Messaging Gateway is enabled this immediate redelivery attempt will trigger the "Reconnect Timeout" limit and cause the connection attempt to be deferred. If the sending mail server again attempts to deliver the message with TLS and fails, the fast retry will again be deferred by Connection Classification.
Based on data gathered so far this issue should be resolved on sending MTA side. Following are some suggestions on how this issue can be resolved on remote MTA side:
Configure remote MTA to trust certificate provided by SMG
Configure remote MTA to fallback to cleartext SMTP with delay (recommended 2mins, if needed shorter period could be configured)
Configure remote MTA to fallback to cleartext reliably and consistently if TLS fails
Configure remote MTA to always use cleartext when connecting to SMG IP
Here is the list of possible workarounds that can be evaluated for implementation on SMG side to restore the connectivity:
Use certificate signed by trusted public Certificate Authority if TLS fails because SMG uses self-signed or untrusted certificate
Use newly generated self-signed certificate if TLS fails and certificate in use was generated several years ago and/or using old security standards
In cases involving SSL deep inspection devices in front of SMG, please make sure this function is disabled for SMTP protocol or at minimum that proper exhaustive list of exceptions is created
Add remote MTA IP to "Local Good Sender IPs" list
Reduce Connection Classification "Reconnect Timeout" to 0sec for the affected classes
Disable Connection Classification
Based on our research, such issues can be mostly avoided when using valid, public CA certificates on SMG. While SMG has the option to use self-signed or private CA signed certificates, such certificates are intended to be used in lab and/or test deployments only.
For any production deployments Symantec strongly recommends use of public CA certificates with Symantec Messaging Gateway.
Major factor is how remote MTAs handle the TLS connection, certificates negotiation and verification and cleartext fallback in case of TLS failure. If all other possibilities are exhausted, Symantec support might need to refer customers to continue troubleshooting directly with remote MTA vendor.
Subscribing will provide email updates when this Article is updated. Login is required.