Quoting Paul Lesniewski <firstname.lastname@example.org>:Paul is correct, although this is not necessarily incorrect behavior.
> On Tue, Sep 7, 2010 at 5:16 AM, Arminas <email@example.com> wrote:
>> 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.
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).
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.
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: firstname.lastname@example.org
List archives: http://news.gmane.org/gmane.mail.squirrelmail.imapproxy
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-imapproxy