[Tickets #7720] Re: _authenticate function in Horde/Auth/imap.php fails to read imap error status

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7720
------------------------------------------------------------------------------
  Ticket             | 7720
  Updated By         | horde at misc.lka.org.lu
  Summary            | _authenticate function in Horde/Auth/imap.php fails to
                     | read imap error status
  Queue              | Horde Base
  Version            | 3.1.7
  Type               | Enhancement
  State              | Rejected
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


horde at misc.lka.org.lu (2008-12-02 20:59) wrote:

I don't quite understand the logic of all this. Couldn't Horde behave  
just like any other Imap client, such as Thunderbird? Thunderbird for  
instance _does_ give exact error messages, rather than lie to the  
user. If the server is not running, Thunderbird _does_ say "Connection  
refused". If the server has a bad certificate, Thunderbird pops up a  
dialog box asking the user whether he wants to accept it anyways. For  
some weird reason, Thunderbird doesn't think "users are too dumb to  
understand error messages". Frankly this attitude makes me think more  
about a Microsoft tool than quality open source software. If a user  
does indeed enter a correct user name and password, he should _never_  
get "your username or password was entered incorrectly".

Moreover, a cursory examination shows that even Horde itself tries to  
return correct messages for other back ends than Imap. For example,  
Samba (lib/Horde/Auth/smb.php, lib/Horde/Auth/smbclient.php), Radius  
(lib/Horde/Auth/radius.php), SASL (lib/Horde/Auth/pam.php,  
lib/Horde/Auth/peclsasl.php), PAM (lib/Horde/Auth/pam.php), LDAP  
(lib/Horde/Auth/ldap.php) all do make use of AUTH_REASON_MESSAGE to  
communicate failure reasons such as "Failed to connect to SMB server"  
or "Failed to create new SASL connection".

And what's worse, even the admin doesn't see the failure reason; all  
that is in the log is
Dec 03 02:44:22 HORDE [error] [horde] FAILED LOGIN for a  
[83.99.45.228] to Horde [on line 116 of "/usr/share/horde3/login.php"]
without any reason _why_ the login failed.
Nobody asks you to log all spurious IMAP debug messages. But if a  
situation is sufficiently serious that an IMAP API call fails, the  
reason why it failed should definitely not be lost.

Right now we are in a situation where we tell our users and assistant  
admins on duty "if Horde behaves weird, please try the same thing in  
Thunderbird, and check what Thunderbird says".