2010/9/7 Michael M. Slusarz <[email protected]>
> 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).
>
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).
>
> 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
>
Arminas
------------------------------------------------------------------------------
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
