[✨ Triage] dotnet/runtime#126160 by madmox - SmtpException.GetMessageForStatus default case produces misleading "com ...

[MihuBot]

Triage for dotnet/runtime#126160.
Repo filter: All networking issues.
MihuBot version: 246635.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

Tool logs

dotnet/runtime#126160: SmtpException.GetMessageForStatus default case produces misleading "command unrecognized" message for unknown status codes by madmox
Extracted 5 search queries: SmtpException.GetMessageForStatus default falls through to CommandUnrecognized producing misleading message, SmtpStatusCode value 0 results in message "Syntax error, command unrecognized" from SmtpException, SmtpClient ConnectCallback / SmtpTransport.EndGetConnection intermittent failure with SmtpStatusCode 0, SmtpReplyReaderFactory _statusCode left at default when no valid SMTP response leading to incorrect exception message, GetMessageForStatus should handle unknown SmtpStatusCode with generic message instead of CommandUnrecognized
Found 8 candidate issues

• Issue #85637 (May 2023) - "Failures in System.Net.Mail.Tests.SmtpClientTest tests"
  Summary: Test failures showed SmtpException messages like "Syntax error, command unrecognized. The server response was: Idk that command". The root cause investigated in that thread was a JIT/regression (not message mapping) and was fixed by a PR. Relevance: shows the exact message string your report complains about appearing in CI/test failures, but the discussion/fixes there were about a JIT/regression causing the test failures, not about the GetMessageForStatus default-case mapping or an unknown-status code being rendered as "command unrecognized".

• android#9888 (Mar 2025) - "SmtpClient issue" (Xamarin/.NET on Android)
  Summary: Reports of SmtpClient async vs sync behavior differences, timeouts and troubleshooting steps. The discussion focused on timeouts / platform-specific behavior and using Send vs SendAsync to get better diagnostics; no changes to SMTP status → message mapping. Relevance: not directly related to GetMessageForStatus or the default-case message; mainly about timeouts and platform runtime behavior.

• PR #288 (Nov 2019) - "Fix SmtpClient handling exceptions as timeouts" (merged)
  Summary: Fixed a bug where async SmtpClient calls could incorrectly surface timeout exceptions (the timeout flag was used erroneously in async path). Relevance: conceptually related because it is an example of SmtpClient historically misreporting error conditions, but it does not touch SmtpException.GetMessageForStatus or the default-case mapping that produces a misleading "command unrecognized" message.

• Issue #49340 (Mar 2021) - "Reusing SmtpClient hangs in net50"
  Summary: Reuse of SmtpClient with SendAsync could hang because async path attempted to open a new connection even when already connected; investigation led to community PRs and fixes (see PR #70046). Relevance: relates to connection/handshake failures and produced confusing SmtpExceptions in some cases, but does not address the specific issue of unknown SmtpStatusCode values being mapped to the "command unrecognized" message.

• PR #70046 (May 2022) - "Fix SmtpClient reuse with SendAsync" (merged)
  Summary: Fix for the async reuse/hang described in #49340; changed locking/logic to avoid opening new connections unnecessarily. Relevance: improves stability/handshake behavior, but not relevant to GetMessageForStatus’s default message mapping.

• Issue #30732 (Aug 2019) - "System.Net.Mail.Tests.SmtpClientTest.TestZeroTimeout hangs in CI"
  Summary: Long-running CI hang investigated; root-cause analysis found edge cases where socket/linger handling and exception swallowing led to hangs; related fixes and dumps were produced. Relevance: demonstrates historical issues where exceptions were swallowed or mis-handled in SmtpClient/SmtpConnection, but doesn't address the specific default message mapping you reported.

• PR #428 (Dec 2019) - "SmtpConnection: fix Socket not getting Disposed when LingerState cannot be set." (merged)
  Summary: Fixed a problem where setting LingerState could throw and the socket would not be disposed; adjusted exception handling to avoid swallowing the underlying exception. Relevance: shows prior attention to correctly surfacing/handling exceptional conditions in SmtpConnection; conceptually related because your report also concerns confusing/misleading error reporting, but this PR is about socket disposal/exception surfacing rather than mapping of SMTP status codes to user-facing messages.

• android#3089 (May 2019) - "SmtpClient.Send System.Net.Mail.SmtpException: Message could not be sent"
  Summary: Xamarin.Android-specific SmtpClient issues, recommendation to use MailKit; unrelated to GetMessageForStatus mapping. Relevance: not relevant.

Overall conclusion from the related work:

• There is precedent in the System.Net.Mail area for incorrect or confusing error reporting (e.g., timeouts being reported incorrectly, exceptions being swallowed), and there have been multiple fixes over time to improve how errors are surfaced. However, none of the referenced issues/PRs directly address SmtpException.GetMessageForStatus returning the CommandUnrecognized message for unknown/0 status codes. The default/fallthrough-to-CommandUnrecognized pattern you point out appears to be an independent problem (and you note it matches the old .NET Framework reference source). This looks like a valid new bug/clarification request: GetMessageForStatus should provide a distinct/generic message for unknown enum values (including (SmtpStatusCode)0) rather than reusing the 500/CommandUnrecognized text.