Bugzilla

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36

Steps to reproduce:

1. Configure the account in Thunderbird 155.0 - SMTP server <host>:465, connection security SSL/TLS, authentication method "Normal password".
2. Click Send. Watch the Error Console (Ctrl+Shift+J).
3. AUTH LOGIN is issued; the server returns a 334 challenge; the client then immediately closes the connection without sending the username.
4. Result is nondeterministic across retries because the server load-balances across heterogeneous back-ends.



Actual results:

Sending failed: Unable to authenticate to Outgoing server (SMTP) dXNlcm5hbWU6. Please check the password and verify "Account settings | Server settings" for the "authentication method". exitCode=2147500037

Error Console log:
mailnews.smtp: S: 334 dXNlcm5hbWU6
mailnews.smtp: Closing connection to server...
mailnews.smtp: Socket closed.
mailnews.smtp: Authentication failed: Socket closed.

Root evidence: after server sends 334 dXNlcm5hbWU6, Thunderbird closes the socket instead of sending the base64-encoded username.

NOTE: The server also intermittently returns a malformed 334 challenge (DXNLCM5HBWU6, base64-decodes to 0d734b08ce4705653a) which is neither "Username:" nor "username:". This makes the issue worse, as the client aborts in both cases.



Expected results:

The client should complete AUTH LOGIN when the server returns a valid 334 Username: / Password: challenge (regardless of case), and send the mail.
The client should tolerate a malformed 334 challenge - if the base64 decode does not yield "Username:"/"username:", it should fall back to the standard flow (send the username) rather than silently closing the socket, or at least retry the connection once.

Related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1824060

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36

Steps to reproduce:

1. Configure the account in Thunderbird 155.0 - SMTP server <host>:465, connection security SSL/TLS, authentication method "Normal password".
2. Click Send. Watch the Error Console (Ctrl+Shift+J).
3. AUTH LOGIN is issued; the server returns a 334 challenge; the client then immediately closes the connection without sending the username.
4. Result is nondeterministic across retries because the server load-balances across heterogeneous back-ends.



Actual results:

Sending failed: Unable to authenticate to Outgoing server (SMTP) dXNlcm5hbWU6. Please check the password and verify "Account settings | Server settings" for the "authentication method". exitCode=2147500037

Error Console log:
mailnews.smtp: S: 334 dXNlcm5hbWU6
mailnews.smtp: Closing connection to server...
mailnews.smtp: Socket closed.
mailnews.smtp: Authentication failed: Socket closed.

Root evidence: after server sends 334 dXNlcm5hbWU6, Thunderbird closes the socket instead of sending the base64-encoded username.

NOTE: The server also intermittently returns a malformed 334 challenge (DXNLCM5HBWU6, base64-decodes to 0d734b08ce4705653a) which is neither "Username:" nor "username:". This makes the issue worse, as the client aborts in both cases.



Expected results:

The client should complete AUTH LOGIN when the server returns a valid 334 Username: / Password: challenge (regardless of case), and send the mail.
The client should tolerate a malformed 334 challenge - if the base64 decode does not yield "Username:"/"username:", it should fall back to the standard flow (send the username) rather than silently closing the socket, or at least retry the connection once.

Related bug 1824060