If strict certificate compliance fails resulting in '602' non-delivery, a second send attempt without strict compliance is initiated

Problem reported by Martin Margheim - 3/16/2026 at 10:20 PM

Submitted

'602' Non-delivery occurs when SMPT OUT is set for strict compliance.

I propose Smartermail attempt a second delivery attempt with strict compliance disabled before issuing non-delivery if second attempt fails

7 Replies

Reply to Thread

J. LaDow Replied

Yesterday at 2:14 AM

It does that anyway if you don't "enforce it" -- SM always tries to send through secured channels first.

The behavior described defeats the purpose of "strict validation" --

The 602 needs to be better worded to say there is an issue with the SSL/TLS certificate presented by the destination server. Users have no damn clue what Error 602 is when it bounces back to their inbox and just blame the current provider for the problems instead of pushing the receiving party to fix their server.

We tried running with it on for a month and it cost us customers because they don't understand the error and we don't have the time and resources to fix everyone else's TLS implementation...

MailEnable survivor / convert --

Kyle Kerst Replied

Yesterday at 5:50 AM

Employee Post

That is when it becomes your job (as the administrator or hosting provider) to educate your users on the root cause. Your Support department exists to connect the dots between '602 error' and 'the people you're sending to aren't adhering to standard best practice security requirements.' That said, I do believe strict enforcement should prevent delivery though the help is a bit vague on this front:

Enforce strict certificate validation - This setting prevents the server from connecting to servers over SSL/TLS that have an invalid certificate For example, this prevents SSL/TLS connections to servers with out-of-date certs or domain name mismatches on their certificate.

It doesn't clarify whether or not SmarterMail should then attempt an insecure delivery to ultimately hand off the message. I'm going to do some testing on this and ping our development team on this to get some more details and I'll follow up with you guys here as I find out more.

Kyle Kerst Lead Internal Network/System Administrator SmarterTools Inc. smartertools.com

Douglas Foster Replied

Yesterday at 9:36 AM

You cannot ensure that every other organization will be configured with a commercial certificate and optimal encryption settings. So you have two options:

- Settle for best-available encryption, even if that means weak or no encryption.

- Subscribe to a secure web relay product and force messages for insecure destinations to go through the secure web relay.

Zixmail was the one product that was available standalone but it has been swallowed by OpenText and I have been stymied on getting information about it. Most of the outbound gateway services offer a secure web relay product, but they also want to be your inbound gateway and want you to pay enough to cover their next resort vacation in Thailand...

John Quest Replied

Yesterday at 1:12 PM

Zixmail was the one product that was available standalone but it has been swallowed by OpenText and I have been stymied on getting information about it.

Don't get me started about OpenText...

Douglas Foster Replied

Yesterday at 1:22 PM

Tangential to this topic: If the STARTTLS sequence is attempted, but the two systems cannot agree on a ciphersuite configuration, does the connection fail back to cleartext automatically?

J. LaDow Replied

Yesterday at 3:48 PM

If strict or relaxed enforcement is enabled, then no.

If not enabled, then yes.

There's another option for when receiving somewhere else if I remember right.

MailEnable survivor / convert --

Kyle Kerst Replied

Today at 7:11 AM

Employee Post

I was able to check in with development on this and got some additional details on how this works. If certificate validation fails in this case the process typically flows like this:

The STARTTLS handshake fails — the connection is aborted
All recipients on that delivery attempt are marked as failed
The SMTP session is ended with a QUIT
The message's completion status is set to TlsError

Once the message has been marked as a TlsError it will be moved into Waiting to Deliver and marked for a later retry. This later retry attempt is where you see the delivery completed without security. Just to provide a bit more context; that setting determines whether SmarterMail will establish a secure connection when the remote cert isn't valid. This results in two behaviors:

If the remote port uses implicit (SSL/TLS) security and offers up an invalid cert, SmarterMail will not fallback.
If the remote port uses explicit (STARTTLS) security and offers up an invalid cert, SmarterMail will fallback to sending insecurely the next time the message is processed by the spool.

This is due to the nature of SSL versus TLS based secured communication. That being outlined, I think a feature request to allow/deny this fallback behavior in any case might be useful. Lastly, I also confirmed for @Douglas Foster that the same behavior applies if a mutual TLS version cannot be agreed upon.

Kyle Kerst Lead Internal Network/System Administrator SmarterTools Inc. smartertools.com

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text