The code change look good to me, thanks.
I'll check it next week in detail.

Please reopen in case the current approach does not work for you.

Ah, now I understand.
Yes, true.
As this is just the mail address in the object I guess it could be 
done that way. But it feels little bit too much like a hack to me. 
Especially since we should have the possibility to retrieve the users 
primary mail address from LDAP on any reasonable Kolab server.

This is what I implemented in the new framework now. The Session 
handler was fetching the Kolab user object anyhow, so retrieving and 
storing the primary mail was just a small addon. I added your solution 
in the session handler as a last backup in case querying the LDAP 
server didn't help.

The session handler caches the primary mail address so it should not 
slow down the writing of Kolab messages to IMAP by first querying LDAP.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/Kolab/Kolab/Storage/Folder.php?r1=1.7&r2=1.8&ty=u
http://cvs.horde.org/diff.php/framework/Kolab/Kolab/Storage/Session.php?r1=1.1&r2=1.2&ty=u
http://cvs.horde.org/diff.php/framework/Kolab/tests/Horde/Kolab/Storage/DataTest.php?r1=1.2&r2=1.3&ty=u
http://cvs.horde.org/diff.php/framework/Kolab/tests/Horde/Kolab/Storage/ListTest.php?r1=1.2&r2=1.3&ty=u
http://cvs.horde.org/diff.php/framework/Kolab/tests/Horde/Kolab/Storage/SessionTest.php?r1=1.2&r2=1.3&ty=u

I'm using IMP as Auth backend, which authenticates against an IMAP server.

Everything works fine, no complaints from the users so far. If some 
part of the Kolab subsystem does work only with the Kolab Auth backend,
then it needs fixing :-)

I'll have an idea that satisfies both your needs: Why not check the 
From: and To: address for the "@" character and append "@localhost" 
only if it is not found?

Thomas

Ups, somehow missed your response to this one. Sorry for the late reply...

Are you using the Auth::kolab driver then? The kolab driver should 
rewrite the user id to the primary mail adress (see the setAuth() 
function in that driver). It looks like you are using UIDs in your 
system. At least in former times that was problematic for other Horde 
subsystems and that is why the kolab driver does the rewrite. I admit 
I don't remember exactly what the effects of using a UID were. But my 
gut feeling is that even with our new infrastructure it makes more 
sense to use the primary Kolab ID.

Oh, Auth::getAuth() always returns just the username for me. If it 
returns a complete email address, then my patch needs some tweaking. 
It happens for all users IIRC.

Auth::getAuth() is defined as "user id". I'm not sure if it always 
must contain an @domain part.

This looks not okay to me.

Auth::getAuth() will usually resolve to something like wrobel@example.org.

Your patch would lead to "wrobel@example.org@example.org" or am I 
missing something?

You are having that problem on the special users (like admins, 
maintainers etc.)? Or on standard users? For a standard Kolab user 
Auth::getAuth() should ALWAYS return a valid mail address. Otherwise 
the inital UID rewrite failed.

Hello Gunnar,

attached patch silences a stupid warning on creation/update of a Kolab object.
The warning looks like this:

[Thu Jun 12 11:06:32 2008] [error] [client 172.16.1.2] PHP Notice:   
Unknown: Missing or invalid host name after @ (errflg=3) in Unknown on 
line 0, referer: 
http://intratest3.m.i2n/horde/turba/contact.php?source=friedrich&key=200806121 
...

Thomas