On Wed, Sep 8, 2010 at 2:46 PM, Michael M. Slusarz <slus...@curecanti.org> wrote: > Quoting Arminas <g.armi...@gmail.com>: > >> 2010/9/7 Michael M. Slusarz <slus...@curecanti.org> >> >> 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...
I have committed a patch to our repository that passes the full server response through to the client in the case of NO and BAD responses against LOGIN and AUTHENTICATE requests (log information now also includes the full server response). The code should be available as a snapshot on our downloads page within 24 hours (and is available via SVN now). Testers appreciated. Also, if anyone has opinions about other contexts where IMAP Proxy could return something more useful, let us know. >> 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. -- Paul Lesniewski SquirrelMail Team Please support Open Source Software by donating to SquirrelMail! http://squirrelmail.org/donate_paul_lesniewski.php ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ----- 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
