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

* Your Email Address
* Spam protection	Enter the letters below: . . ..___..__.. . \| \| \| \| \| \|\|\/\| \|__\|\__\| \| \|__\|\| \|
Comment	>> 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? > >
Attachment
Watch this ticket

Saved Queries