Quoting Arminas <[email protected]>:
> 2010/9/7 Michael M. Slusarz <[email protected]>
>
> 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.
Obviously, this is something that can only be done locally since every
IMAP server produces a different error message/string.
>> 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?
All IMAP4rev1 clients MUST follow RFC 3501. RFC 3501 says that
response codes are OPTIONAL. RFC 5530 provides additional response
codes that a server can return.
So, technically speaking, imapproxy does not need to forward these
response codes because it is still acting in a IMAP4rev1 complaint
matter. However, practically speaking, this is bad proxy behavior
because (by definition) a proxy should be forwarding data
unadulterated. So it would be great if imapproxy could be extended in
this regard, especially since it opens things up 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).
..exactly this kind of feature. RFC 5530 very conveniently defines
the EXPIRED response code for exactly this reason. From RFC 5530[3]:
EXPIRED
Either authentication succeeded or the server no longer had the
necessary data; either way, access is no longer permitted using
that passphrase. The client or user should get a new
passphrase.
So given a RFC 5530 compliant server (e.g. Dovecot 2) and client (e.g.
IMP 5), end users will receive a nicely formatted error message
without any configuration needed on the client side of things. This
is *very* useful and would be a major drawback to using imapproxy if
it is not extended to handle these response codes.
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
