Bug 115474 - [PATCH] fetchmail gsspop patch seems to cause endless looping
[PATCH] fetchmail gsspop patch seems to cause endless looping
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: fetchmail (Show other bugs)
rawhide
i686 Linux
high Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
: 118457 119894 122576 (view as bug list)
Depends On:
Blocks: FC2Blocker
  Show dependency treegraph
 
Reported: 2004-02-12 15:30 EST by Moritz Barsnick
Modified: 2007-11-30 17:10 EST (History)
7 users (show)

See Also:
Fixed In Version: 6.2.5-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-22 15:50:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gsspop patch with merged patch proposal (for testing) (3.29 KB, patch)
2004-04-02 10:15 EST, Robert Scheck
no flags Details | Diff

  None (edit)
Description Moritz Barsnick 2004-02-12 15:30:14 EST
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@gmx.XX@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@gmx.XX@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@gmx.XX@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@gmx.XX@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. 
 ;-)
Comment 1 Moritz Barsnick 2004-02-12 15:39:57 EST
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@gmx.XX@pop.gmx.XX
fetchmail: POP3< +OK GMX POP3 StreamProxy ready <10672.
1076618385@mp007>
fetchmail: POP3> USER XxXxXxXx@gmx.XX
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]
Comment 2 Daniel Malmgren 2004-02-19 11:22:20 EST
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.
Comment 3 Mark Mielke 2004-03-02 11:00:12 EST
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... :-)
Comment 4 Daniel Malmgren 2004-03-14 03:31:06 EST
Just to note: It's still there in 6.2.0-10 :-/
Comment 5 Bill Nottingham 2004-03-16 17:49:02 EST
*** Bug 118457 has been marked as a duplicate of this bug. ***
Comment 6 Moritz Barsnick 2004-03-17 04:15:04 EST
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.
Comment 7 Robert Scheck 2004-03-17 04:24:43 EST
No, it doesn't fix the problem, please look at #118457
Comment 8 Warren Togami 2004-03-17 04:32:11 EST
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.
Comment 9 Robert Scheck 2004-03-17 04:41:42 EST
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?
Comment 10 Fabrice Bellet 2004-03-17 17:35:02 EST
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.
Comment 11 Warren Togami 2004-03-19 00:00:32 EST
If possible, please submit an exact patch to drop into the SRPM.  That
will make it quicker to import for the package maintainer.  Thanks.
Comment 12 Kenneth Topp 2004-04-02 09:04:28 EST
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...
Comment 13 Robert Scheck 2004-04-02 10:13:35 EST
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... ;-)
Comment 14 Robert Scheck 2004-04-02 10:15:20 EST
Created attachment 99073 [details]
gsspop patch with merged patch proposal (for testing)
Comment 15 Bill Nottingham 2004-04-06 00:58:52 EDT
*** Bug 119894 has been marked as a duplicate of this bug. ***
Comment 16 Moritz Barsnick 2004-04-16 15:35:51 EDT
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.)
Comment 17 Nicolas Mailhot 2004-04-17 08:02:20 EDT
Seems to work here too
Comment 18 Nalin Dahyabhai 2004-04-21 22:23:09 EDT
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.
Comment 19 Robert Scheck 2004-04-22 01:48:07 EDT
Okay Nalin, I've tested your package and it works for me :)
Comment 20 Nicolas Mailhot 2004-04-22 01:51:57 EDT
Works here too
Comment 21 Kenneth Topp 2004-04-22 08:10:00 EDT
yes.  hopefully this can be rolled in soon. will make for a lot of bug
reports without it...
Comment 22 Nalin Dahyabhai 2004-05-05 17:46:44 EDT
*** Bug 122576 has been marked as a duplicate of this bug. ***
Comment 23 Fernando Fernandez Pedraza 2004-05-05 22:02:39 EDT
I tested fetchmail-6.2.5-2 and is working perfect for me now.
Thanks a lot!

Note You need to log in before you can comment on or make changes to this bug.