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 the first 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. This takes a similar workaround to
b363b602e179 ("Add SMTP gsasl auth workaround for broken Microsoft
servers.")
Link: https://datatracker.ietf.org/doc/html/rfc5034
Signed-off-by: Yao Zi <[email protected]>
---
Changed from v1
- Only ignore decoding errors in the first server challenge
- Update commit description to mention b363b602e179 which is similar to
the patch but for SMTP + GSASL
- Link to v1:
https://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20260105/001679.html
pop_auth.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/pop_auth.c b/pop_auth.c
index 77c6e764761d..1642b7f76e04 100644
--- a/pop_auth.c
+++ b/pop_auth.c
@@ -46,7 +46,7 @@ static pop_auth_res_t pop_auth_sasl (POP_DATA *pop_data,
const char *method)
{
sasl_conn_t *saslconn;
sasl_interact_t *interaction = NULL;
- int rc;
+ int rc, first_challenge = 1;
char *buf = NULL;
size_t bufsize = 0;
char inbuf[LONG_STRING];
@@ -123,9 +123,21 @@ 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, thus we try to
+ * keep going to improve compatibility if the first challenge fails to
+ * decode.
+ */
+ if (first_challenge)
+ len = 0;
+ else
+ goto bail;
}
+ first_challenge = 0;
+
if (!client_start)
FOREVER
{
--
2.52.0
