SmtpException.GetMessageForStatus default case produces misleading "command unrecognized" message for unknown status codes

[madmox]

Description

In SmtpException.GetMessageForStatus, the default case falls through to SmtpStatusCode.CommandUnrecognized:

default:
case SmtpStatusCode.CommandUnrecognized:
    return SR.SmtpCommandUnrecognized;

This means any SmtpStatusCode value not explicitly handled in the switch (including (SmtpStatusCode)0) produces the message "Syntax error, command unrecognized. The server response was: ", which is misleading - it implies the server actively rejected a command with SMTP 500, when in reality the status code may be something entirely different.

Reproduction Steps

We observed this in production with SmtpClient connecting to a third-party SMTP relay. Intermittently, the connection fails during the handshake (ConnectCallback → SmtpTransport.EndGetConnection), and the resulting SmtpException has:

• StatusCode = (SmtpStatusCode)0 (not a defined enum member)
• InnerException = null
• Message = "Syntax error, command unrecognized. The server response was: "

The status code 0 likely comes from SmtpReplyReaderFactory's _statusCode field retaining its default value when no valid SMTP response was received.

Expected behavior

The default case should return a distinct, generic message (e.g. "Unknown SMTP error." or "Unexpected SMTP status code.") rather than falling through to CommandUnrecognized. This would make it clear that the status code is not a standard SMTP 500 response.

Actual behavior

Any unrecognized SmtpStatusCode value produces the message "Syntax error, command unrecognized.", which is the description of a specific SMTP error (500) and does not reflect the actual status code.

Regression?

Unknown - the default / case CommandUnrecognized pattern appears to have been present since the original .NET Framework implementation (reference source).

Known Workarounds

No response

Configuration

• .NET 8.0.22
• Linux (Amazon Linux 2023), x64
• SMTP relay: Mailjet (also observed with smtp2go)

Other information

No response

[rzikm]

Will changing the exception message really fix your scenario? If we change the exception message to what you propose in the Expected behavior section, then we will still throw SmptException, with StatusCode == 0, and your scenario will still fail without being actionable from your side. Or am I missing something?

[madmox]

Will changing the exception message really fix your scenario? If we change the exception message to what you propose in the Expected behavior section, then we will still throw SmptException, with StatusCode == 0, and your scenario will still fail without being actionable from your side. Or am I missing something?

The issue is only about the coherency of the exception message. The current message is misleading for diagnostics purposes when the error occurs, I was about to add the CommandUnrecognized error code (500) in my SMTP retry policy for no reason, just because the error log indicated the corresponding error message (unfortunately, SmtpException.ToString() does not contain the SMTP status code).

[ManickaP]

IMHO this is a valid complain. Changing the message for the unknown codes - not listed in the switch - would improve ability to diagnose problems. In other places we also separate "unknown" from other codes / messages (e.g. QUIC). And I think this is fairly straightforward and would be easy to contribute.