Quoting Paul Lesniewski <[email protected]>: > On Tue, Sep 7, 2010 at 5:16 AM, Arminas <[email protected]> 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). 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. michael ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ----- squirrelmail-imapproxy mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: [email protected] List archives: http://news.gmane.org/gmane.mail.squirrelmail.imapproxy List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-imapproxy
