It appears after another couple of hours of debugging and trying that depending on the excact circumstances, the GSS library in use may return when the actual AUTH SASL process has not completed, for instance, because credentials are missing.
However, fetchmail has never cancelled the authentication phase properly in that situation. Ever since the gssapi.c code had been added to fetchmail in February 2001, fetchmail sent a blank line "to wake up the server", which worked in some circumstances. However, according to various RFCs (1734/5034, 3501), fetchmail was supposed to send an asterisk, *, on a line by its own, to really cancel the AUTHentication phase. Also, the authentication framework in fetchmail sent the star to cancel things a bit later, but did not wait for and did not pick up the authentication error message that the server is required to send. This caused fetchmail to go out of synch and mistake the GSSAPI AUTH error for an error response to the later USER command. Relevant changes that should fix the bug but require testing are in the upstream test release 6.3.18-pre2; it is spread out across various commits in Git unfortunately. I'd propose that 6.3.18-pre2 be packaged for experimental, or for unstable with a marker to NOT migrate to testing until we have evidence that the bug is really fixed in -pre2. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
