|
From: Jakob H. <jh...@pl...> - 2006-11-29 10:45:28
|
Quoting Matthias Andree: > Thank you very much for testing this. > The attached patch should cure this. You're welcome. Thanks for the patch, looks better now: > fetchmail: 6.3.6-rc4 querying pop.guru.de (protocol POP3) at Wed, 29 Nov 2006 10:33:36 +0100 (CET): poll started > Trying to connect to 212.11.227.194/110...connected. > fetchmail: POP3< +OK b1gPOP3 2-1.22 Linux (guru.de) ready > fetchmail: POP3> CAPA > fetchmail: POP3< -ERR Unknown command (in this session state): "CAPA" > fetchmail: Unknown command (in this session state): "CAPA" > fetchmail: Repoll immediately on jh...@gu...@pop.guru.de > Trying to connect to 212.11.227.194/110...connected. > fetchmail: POP3< +OK b1gPOP3 2-1.22 Linux (guru.de) ready > fetchmail: POP3> USER xx...@gu... > fetchmail: POP3< +OK Need password for jh...@gu... > fetchmail: POP3> PASS * > fetchmail: POP3< +OK Logged in, you have 0 message(s) in your mailbox (0 octets) But why the superfluous CAPA? I know the server does not support SSL or TLS, and I have no "ssl" for it in my fetchmailrc, so why look for it at all? It probably does not harm much, but I think we should not bother the server unnecessarily, so the extra connect should be avoided. We could instead try to login despite of the failed CAPA, and only reconnect after this login failed (which will surely happen with some servers). |