Confirmed (and fixed).  But this had nothing to do with these changes 
- this would have been broken by some error related changes made last 
month.

I didn't experience any problems running this in production in the 
last few days either. But trying a few less usual setups, I found one 
that still doesn't work:
If not using IMP for authentication, and disabling hordeauth too, when 
clicking on the webmail link after being authenticated to Horde, I'm 
still logged out of the complete Horde session, instead of getting the 
login form for IMP.

Merged to master after several days of successful testing.

https://github.com/horde/horde/compare/bug_12590

commit 7f38f489e746cf0d55298ae25d6c2d841168dda0
Author: Michael M Slusarz <slusarz at horde.org>
Date:   Tue Aug 20 21:41:44 2013 -0600

     [mms] Update session data stored with secret key if session ID 
changed and we are using non-cookie based sessions.

commit 74faf189977c45afcd33358458206cda6bcbbf34
Author: Michael M Slusarz <slusarz at horde.org>
Date:   Tue Aug 20 21:30:41 2013 -0600

     Use the new 'password' callable parameter to store password for 
Imap object

     This *should* transparently work around issue where secret key changes
     when IMP is used as the authentication application.

commit c7f951850f7601136428a2c01ce01dc473401bd1
Author: Michael M Slusarz <slusarz at horde.org>
Date:   Tue Aug 20 21:19:44 2013 -0600

     [mms] Add preferred way of retrieving password - by passing in 
callable to 'password' parameter.

commit 846d7b162e3d7f560eff664e47004ce6886c766b
Author: Michael M Slusarz <slusarz at horde.org>
Date:   Tue Aug 20 20:54:13 2013 -0600

     [mms] Horde_Session now handles resetting the secret key on login.

commit 309e8f6d9f254596a38d1f6314ccfb7642c83125
Author: Michael M Slusarz <slusarz at horde.org>
Date:   Tue Aug 20 20:54:49 2013 -0600

     Use new Horde_Session::ENCRYPT flag to store password in session

commit 4d85e082551f6974d1f511f1b8bc6fc7b922653a
Author: Michael M Slusarz <slusarz at horde.org>
Date:   Tue Aug 20 20:53:02 2013 -0600

     Use new Horde_Session::ENCRYPT flag to store password in session

commit 6d1df122dd44a0cd293eb12d22ca2826ace78ec4
Author: Michael M Slusarz <slusarz at horde.org>
Date:   Tue Aug 20 16:14:37 2013 -0600

     [mms] Add Horde_Session::ENCRYPT flag for session data.

Yuck yuck yuck.

This opened up a WHOLE can of worms today.  Let's see if I can recap...

It is true that non-cookie based sessions didn't work (not sure how I 
got this work a few days ago.  Thinking that I must not have disabled 
cookies entirely on the server).  Long story short - this is the 
long-standing issue that when IMP is used as the authentication 
handler, the password is first encoded using the secret key BEFORE the 
session is started.  This isn't a deal for cookie-based sessions 
(since the auth key was changed at the beginning of login.php, this 
value is used for the entire authentication access and doesn't change 
when the session ID is reset).  But non-cookie based sessions is 
problematic since the secret key is entirely tied to the session ID, 
which changes halfway through that request.

If that wasn't enough, I then realized that non-cookie based sessions 
can't handle our session regeneration code either - this code was 
added to prevent CSRF attacks.  When the session ID changes, all data 
encrypted using the old session ID would be invalidated, causing a 
logout (again, this isn't an issue with cookie-based sessions since 
the auth key doesn't change when the session ID does).

To prevent the latter, it is necessary to tie the session backend with 
storage of secret-encrypted data.  We need to track all session data 
keys that contain encrypted data, so we can re-encrypt whenever the 
session ID changes (this is only necessary on non-cookie based 
sessions).  This has the benefit of making storage encrypted data 
easier: now to store encrypted data you just need to add the 
Horde_Session::ENCRYPT mask when set()'ing the session data.  There is 
no need to know that the data is encrypted when get()'ing the data - 
this is all transparent, since we necessarily need to track the keys 
that are encrypted for the reasons described above.

Part 2 is shifting the encryption of password information in IMP from 
authentication time to serialization time.  By the time we serialize 
data, we necessarily need to have created the session.  This is 
accomplished by storing all password data via session (necessary since 
the secret key may change during the session).  This also required 
changing the way passwords are stored in the Horde_Imap_Client 
serialized object.  Before, we were passing the secret key needed to 
encrypt/decrypt the password.  But this suffers from the same problems 
as mentioned above.  Instead, this method has been deprecated and we 
now allow the 'password' parameter to be a callable object that 
returns the password.  This allows maximum flexibility - storage of 
the password can be accomplished in any manner and is not limited to 
what Horde_Imap_Client can do.

Long story short ... this should fix non-cookie based sessions.   
Additionally, this should fix the intermittent issues users reported 
about their passwords being "lost" when authenticated via IMP.  The 
combination of these 2 fixes are extremely important, and why this 
change -- although invasive -- needs to be immediately applied rather 
than waiting for another point release.

That being said, because of the invasive nature of these changes, I 
would like feedback/testing to make sure this works for everyone.  The 
code can be found in the "bug_12590" branch I have pushed to 
git.horde.org.  It would be great if people (especially devs) can look 
this over so this can be merged ASAP.

At the moment I cannot login to IMP without cookies at all.

If authenticating Horde via IMP or using hordeauth, I can login to 
Horde, but IMP is deactivated. If doing neither, IMP is activated, but 
as soon as I click on the webmail links, I'm not simply sent to the 
login page for IMP, but completely logged out of Horde.