RFC 5034 requires data in SASL server challenges to be encoded in base64 when integrating with POP3,
> A server challenge is sent as a line consisting of a "+" character, > followed by a single space and a string encoded using Base64, as > specified in Section 4 of [RFC4648]. This line MUST NOT contain any > text other than the BASE64-encoded challenge. However, some mail providers put raw text instead of base64-encoded data in the challenge. Mutt always bails out when encountering them, [2026-01-08 05:02:31] Authenticating (SASL)... [2026-01-08 05:02:31] 6> AUTH PLAIN [2026-01-08 05:02:31] 6< + Ready for additional text [2026-01-08 05:02:31] pop_auth_sasl: error base64-decoding server response. [2026-01-08 05:02:31] 6> * [2026-01-08 05:02:32] 6< -ERR Au [2026-01-08 05:02:32] SASL authentication failed. while some other POP3 clients, e.g. cURL, accept them, > AUTH PLAIN < + Ready for additional text > dGVzdHRlc3R0ZXN0Cg== < +OK > LIST < +OK 223 messages (1256448 octets) which might work since some SASL mechanisms, e.g. PLAIN, don't care about the challenge responsed by server. Let's stop bailing out early when failing to decode SASL challenge as base64. Instead, print a debug message and then try to continue the authentication process for better compatibility with these quirky service providers. Link: https://datatracker.ietf.org/doc/html/rfc5034 Signed-off-by: Yao Zi <[email protected]> --- pop_auth.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/pop_auth.c b/pop_auth.c index 77c6e764761d..8ef8851bec29 100644 --- a/pop_auth.c +++ b/pop_auth.c @@ -123,7 +123,13 @@ static pop_auth_res_t pop_auth_sasl (POP_DATA *pop_data, const char *method) && sasl_decode64 (inbuf+2, strlen (inbuf+2), buf, bufsize - 1, &len) != SASL_OK) { dprint (1, (debugfile, "pop_auth_sasl: error base64-decoding server response.\n")); - goto bail; + + /* Some server implementations may send non-base64-encoded challenge, + * which is against RFC 5034. However, for certain SASL mechanism, e.g. + * PLAIN, the content of challenge doesn't really matter, we try to keep + * going to improve compatibility in such case. + */ + len = 0; } if (!client_start) -- 2.52.0
