Error 451 4.7.5 for messages that failed specific TLS communication


Article ID: 156083


Updated On:


Messaging Gateway


On sending outbound email, a number of messages failed due to TLS settings/mode that were known to have been set incorrectly. These messages subsequently get stuck in the delivery queue with an error of 451 4.7.5 [internal] SSL certificate subject does not match host.

The messages do not flush and do not reroute to another specified scanner or hop due to the original TLS destination remaining, in the form of the  incorrect TLS destination.



The primary error is 451 4.7.5

On closer examination of the ‘maillog’, the actual error is as follows.

2012 Mar 15 06:33:26 EDT (info) ecelerity: [16854] ec_ssl_ctx 0x881fee78 tls_verify_hostname failed: VeriSign Class 3 Secure Server CA - G3 not in (,#sms#00000017)

2012 Mar 15 06:33:26 EDT (debug) ecelerity: [16854] SSL Certificate: Subject: /C=US/ST=New Jersey/O=company name AG/ Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at (c)10/CN=VeriSign Class 3 Secure Server CA - G3

2012 Mar 15 06:33:26 EDT (debug) ecelerity: [16854] SMTP STARTTLS: /C=US/ST=New Jersey/O=company name AG/ /C=US/O=VeriSign, Inc./OU=VeriSign Trust


The 'wronghost' is the host that was attempted initially and then repeatedly, however the messages need re-routing to the 'correcthost' as stated in the cert entries as indicated by in the log entry above.



The cause of this behavior is to be expected as failed TLS mail will retry to the same destination for TLS verification even though 'Verify' is no longer configured. Only new messages will adapt the new TLS configuration of 'Require TLS' only. The original incorrect destination host will be attempted on 'Flush' and/or 'Re-Route' unless an alternative and correct destination host is specified. In this case it is as referenced from the ‘Maillog’ of the scanner in question.


Since the original TLS configuration was corrected, all messages after the original failures delivered fine. The issue only affects messages failed in the delivery queue due to the previous TLS configuration as outlined.



The following command will re-route all failed messages to the correct host as stated in the maillog cert entry and the host in which messages should have been routed from the offset if 'Require TLS' was set at that time.

'mta-support  reroute'

Different receiving domains have different TLS requirements and Symantec recommends that these requirements are established and confirmed in advance and tested at an off peak time to confirm successful mail delivery.


Applies To

This behavior has been confirmed on Symantec Messaging Gateway (SMG) 8.0.3 but based on the Ecelerity MTA it can be expected to be seen in the same circumstances on SMG 9.x

The specific configuration that allowed the first batch of messages to fail based on error of 451 4.7.5 was due to the following TLS configuration scenario:

- Require TLS and Verify certificate.

However, the setting that was required by the receiving domain was as follows.

- Require TLS