Hi all, below is a small patch fixing an authentication problem with one of my mail providers (pop3.netcologne.de) which replies to the "CAPA" (RFC 2449) command, but does not offer USER authentication explicitly:
R '+OK POP3 ready' W 'CAPA' R '+OK Capability list follows' R 'CAPA' R 'TOP' R 'UIDL' R 'RESP-CODES' R 'PIPELINING' R 'SASL LOGIN PLAIN' R 'STLS' R '.' I am not sure if this is really a buggy server, as RFC 1939, Sect. 4 states: <quote> Two possible mechanisms for doing this are described in this document, the USER and PASS command combination and the APOP command. [...] Additional authentication mechanisms are described in [RFC1734]. While there is no single authentication mechanism that is required of all POP3 servers, a POP3 server must of course support at least one authentication mechanism. </quote> This /could/ be interpreted as "the server must support either APOP or USER (i.e. one of the basic ones), even if it reports a SASL (AUTH) mechanism as reply to CAPA". At least, I /can/ login using the USER mechanism... Therefore, I suggest to always enable 'USER' if APOP is disabled, even if the CAPA does not announce it explicitly. Opinions? Cheers, Albrecht.
diff --git a/libbalsa/imap/pop3.c b/libbalsa/imap/pop3.c
index fb74863..8955b7e 100644
--- a/libbalsa/imap/pop3.c
+++ b/libbalsa/imap/pop3.c
@@ -226,6 +226,9 @@ pop_get_capa(PopHandle *pop, GError **err)
char *line;
memset(pop->capabilities, '\0', sizeof(pop->capabilities));
+ if (pop->disable_apop != 0) {
+ pop->capabilities[POP_CAP_USER] = 1;
+ }
if(!pop_exec(pop, "CAPA\r\n", err)) {
pop->capabilities[POP_CAP_USER] = 1;
return FALSE;
pgpqXMifdENN2.pgp
Description: PGP signature
_______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
