[Bug] App fails to fall back when server misadvertises AUTH=PLAIN but rejects with BAD/invalid command

Checklist

• I have used the search function to see if someone else has already submitted the same bug report.
• I will describe the problem with as much detail as possible.

App

Thunderbird for Android

App version

20

Where did you get the app from?

F-Droid

Android version

14

Device model

SM-A528N

Steps to reproduce

1. Open Thunderbird Mobile on an Android device.
2. Select Add Account and enter any valid email address under the domain @seoultech.ac.kr (or choose Manual Setup).
3. Configure the incoming server settings as follows:

• IMAP Server: imap.seoultech.ac.kr | Port: 993 (or 143) | Security: SSL/TLS (or STARTTLS)
• (Alternatively for POP3) POP3 Server: pop3.seoultech.ac.kr | Port: 995 | Security: SSL/TLS

4. Proceed to the next step to trigger the authentication handshake.
5. The app reads the server's CAPABILITY banner (which lists AUTH=PLAIN or SASL PLAIN), issues the corresponding standard AUTHENTICATE PLAIN (or AUTH PLAIN) command, and immediately crashes/fails when the server rejects its own advertised protocol with a BAD or -ERR response.

Expected behavior

1. Standard Behavior: The server infrastructure should strictly adhere to RFC standards, meaning it should either properly process the AUTH=PLAIN command or remove it entirely from the CAPABILITY banner if it is not supported.
2. Requested App Behavior (Fallback Mechanism): Given that the hosting provider has indicated they will not be modifying the server-side configuration, it would be highly beneficial if Thunderbird could implement a robust fallback mechanism. Specifically, when the app receives an immediate BAD or -ERR response following an AUTHENTICATE PLAIN / AUTH PLAIN request, it should gracefully fall back to alternative standard methods, such as the primitive LOGIN (IMAP) or USER / PASS (POP3) commands, rather than aborting the connection entirely.

Actual behavior

Instead of recovering from the server's unexpected response, Thunderbird strictly follows the protocol sequence based on the advertised capabilities.
Upon receiving the immediate BAD, invalid command (IMAP) or -ERR invalid command (POP3) response right after the AUTH PLAIN request, the app cannot proceed further. It throws a Command continuation aborted or Pop3ErrorResponse exception and terminates the connection entirely, preventing the user from completing the account setup.
The exact failure sequences from the debug logs are as follows:

Logs

1. IMAP Connection Failure Sequence

06-16 12:11:39.707 D Sink$-CC: Connecting to imap.seoultech.ac.kr as imap.seoultech.ac.kr/27.96.156.206
06-16 12:11:39.846 V Sink$-CC: conn134276599 <<< #null# [OK, IMAP4 ready]
06-16 12:11:39.846 I Sink$-CC: Did not get capabilities in banner, requesting CAPABILITY for conn134276599
06-16 12:11:39.846 V Sink$-CC: conn134276599>>> 1 CAPABILITY
06-16 12:11:39.876 V Sink$-CC: conn134276599<<<#null# [CAPABILITY, IMAP4, IMAP4rev1, MOVE, QUOTA, SPECIAL-USE, ID, APPENDLIMIT, AUTH=PLAIN]
06-16 12:11:39.877 V Sink$-CC: conn134276599>>> 2 AUTHENTICATE PLAIN
06-16 12:11:39.901 V Sink$-CC: conn134276599<<<#2# [BAD, invalid command]
06-16 12:11:39.902 E Sink$-CC: Failed to login, closing connection for conn134276599
06-16 12:11:39.904 E Sink$-CC: net.thunderbird.core.common.exception.MessagingException: Command continuation aborted: #2# [BAD, invalid command]

2. POP3 Connection Failure Sequence

06-16 12:42:54.839 D Sink$-CC: Connecting to pop3.seoultech.ac.kr as pop3.seoultech.ac.kr/27.96.156.206
06-16 12:42:54.987 D Sink$-CC: <<< +OK POP3 ready
06-16 12:42:54.987 D Sink$-CC: >>> CAPA
06-16 12:42:55.015 D Sink$-CC: <<< +OK Capability list follows
06-16 12:42:55.015 D Sink$-CC: <<< SASL PLAIN LOGIN
06-16 12:42:55.015 D Sink$-CC: <<< .
06-16 12:42:55.016 D Sink$-CC: >>> AUTH PLAIN
06-16 12:42:55.040 D Sink$-CC: <<< -ERR invalid command
06-16 12:42:55.041 E Sink$-CC: com.fsck.k9.mail.store.pop3.Pop3ErrorResponse: -ERR invalid command

Start with the Add Account authentication flow and use the reported IMAP and POP3 log sequences to trace how AUTH PLAIN failures are handled. Done means an immediate BAD or -ERR response from a misadvertised AUTH=PLAIN or SASL PLAIN capability can fall back to an alternative login method without terminating setup.