| Summary | Can't use horde together with imapproxy anymore |
| Queue | IMP |
| Queue Version | 6.2.2 |
| Type | Bug |
| State | Not A Bug |
| Priority | 1. Low |
| Owners | |
| Requester | horde (at) immerda (dot) ch |
| Created | 09/21/2014 (3917 days ago) |
| Due | |
| Updated | 09/22/2014 (3916 days ago) |
| Assigned | |
| Resolved | 09/22/2014 (3916 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
State ⇒ Not A Bug
In short: imapproxy can't be used with non-ASCII authentication
credentials. (I believe this is a long-known issue with imapproxy
that nobody has bothered to fix yet. But that's what needs to be
fixed).
https://github.com/horde/horde/blob/master/framework/Imap_Client/lib/Horde/Imap/Client/Socket.php#L732 with: $password = '"'.$password.'"'; makes it possible to use imapproxy again with nonascii
characters.
This is likely not what we want in the end, but it shows what worked
before and is a quick'n'dirty workaround.
the time being.
http://www.horde.org/apps/imp/docs/PERFORMANCE and that nonascii
character passwords are very likely and that modern imap-servers
(e.g. dovecot) do not have a problem with login commands with
nonascii characters, there should be a way to get the old behavior
back.
https://github.com/horde/horde/blob/master/framework/Imap_Client/lib/Horde/Imap/Client/Socket.php#L732 with: $password = '"'.$password.'"'; makes it possible to use imapproxy again with nonascii
characters.
This is likely not what we want in the end, but it shows what worked
before and is a quick'n'dirty workaround.
Priority ⇒ 1. Low
Patch ⇒ No
Milestone ⇒
Queue ⇒ IMP
Summary ⇒ Can't use horde together with imapproxy anymore
Type ⇒ Bug
State ⇒ Unconfirmed
together. It worked fine and without any problems.
After installing the latest Updates from a few days ago, everything
seemed to work fine, but we started getting complains, that certain
users are not anymore able to login. While most of the users just
worked fine.
While investigating the issue, we figured out, that all the
complaining users were likely using nonascii characters within their
passwords. Debugging the issue further let us to
#13554and the changein
https://github.com/horde/horde/commit/10a822329f9fcaa8026de4c1e56de637554cf261
&
https://github.com/horde/horde/commit/ecea895075319793c034a30a625be1bc5db60a6c
Further we debugged http://imapproxy.org/ and figured out that only
AUTH=LOGIN is supported by it.
So summarizing the issue:
Up to 10a822329f9fcaa8026de4c1e56de637554cf261 the method
Horde_Imap_Client_Data_Format_Astring didn't complain about nonascii
chars and hence horde just used the LOGIN method in combination with
an imapproxy. Because our backend imap-server (dovecot) accpeted
nonascii characters with the LOGIN method this worked fine.
After the change to Horde_Imap_Client_Data_Format_Astring logins using
passwords with nonascii characters stopped working, because the method
was now throwing an error.
However, given that imapproxy does only support AUTH=LOGIN there is no
way atm to use horde together with imapproxy.
Furthemore, the errormessage thrown at
https://github.com/horde/horde/blob/master/framework/Imap_Client/lib/Horde/Imap/Client/Socket.php#L735 is very general and hence misleading, because you need to dig into the code to figure out, that it failed because of character
issues.
Givent that imapproxy is recommended by
http://www.horde.org/apps/imp/docs/PERFORMANCE and that nonascii
character passwords are very likely and that modern imap-servers (e.g.
dovecot) do not have a problem with login commands with nonascii
characters, there should be a way to get the old behavior back.