Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.3.8

Bug #1942 wrong parameter-type specification in Net_POP3::login
Submitted: 2004-07-22 00:05 UTC
From: swolfsheimer at netz98 dot de Assigned: damian
Status: Closed Package: Net_POP3
PHP Version: Irrelevant OS:
Roadmaps: (Not assigned)    

 [2004-07-22 00:05 UTC] swolfsheimer at netz98 dot de
Description: ------------ In the PEAR manual following declaration is specified: boolean Net_POP3::login (string $user string $pass boolean $apop) Am I right, that the last parameter $apop is not of type boolean, but of type "boolean or string"? By looking into the source code and following the parameter over serval function-calls, one can find a switch (in function _cmdAuthenticate) between the strings 'DIGEST-MD5', 'CRAM-MD5', 'APOP', 'PLAIN' , 'LOGIN', 'USER' or alternativly a false - value for this parameter. following code gives not the result as expected according to the documentation: $pop3->login($user, $pass,true); this would be the correct call: $pop3->login($user, $pass,"APOP"); Another thing: Since the last(?) update of the Net_POP3 class-documentation there are the wrong classnames (Net_Ping instead of Net_POP3) given on the overview page ( Net_Ping::Net_POP3() and so on) Reproduce code: ---------------


 [2004-07-29 12:27 UTC] mj
After examining the code of Net_POP3, I cannot find any evidence that the third parameter should be a string. Can you point us to the place in the code that makes you think so? Apart from that I've fixed the bogus usage of Net_Ping.
 [2004-08-02 18:23 UTC] swolfsheimer at netz98 dot de
in my case neither $apop=true nor $apop=false worked. Only $apop "USER" was correct. I am not very familar with the POP3 protocol, so I only can try to obtain my opion by logical arguments: the login functions calls _cmdAuthenticat($user,$pass,$apop) with the critical parameter $apop (see pseudo code below). From _cmdAuthenticate($uid , $pwd , $userMethod = null first _getBestAuthMethod($userMethod) is called, and the result ist stored in $method, followed by a switch, which desides between serval string statements. Well, let's have a look how _getBestAuthMethod($userMethod)works in my case: Consider the case, that no $this->_capability['sasl'] was found, e.g. $serverMethods are set to array('APOP','USER'). Now consider, that I want to login with the 'USER'-method, according to the documentation this would be the boolean value false. The statement "if($userMethod !== null && $userMethod !== true )" would be true (because false is not of the same type as null), and false would be returned by the function. But this causes the default switch in the _cmdAuthenticate - function, which is an error-handler. But if $apop would be a string of the value "USER" everything works fine. function login($user, $pass, $apop = true) { ... $this->_cmdAuthenticate($user , $pass , $apop ) ... } function _cmdAuthenticate($uid , $pwd , $userMethod = null ) { ... $method = $this->_getBestAuthMethod($userMethod); ... switch($method) { case 'DIGEST-MD5': ... case 'CRAM-MD5': case 'LOGIN': case 'PLAIN': case 'APOP': case 'USER': default : ERROR } ... } function _getBestAuthMethod($userMethod = null) { ... if( isset($this->_capability['sasl']) ){ $serverMethods=$this->_capability['sasl']; }else{ $serverMethods=array('APOP','USER'); } ... if($userMethod !== null && $userMethod !== true ) { $methods = array(); $methods[] = $userMethod; return $userMethod; } ... }
 [2005-03-27 16:43 UTC] danielc
Changing category/package from "Documentation" to "Net_POP3" in hopes of getting this very old bug fixed.
 [2005-04-05 02:23 UTC] damian
Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at
 [2005-08-08 12:09 UTC] g dot o dot crawford at gmail dot com
As far as I can see, this bug is still very much alive in the latest release - v1.3.6. I can't use TRUE or FALSE as the third parameter for login(), I am forced instead to use 'APOP' or 'USER'. I am slightly concerned by the internal ID line at the top of the POP3.php file: $Id: POP3.php,v 1.2 2004/12/05 16:34:39 damian Exp $ Does this suggest the file is not v1.3.6 at all, but an older version? I would appreciate some other feedback - do other users find that the bug is fixed or not?
 [2005-10-27 05:37 UTC] aavaria at gmail dot com
I ran into this problem today also. I had written a script to check multiple email boxes and it would only work with one of them. I ended up having to use the following to get it to work correctly: if(PEAR::isError( $ret=$myPop3->login($this->User,$this->Pass, 'USER') )){ echo "ERROR: " . $ret->getMessage() . "\n"; } using release v1.3.6
 [2006-11-30 15:23 UTC] rbolzendahl at netzkraefte dot de (ronnyB)
Bug is still not fixed. Tried to login with $pop3->login('user','pass', FALSE) error (using the toString() method on PEAR_ERROR object): pear_error: message=" is not a supported authentication method" using 'USER' instead of FALSE works perfectly. A fix in the docs or the method would be nice!
 [2008-05-27 00:20 UTC] homersim (Lance Fordham)
I have found this bug to exhibit itself when connecting to only a small fraction of the servers I connect to... I typically just use the login command like this: $ret = $pop3->login($mail_username, $mail_password, 'USER'); and it works well for servers using APOP and those not using it... took me a while to figure it out though.