Description of problem: Since an update, fetchmail loops endlessly on a certain server (at least when my mailbox is empty). Version-Release number of selected component (if applicable): 6.2.0-9 How reproducible: sometimes user@host:/usr/local/Fedora_update/new > fetchmail -v gmx fetchmail: 6.2.0 querying pop.gmx.XX (protocol POP3) at Thu 12 Feb 2004 09:19:59 PM CET: poll started fetchmail: POP3< +OK GMX POP3 StreamProxy ready <30999. 1076617200@mp001> fetchmail: POP3> CAPA fetchmail: POP3< -ERR Unknown command. fetchmail: Unknown command. fetchmail: Repoll immediately on XxXxXxXx@pop.gmx.XX fetchmail: POP3< +OK GMX POP3 StreamProxy ready <21746. 1076617200@mp011> fetchmail: POP3> CAPA fetchmail: POP3< -ERR Unknown command. fetchmail: Unknown command. fetchmail: Repoll immediately on XxXxXxXx@pop.gmx.XX fetchmail: POP3< +OK GMX POP3 StreamProxy ready <5798. 1076617200@mp018> fetchmail: POP3> CAPA fetchmail: POP3< -ERR Unknown command. fetchmail: Unknown command. fetchmail: Repoll immediately on XxXxXxXx@pop.gmx.XX fetchmail: POP3< +OK GMX POP3 StreamProxy ready <31183. 1076617201@mp001> fetchmail: POP3> CAPA fetchmail: POP3< -ERR Unknown command. fetchmail: Unknown command. fetchmail: Repoll immediately on XxXxXxXx@pop.gmx.XX fetchmail: POP3< +OK GMX POP3 StreamProxy ready <31245. 1076617201@mp001> fetchmail: POP3> CAPA fetchmail: terminated with signal 2 Additional info: I updated from 6.2.0-6 to 6.2.0-9 just now. This has always worked before without a loop. Two other servers replying to "CAPA" worked fine, as always. You will get the relevant parts of my .fetchmailrc only upon request. ;-)
Here's the normal. expected behavior after a downgrade to 6.2.0-6: user@host:/usr/local/Fedora_update/new > fetchmail -v gmx fetchmail: 6.2.0 querying pop.gmx.XX (protocol POP3) at Thu 12 Feb 2004 09:39:44 PM CET: poll started fetchmail: POP3< +OK GMX POP3 StreamProxy ready <25204. 1076618384@mp017> fetchmail: POP3> CAPA fetchmail: POP3< -ERR Unknown command. fetchmail: Unknown command. fetchmail: Repoll immediately on XxXxXxXx@pop.gmx.XX fetchmail: POP3< +OK GMX POP3 StreamProxy ready <10672. 1076618385@mp007> fetchmail: POP3> USER XxXxXxXx fetchmail: POP3< +OK May I have your password, please? fetchmail: POP3> PASS fetchmail: POP3< +OK mailbox has 1 messages (36333 octets) fetchmail: POP3> STAT fetchmail: POP3< +OK 1 36333 [... and so on ... download of messages]
Confirmed. I get the exact same behaviour since upgrading to 6.2.0-9 (from whatever whas in Fedora development before that one). It doesn't make any difference whether there exists any fetchmailrc or not, so it can't be any option there being wrong. I also get this on one of the servers I poll (a .telia.com one) but not on any other.
Just because I've been waiting for this to be fixed, and have not seen a comment regarding a solution on the list or here, I will post that I have seen the exact same behaviour. Downgrading to 6.2.0-8 solves the problem. Looks like somebody broke fetchmail in 6.2.0-9... :-)
Just to note: It's still there in 6.2.0-10 :-/
*** Bug 118457 has been marked as a duplicate of this bug. ***
fetchmail-6.2.5-1 has appeared in "Fedora development". Is it anticipated that this version fixes this problem (couldn't check yet) ? The changelog doesn't explicitely say so, it just says the author of the program recommended an update.
No, it doesn't fix the problem, please look at #118457
Bug #118457 describes the issue as being caused by the fetchmail gsspop patch. This issue needs upstream attention. You should ask on their mailing list for help.
Why? This problem and #118457 are the same one - in my eyes, introduced by the gsspop patch, which came up between -6 and -9. From fetchmail's changelog: "fix gssapi support authenticating to imap, even when connected to pop" So why do we need a gssapi support, even when we connected to pop?
The problem in the gsspop patch is related to this test in pop3.c : (ctl->use_ssl != FLAG_FALSE). This variable is set to FALSE (0) in loadparams(), but FLAG_FALSE==1 in fetchmail.h. So this test passes although ssl is not used.
If possible, please submit an exact patch to drop into the SRPM. That will make it quicker to import for the package maintainer. Thanks.
Warren, this is a bogus RedHat patch, not an upstream bug. In order to fix it, we'd have to understand what the patch author (unattributed) was thinking. it's in: fetchmail-6.2.0-gsspop.patch I believe you'd have to make ((ctl->use_ssl != FLAG_FALSE)) into ((ctl->use_ssl != FALSE)) But it's still broken. If the use sets: "auth password" which is ctl- >server.authenticate == A_PASSWORD, it must not attempt CAPA. I'd prefer a patch like: - if (ctl->server.authenticate == A_ANY) + if ((ctl->server.authenticate != A_PASSWORD) && ( + (ctl->use_ssl != FLAG_FALSE) || + (ctl->server.authenticate == A_ANY) || + (ctl->server.authenticate == A_GSSAPI) || + (ctl->server.authenticate == A_KERBEROS_V4) || + (ctl->server.authenticate == A_OTP) || + (ctl->server.authenticate == A_CRAM_MD5) ) ) { Prodigy.net like this bug submitter's pop server has such a flaw that doesn't support CAPA. This turns fetchmail into a DoS tool against old pop servers...
Kenneth, your idea for the patch works very well for me, so I was free to merge it simply to the original old patch and distribute the complete adapted patch here for testing... ;-)
Created attachment 99073 [details] gsspop patch with merged patch proposal (for testing)
*** Bug 119894 has been marked as a duplicate of this bug. ***
Excellent, the patch in attachment #99073 [details] works for me! (I'm the original reporter.) Would the others who've come across this bug please also try to verify this fix? Perhaps Nalin (or Bill?) can then push it into a new Fedora devel / RedHat Rawhide package... (I haven't really reviewed the patch's code, though.)
Seems to work here too
I've been staring at this off and on for a while now, and I think the fix may be simpler still. Please try fetchmail-6.2.5-2 from http://people.redhat.com/~nalin/test/ in places where this popped up. I don't have a server which doesn't support CAPA here, but I'm pretty sure it'll work as expected.
Okay Nalin, I've tested your package and it works for me :)
Works here too
yes. hopefully this can be rolled in soon. will make for a lot of bug reports without it...
*** Bug 122576 has been marked as a duplicate of this bug. ***
I tested fetchmail-6.2.5-2 and is working perfect for me now. Thanks a lot!