It is not possible to provide meaningful IMAP log information in IMP 
4.  This is a limitation of c-client.  All of this has already been 
described in detail in this ticket.

Apparently, this problem still exists in horde 3.3.3
Problem is, the log doesn't contain more details either. Here is all 
we got, when this happened again today:



Mar 02 17:01:12 HORDE [error] [horde] FAILED LOGIN for warje 
[158.64.160.37] to Horde [on line 116 of "/usr/share/horde3/login.php"]



Pretty useless, IMHO.

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



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



[...]
See my attached patch. I supply a way.
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...).



[...]
Where can I download IMP5 from?

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

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

Alerts - never.  Alerts are designed (and required) to be displayed to 
the user; there is no need to log them.  The only reason the DEBUG log 
is in there now is in case an IMAP alert happens to sneak by.



For IMAP errors (from imap_errors()) - after further review, I believe 
the current way we handle errors - via debug logging only - is proper. 
  The main issue is that c-client throws all sorts of spurious errors 
that will quickly fill a long with useless information.  Here are some 
example errors:



Nov 30 20:45:40 HORDE [debug] [imp] IMAP errors: Invalid mailbox list: 
; [pid 3321 on line 184 of "/httpd/htsdocs/horde/imp/lib/IMAP.php"]



Dec 01 12:02:59 HORDE [debug] [imp] IMAP errors: Unexpected characters 
at end of address: <slusarz@curecanti.org> [pid 3318 on line 184 of 
"/httpd/htsdocs/horde/imp/lib/IMAP.php"]



These are *not* errors they should be showing up in a log configured 
for PEAR_LOG_ERR.  These are errors suitable for debugging only (these 
errors aren't even being thrown by the server - they are being thrown 
by c-client internals and deal with bad formatting, not an issue with 
the server or the client-server connection).  If an admin is truly 
having issues connecting to an IMAP server, they should either be 
diagnosing on the IMAP side or enabling debug logging while diagnosing 
the problem.  But logging these errors normally will make it difficult 
to realistically be able to parse a log for truly critical errors.



BTW, here is an example of an IMAP error from authentication failure:

Dec 01 06:05:31 HORDE [debug] [imp] IMAP errors: Retrying LOGIN 
authentication after AUTHENTICATE failed Retrying LOGIN authentication 
after AUTHENTICATE failed Can not authenticate to IMAP server: 
AUTHENTICATE failed [pid 3320 on line 184 of 
"/httpd/htsdocs/horde/imp/lib/IMAP.php"]



Not useful at all.  The information we currently provide to the end 
user is more than sufficient.

Since they are errors or even alerts, shouldn't we log them with 
PEAR_LOG_ERR then, or at least PEAR_LOG_NOTICE?

We do (see _onShutdown() in imp/lib/IMAP.php; albeit only at a DEBUG 
level presently).  The problem with doing it at login time is that 
imap_last_error() doesn't always return data on the login error - the 
only reliable way of capturing errors is via imap_errors() at the end 
of the access.

Okay. How about we log them then?

Disagree.  We have no control over the IMAP error returned from the 
server, and error msgs like "CRAM-MD5 lookup table blah blah blah" or 
"authentication backend returned no data" have no business being 
reported to the user.  These error messages, while useful to an ADMIN, 
are not useful to a USER.

Aside from the use of ereg for something that isn't a regular 
expression, this seems reasonable to me.

Michael, does this make sense to you?

Attached is a patch which fixes the issue

If the call to imap_open in the _authenticate function fails, this

function returns the generic (... and often misleading...) code

AUTH_REASON_BADLOGIN rather than calling imap_errors to get the real

reason