2068867 - SMTP AUTH LOGIN fails on TB 155 against Coremail: server sends non-standard/case-variant 334 challenge

Status: RESOLVED FIXED

(MailNews Core :: Networking: SMTP, defect)

Description

Attachment: ScreenShotScreenshot of Thunderbird Error Console showing AUTH LOGIN, server 334 challenge dXNlcm5hbWU6, then Socket closed (exitCode 2147500037). Company/account identifiers are redacted in the text of this report._2026-09-03_153116_430.png

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

Comment 1

[Max Emig [:maxe]]

Result is nondeterministic across retries because the server load-balances across heterogeneous back-ends.

How do you end up in such a situation? Have you ever reached out to whoever is providing that infrastructure?

Comment 2

[Max Emig [:maxe]]

The contents of both challenges SHOULD be ignored.

per https://datatracker.ietf.org/doc/html/draft-murchison-sasl-login-00

Yeah, we should fix that.

Comment 3

[Qing]

(In reply to Max Emig [:maxe] from comment #1)

Result is nondeterministic across retries because the server load-balances across heterogeneous back-ends.

How do you end up in such a situation? Have you ever reached out to whoever is providing that infrastructure?

Thank you for the follow-up, maxel.

To answer your questions:

1. How did I end up in this situation?
   I configured the account in Thunderbird 155.0 (SMTP 465/SSL, auth "Normal password"). Sending consistently fails. From repeated manual tests against the server (openssl s_client to port 465 and 25), I observed that the server returns an INCONSISTENT AUTH LOGIN challenge across connections:

   • Sometimes a valid "dXNlcm5hbWU6" (= base64 "username:")
   • Sometimes a malformed "DXNLCM5HBWU6" (base64-decodes to 0d734b08ce4705653a, which is neither "Username:" nor "username:")
     Also the EHLO capability advertisement is unstable: on port 25, STARTTLS is advertised on some connections and absent on others.

2. Have I reached out to the infrastructure provider?
   No, I have not been able to reach the mail server administrator directly. Note that the vast majority of colleagues in my company use Foxmail for email. In Foxmail, only POP3 needs to be configured (SMTP is not required), and Foxmail receives AND sends mail normally with the same credentials. This strongly suggests the account and credentials are valid, and that the issue is specific to how Thunderbird 155.0 negotiates AUTH LOGIN with this server.

Please let me know if you need more logs or details.

Comment 4

[Max Emig [:maxe]]

Looking into this, it seems we should move over to only checking for status code in line with the old C++ implementation as well as any of the 5+ FOSS SMTP clients I checked. There is no precedent in either standards or other FOSS implementation for trying to match the string in the first place.

Comment 5

[Qing]

(In reply to Max Emig [:maxe] from comment #4)

Looking into this, it seems we should move over to only checking for status code in line with the old C++ implementation as well as any of the 5+ FOSS SMTP clients I checked. There is no precedent in either standards or other FOSS implementation for trying to match the string in the first place.

Thanks for taking this on. I'll help verify once a fix lands.

Comment 6

[Max Emig [:maxe]]

(In reply to Qing from comment #5)

(In reply to Max Emig [:maxe] from comment #4)

Looking into this, it seems we should move over to only checking for status code in line with the old C++ implementation as well as any of the 5+ FOSS SMTP clients I checked. There is no precedent in either standards or other FOSS implementation for trying to match the string in the first place.

Thanks for taking this on. I'll help verify once a fix lands.

I will want you to confirm it working with a try build which I will provide soon. You are using Windows, right?

Comment 7

[Max Emig [:maxe]]

Attachment: Bug 2068867 - Rely solely on SMTP status codes for AUTH LOGIN handling. r=#thunderbird-back-end-reviewers

Comment 8

[Qing]

(In reply to Max Emig [:maxe] from comment #6)

(In reply to Qing from comment #5)

(In reply to Max Emig [:maxe] from comment #4)

Looking into this, it seems we should move over to only checking for status code in line with the old C++ implementation as well as any of the 5+ FOSS SMTP clients I checked. There is no precedent in either standards or other FOSS implementation for trying to match the string in the first place.

Thanks for taking this on. I'll help verify once a fix lands.

I will want you to confirm it working with a try build which I will provide soon. You are using Windows, right?

Yes, I am using Windows 10 (build 26200). Happy to test the try build and report back the results. Please share the download link / instructions when it's ready and let me know the expected behavior to verify.

Comment 9

[Qing]

(In reply to Qing from comment #8)

(In reply to Max Emig [:maxe] from comment #6)

(In reply to Qing from comment #5)

(In reply to Max Emig [:maxe] from comment #4)

Looking into this, it seems we should move over to only checking for status code in line with the old C++ implementation as well as any of the 5+ FOSS SMTP clients I checked. There is no precedent in either standards or other FOSS implementation for trying to match the string in the first place.

Thanks for taking this on. I'll help verify once a fix lands.

I will want you to confirm it working with a try build which I will provide soon. You are using Windows, right?

Yes, I am using Windows 10 (build 26200). Happy to test the try build and report back the results. Please share the download link / instructions when it's ready and let me know the expected behavior to verify.

Correction: I'm actually on Windows 11 Pro (25H2, build 26200), not Windows 10. Apologies for the earlier typo - please build the try build for Windows 11 / x64. Ready to test whenever it's ready.

Comment 10

[Max Emig [:maxe]]

This weird incorrect behaviour came straight from the emailjs-smtp-client import and wasn't an active decision of anyone involved in the Thunderbird project.

Here is the build I'd like you to try: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HcJBQ269S26EH01UgYMg1w/runs/0/artifacts/public/build/target.installer.exe

Please report if everything is fully working as expected.

Thanks

Max

Comment 11

[Qing]

(In reply to Max Emig [:maxe] from comment #10)

This weird incorrect behaviour came straight from the emailjs-smtp-client import and wasn't an active decision of anyone involved in the Thunderbird project.

Here is the build I'd like you to try: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HcJBQ269S26EH01UgYMg1w/runs/0/artifacts/public/build/target.installer.exe

Please report if everything is fully working as expected.

Thanks

Max

I've tested the try build and can confirm everything is working as expected now.

• Sending: Successfully sent test emails via SMTP (465/SSL) without any authentication errors.
• Receiving: Successfully received mail via POP3.

The SMTP AUTH LOGIN issue is fully resolved in this build. Thank you for the quick fix, Max! I'll keep an eye on the stable release to confirm the fix lands there too.

Comment 12

[Max Emig [:maxe]]

(In reply to Qing from comment #11)

(In reply to Max Emig [:maxe] from comment #10)

This weird incorrect behaviour came straight from the emailjs-smtp-client import and wasn't an active decision of anyone involved in the Thunderbird project.

Here is the build I'd like you to try: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HcJBQ269S26EH01UgYMg1w/runs/0/artifacts/public/build/target.installer.exe

Please report if everything is fully working as expected.

Thanks

Max

I've tested the try build and can confirm everything is working as expected now.

• Sending: Successfully sent test emails via SMTP (465/SSL) without any authentication errors.
• Receiving: Successfully received mail via POP3.

The SMTP AUTH LOGIN issue is fully resolved in this build. Thank you for the quick fix, Max! I'll keep an eye on the stable release to confirm the fix lands there too.

It did not land in any way yet, but your feedback will certainly help reviewers make a timely decision on it.

Thanks

Max

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/5b104b54beef
Rely solely on SMTP status codes for AUTH LOGIN handling. r=mkmelin