Menu
▾
▴
fetchmail-users
|
From: Matthias A. <mat...@gm...> - 2006-11-27 04:20:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, After several more bugs had to be fixed, I have uploaded the fourth fetchmail 6.3.6 release candidate to the usual download location: <http://home.pages.de/~mandree/fetchmail/> - the site also has rpms. It is very important that 6.3.6-rc4 gets as much testing as possible, so as to find incompatibilities between the fixes and your existing setups. Please report all such incompatibilities, else we can't fix them for 6.3.6, obviously, and it may be a long time before the release after this. WARNING: This message sets the Reply-To: header. When replying to me personally, you need to edit the To: header! Can those who use an mda and who have experienced fetchmail crashes after refused messages please test if these are gone? Thank you. Happy fetching, Matthias Andree -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFallUvmGDOQUufZURAtEEAKDm5Z2M0Igfldst8uEef8KgHSg/SACfdn1k CBvvTQrhpb72NaQVBzbaAX4= =esf+ -----END PGP SIGNATURE----- |
|
From: Jakob H. <jh...@pl...> - 2006-11-27 11:05:14
|
Quoting Matthias Andree: It worked here: > fetchmail: 6.3.6-rc3 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:58:09 +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> USER xx...@gu... > fetchmail: POP3< +OK Need password for xx...@gu... > fetchmail: POP3> PASS * > fetchmail: POP3< +OK Logged in, you have 0 message(s) in your mailbox (0 octets) ... but not anymore... > fetchmail: 6.3.6-rc4 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:59:54 +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: Authorization failure on xx...@gu...@pop.guru.de > fetchmail: POP3> QUIT > fetchmail: POP3< +OK Bye > fetchmail: 6.3.6-rc4 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:59:54 +0100 (CET): poll completed > fetchmail: Query status=3 (AUTHFAIL) > fetchmail: normal termination, status 3 with defaults proto pop3 ... and poll pop.guru.de auth password user xx...@gu... pass yyyyyy fetchall to "guru" There should be no CAPA at all (or at least used to be), but fetchmail should not stumble on that, I guess. |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 07:58:13
Attachments:
fix-pop3.patch
|
Jakob Hirsch <jh...@pl...> writes: > Quoting Matthias Andree: > > It worked here: > >> fetchmail: 6.3.6-rc3 querying pop.guru.de (protocol POP3) at Mon, 27 Nov 2006 10:58:09 +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> USER xx...@gu... >> fetchmail: POP3< +OK Need password for xx...@gu... >> fetchmail: POP3> PASS * >> fetchmail: POP3< +OK Logged in, you have 0 message(s) in your mailbox (0 octets) > ... Thank you very much for testing this. The attached patch should cure this. -- Matthias Andree |
|
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). |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 17:39:27
|
Jakob Hirsch schrieb am 2006-11-29: > 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). 1. You did not ask for SSL, but you did probably not prohibit TLS either, so fetchmail will - that's its default - look if it has the opportunity to use TLS. Using 'sslproto ""' should defeat this CAPA probe. This goes along with <http://www.fetchmail.info/fetchmail-FAQ.html#K6> 2. ESR got reports that some servers dropped the connection later on when probed for capabilities, and a reconnect was chosen as a solution. I don't know many of the details though, if someone knows URLs off-hand, let me know. I'm a bit loathe to change this part of the behavior at this time though. Given that CAPA doesn't cause state change, servers that change behavior after "reconnect without CAPA" are broken anyways. 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and subsequent polls? It shouldn't. -- Matthias Andree |
|
From: Jakob H. <jh...@pl...> - 2006-11-29 18:06:26
|
Quoting Matthias Andree: > 1. You did not ask for SSL, but you did probably not prohibit TLS > either, so fetchmail will - that's its default - look if it has the > opportunity to use TLS. Using 'sslproto ""' should defeat this CAPA > probe. This goes along with <http://www.fetchmail.info/fetchmail-FAQ.html#K6> Ok, I get that. Setting sslproto to an empty string prevents CAPA, indeed. But that wasn't necessary in rc3 (and AFAIR, many versions before). Not that it bothers me much, I just wonder why this changed. > 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and > subsequent polls? It shouldn't. I don't know, I use cron. |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 23:09:49
|
Jakob Hirsch <jh...@pl...> writes: > Quoting Matthias Andree: > >> 1. You did not ask for SSL, but you did probably not prohibit TLS >> either, so fetchmail will - that's its default - look if it has the >> opportunity to use TLS. Using 'sslproto ""' should defeat this CAPA >> probe. This goes along with <http://www.fetchmail.info/fetchmail-FAQ.html#K6> > > Ok, I get that. Setting sslproto to an empty string prevents CAPA, > indeed. But that wasn't necessary in rc3 (and AFAIR, many versions > before). Not that it bothers me much, I just wonder why this changed. That's actually a bug fix, but the necessary detail is missing from the NEWS file - I've just committed that information to SVN (rev. 4979). It wasn't necessary to suppress these with previous versions, because 6.3.6-rc3/6.3.5 and older were broken and didn't always probe when they should have. CAPA is a requisite for TLS, but these older versions only probe capabilities (which is a requisite for TLS) if you configure no specific authentication for a certain server (but let fetchmail guess), or configure GSSAPI, Kerberos V4, OTP or CRAM-MD5. (For some undocumented reason, Kerberos V5 hasn't been in this list, I presume that was an oversight.) -- Matthias Andree |
|
From: Volker K. <hi...@pa...> - 2006-11-29 19:13:55
|
> 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and > subsequent polls? It shouldn't. What if fetchmail runs for 3 months, and the server changed 2.5 months ago? And with *ix, 3 months is nothing. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. |
|
From: Matthias A. <mat...@gm...> - 2006-11-29 23:11:47
|
Volker Kuhlmann <hi...@pa...> writes: >> 3. Does fetchmail re-probe capabilities in daemon mode for the 2nd and >> subsequent polls? It shouldn't. > > What if fetchmail runs for 3 months, and the server changed 2.5 months > ago? And with *ix, 3 months is nothing. In that case, the way out is to have fetchmail re-execute itself. To achieve that, just touch the run control file ($HOME/.fetchmailrc, for instance) - if the mtime increases, fetchmail restarts. -- Matthias Andree |
Thanks for helping keep SourceForge clean.
X