Description: ------------ "IMPLEMENTATION" "Cyrus timsieved v2.2.13" "SASL" "LOGIN PLAIN CRAM-MD5" All without TLS or SSL PLAIN auth works just fine. CRAM-MD5 hangs until it times out and then succeeds causing a long delay during sieve login. We traced the hang to Line 947 in Sieve.php $this->_recvLn(); commenting this line out cures the problem. when we simulate the conversion using telnet, we notice that after a AUTHENTICATE "CRAM-MD5" timsieved responds with: {56} PDE4NDMyMjA0NDAuNTM2NzQ1MkB0YWthcHVuYS5yZWFsdHNwLmNvbT4= which is exactly 58 characters (incl newlines) but then the _recvLn() call expects to read an additional line. We do not see what input it is looking for in the telnet session, the comment on Line 946 seems to indicate that it is waiting for an OK: // receive the pending OK however there does not appear to be an OK due at this stage of the Auth process. Just commenting recvLn() is probably not the correct final solution. I guess it was there for something? Maybe only look for the "OK" in some cases? optional parameter to doCmd()? this patch works for me: --- /usr/local/share/pear/Net/Sieve.php Wed Nov 8 14:45:53 2006 +++ /usr/local/share/pear/Net/Sieve.php.orig Wed Nov 8 14:44:45 2006 @@ -504,7 +504,7 @@ */ function _authCRAM_MD5($uid, $pwd, $euser) { - if ( PEAR::isError( $challenge = $this->_doCmd( 'AUTHENTICATE "CRAM-MD5"', false ) ) ) { + if ( PEAR::isError( $challenge = $this->_doCmd( 'AUTHENTICATE "CRAM-MD5"' ) ) ) { $this->_error=challenge ; return challenge ; } @@ -872,7 +872,7 @@ * @param string $cmd The command to send * @return mixed Reponse string if an OK response, PEAR_Error if a NO response */ - function _doCmd($cmd = '', $expect_ok = true ) + function _doCmd($cmd = '' ) { $referralCount=0; while($referralCount < $this->_maxReferralCount ) { @@ -944,7 +944,7 @@ echo "S:$line\n"; } // receive the pending OK - if ($expect_ok) $this->_recvLn(); + $this->_recvLn(); return $line; } $response .= $line . "\r\n"; Test script: --------------- Problem occurs when using latest horde/INGO (1.1.3) with the above timsieved. Expected result: ---------------- immediate login (IMP logs in immediately) Actual result: -------------- very delayed login due to __recvLn() waiting for input that never arrives.

we tested and the same happens with DIGEST-MD5, the same patch fixes that also.

better patch which comforms to coding standards and includes the additional "false" parameter for DIGEST-MD5 as well. --- /usr/local/share/pear/Net/Sieve.php Wed Nov 8 14:56:58 2006 +++ /usr/local/share/pear/Net/Sieve.php.orig Wed Nov 8 14:44:45 2006 @@ -504,7 +504,7 @@ */ function _authCRAM_MD5($uid, $pwd, $euser) { - if ( PEAR::isError( $challenge = $this->_doCmd( 'AUTHENTICATE "CRAM-MD5"', false ) ) ) { + if ( PEAR::isError( $challenge = $this->_doCmd( 'AUTHENTICATE "CRAM-MD5"' ) ) ) { $this->_error=challenge ; return challenge ; } @@ -537,7 +537,7 @@ */ function _authDigest_MD5($uid, $pwd, $euser) { - if ( PEAR::isError( $challenge = $this->_doCmd('AUTHENTICATE "DIGEST-MD5"', false) ) ) { + if ( PEAR::isError( $challenge = $this->_doCmd('AUTHENTICATE "DIGEST-MD5"') ) ) { $this->_error=challenge ; return challenge ; } @@ -872,7 +872,7 @@ * @param string $cmd The command to send * @return mixed Reponse string if an OK response, PEAR_Error if a NO response */ - function _doCmd($cmd = '', $expectOk = true ) + function _doCmd($cmd = '' ) { $referralCount=0; while($referralCount < $this->_maxReferralCount ) { @@ -943,10 +943,8 @@ if($this->_debug){ echo "S:$line\n"; } - // receive the pending OK if expecting one - if ($expectOk) { - $this->_recvLn(); - } + // receive the pending OK + $this->_recvLn(); return $line; } $response .= $line . "\r\n";

Would you email me the diff? Thanks.

I've applied a different fix to the CVS for this problem. Please confirm it works for you. I've just tested it with DIGEST authentication on one of my Sieve servers and it works fine.

perfect...works nicely for me and is clearly better than my patch. thanks

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.