[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 22:37) wrote:

> Because IMP 4 does not talk directly to the IMAP server.

So what exactly sits in between Horde and the IMAP server?

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

Well, I think that actually depends on the problem. If a user really  
did mistype his password, he can do something about it: try again.
So, IMP is indeed broken by mixing user-fixable problems (bad  
passwords) with non-user-fixable problems (imap server not running)

>  Instead, an admin must fix it.

Well, if the server is not running, an admin must fix it, even if the  
user uses Thunderbird. However, it is still useful to find out where  
the error lies, and whom to call.

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

We try to teach our users to look at error messages... for these cases  
where they _can_ do something about it (mistyped passwords, mistyped  
addresses, mails that are too long, ...). How can we ask them to trust  
the error messages if the messages are often wrong?
With this kind of messages, user will submerge our help desk with  
calls whenever they are fat fingered because "last time it said 'bad  
password', and it really was the system that was broken"

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

See my attached patch. I supply a way.

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

Well, at least in 3 common cases (tested with server not running, bad  
certificate, and bad password), it does supply a more meaningful  
description that in the unpatched code. It may not be 100% (had only  
these 3 cases to test, sorry), but it's sure better than what is there  
now (correct in only one case, in the same sense as a stopped watch  
shows the correct twice per day...).

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

Where can I download IMP5 from?