[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         | Michael Slusarz <slusarz at horde.org>
  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
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2008-12-02 22:20) 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.

Because IMP 4 does not talk directly to the IMAP server.  Please read  
what I have written in this ticket about  
c-client/imap_error/imap_last_error().  In IMP 5 this might change due  
to the switch in IMAP client, but for now, no.

> 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".

Thunderbird vs. IMP is a bad analogy.  If thunderbird is broken, *you*  
(as a user) must debug it.  If IMP is broken, a user can't do anything  
about it.  Instead, an admin must fix it.  And error message shown to  
a user isn't going to be that helpful - rather, and admin is going to  
look at a log (on either the IMAP or webmail side) to fix the problem.

> 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".

Exactly.  All of these auth drivers directly handle the connection to  
the backend so they can provide better error messages.  But how do we  
do that with this function?
http://us.php.net/imap_open

Again, you CAN'T rely on imap_last_error() to provide a meaningful  
description, so what are we supposed to report to the user?

> 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.

See above.

Regardless, this request has already become moot in IMP 5 where we can  
directly parse the IMAP status response returned by the IMAP server on  
any IMAP failure.