2010/9/7 Michael M. Slusarz <slusarz@curecanti.org>
Quoting Paul Lesniewski <paul@squirrelmail.org>:

> On Tue, Sep 7, 2010 at 5:16 AM, Arminas <g.arminas@gmail.com> wrote:
>> Hi,
>> we're using IMAP Proxy program to speed up "Horde" webmail (both are on the
>> same machine). Unfortunately, after installing the I-Proxy, we saw that one
>> (at least) IMAP error, returned from mailserver is wrong. It happends to
>> users whose password is expired. Before IMAP Proxy, "Horde" was configured
>> to communicate with IMAP server directly and if user's password is expired,
>> the mail server returned this IMAP error: "Can not authenticate to IMAP
>> server: Password expired". After installing IMAP Proxy, IMAP error is:
>> "LOGIN failed Too many login failures".
> I do not believe IMAP Proxy has logic to deal specially with such an
> error, and any login failure is simply considered no more than just
> that.  I can't promise anything, but can consider this as a feature
> request in the future.  Please also show your IMAP server and relevant
> configuration settings for testing purposes.

Paul is correct, although this is not necessarily incorrect behavior.
RFC 3501 does not define what a server must return on an
authentication failure other than returning an IMAP NO response.  Your
particular IMAP server MAY provide further information in the
response, but that is not required.

Imapproxy correctly returns a NO response if the authentication
failed, which is all that the RFCs require.  Returning the response
string is probably not all that useful (especially since this response
string is most likely in English, which may not be very useful to
display to the end user).

Yes, its not that useful to return full imap response string to the users. We've made some changes in our IMP-4 so it can catch IMAP response string, and if it contains "Can not authenticate to IMAP server: Password expired", user is automatically redirected to form where he can change his password. Because imap-proxy returns same response for all authentication failures, webmail is not able to detect if user's password is expired. Everytime our webmail shows same error "Wrong username and/or password". In this case users are sending lots of emails with such quesstions "What's wrong with my account, yesterday my credentials was just fine and now its not working", or smth.

That being said, RFC 5530 does define additional response codes to
give a more accurate explanation of what went wrong.  These response
codes SHOULD be retained and passed back to the client.  IMP 5, for
example, uses these response codes to generate the failure message
(again, since there is no guarantee as to the quality/language of the
response text, if any, this text should not be shown to the enduser.
IMP 4 was unfortunately limited by what c-client would provide, which
is inconsistent and not accurately documented).  So if imapproxy isn't
doing this, that should be fixed/changed.

I'm little bit confused. :) You've said that RFC 3501 does NOT define what server should return after authentication failure, but RFC 5530 it does and it should be retained and passed back to the client. So which RFC imapproxy must work according to?

However, imap-proxy doesnt retain and return additional error codes (or strings) to the client - at least the error code that we're talking about (users with expired passwords).


This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
squirrelmail-imapproxy mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-imapproxy@lists.sourceforge.net
List archives: http://news.gmane.org/gmane.mail.squirrelmail.imapproxy
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-imapproxy