A few years ago, I started to grow tired of having different Address Books at work and at home, each with a partial, and sometimes out of date list of contacts. So I started to look for a solution that would allow me to maintain only one copy that was accessible mainly at home and work, but any where else on the internet I might pop up.
At the time, I was using various flavors of the Ximian Evolution groupware client. And I had noticed that for address books it supported an LDAP provider. And after various emails to the OpenLDAP and Evolution mailing lists both to try to get information about Evolution's requirements of LDAP, and also to complain that there was no cookbook to show a simple OpenLDAP configuration, I managed to get everything working. And the world was good.
But I started to grow unhappy with Evolution for multiple reasons. Which was unfortunate because it has a really great address book, the Virtual Folders (aka Views in DtMail lingo), were pretty good too, however I started to outgrow some of its ability to manage mail folders. It seemed to do weird things with scanning lots and lots of mail folders just during what would seem to be a simple check of my INBOX which would cause the entire interface to pause for up to 30 seconds a time. Pretty annoying when you're in the middle of typing an email.
So I took a look at this fledgling mail client called Mozilla Thunderbird. And after looking at it, I found that it supported something they call Saved Searches, which do pretty much the same thing as Evolution's Virtual Folders. And after a little testing I found that it did not appear to have any problems with subscribing to lots of big mail folders, so perhaps 4 months ago I made the switch and dumped Evolution entirely.
Now, recently I started to look at trying to get my LDAP Address Book back, and doing some initial poking around I saw that Thunderbird did, in fact support an LDAP provider. So I eagerly gave it a try, plugged in my host and port, and basedn, and gave it a whirl. The results were less than awe inspiring. Although it did show the basic info like name and email address, it did not show all of the street addresses for example and most other personal information. Well, whatever, looks like its going to be more work that I wanted to do, so I put it on the back burner for a while.
Until a last week. I gave another whack at it. First of all I remember when I set things up for Evolution, it expected a special evolutionPerson LDAP schema. So I wondered if there was something similar for Thunderbird, and after doing a bit of Googling[tm]. I found a few sites that mentioned both mozillaOrgPerson schema and a mozillaABPersonObsolete schema. That second one doesn't sound that hot, so I started to pursue the first one.
I found this dude Jason Jason's Notes who appeared to get things working ok. So I grabbed a copy of the mozillaOrgPerson schema, installed it in my OpenLDAP server, created an entry which included some attributes from mozillaOrgPerson, then tried to load it into Thunderbird.... No love.
Jason's post mentions an article on linux.com. So I took a look at it. They appear to have gotten things working too. What the heck? So I go back and do some more tinkering around. I start wondering in Thunderbird may be caching entries locally somehow, so I exit it and restart it multiple times, and change some fields I know I can see, just to confirm that it isn't caching anything locally. Well, I'm not loosing my brain there.
Continuing down the link trail, the linux.com article mentions a few Thunderbird bugs filed regarding LDAP support. I take a peek at the bugs an notice they are all talking about the mozillaOrgPerson schema again. That's really of no help because I had pretty much proved to myself that the attributes in mozillaOrgPerson are ignored by Thunderbird.
I should mention that at some point I found the the document LDAP in Mozilla Thunderbird which has a lot of good info, but considering the date of the document compared to work on the aforementioned bugs, I dismissed this document as the typical OpenSource documentation kruft.. I mean really the document was last updated in 2003, thats centuries in Internet Time.
Instead, I started to search around for this mozillaABPersonObsolete LDAP schema. I figured that although it may be an older schema, if Thunderbird recognizes it, then so be it. Only problem was that I really didn't find much to go on.
Now this is really driving me crazy. I clearly see in the Thunderbird Address Card a huge amount of fields, more specifically, I was interested in the Home Address fields. Why would this appear in the interface if they are unused. I know now that I was a little too focussed on the LDAP provider side of things. I realize now, that the same Address Card is used for the built-in File-based provider. And in that mode, I can managed Home Addresses.
But before I realized this, I was still hopeful that I could see something in the LDAP-based Home Address fields. So I decided to do some brute force work. This is where snoop is definitely your friend. I fired up snoop, then brought up the Address Book and captured the packets. I was hoping over-the-wire, LDAP was a (mostly) text based protocol, and fortunately it is. I decrypted the packets enough to see what was going on.
I found that a query was being issued against the LDAP attributes (mail, cn, givenname and sn). Ok, nothing too surprising there. However, the set of attributes that were returned are (modifytimestamp, xmozillausehtmlmail, description, notes, custom4, custom3, custom2, custom1, birthyear, homeurl, workurl, nscpaimscreenname, countryname, company, o, departmentnumber, department, orgunit, ou, title, countryname, zip, postalcode, region, st, locality, l, streetaddress, postofficebox, carphone, cellphone, mobile, pagerphone, pager, facsimiletelephonenumber, fax, homephone, telephonenumber, xmozillasecondemail, mail, xmozillanickname, displayname, commonname, cn, surname, sn and givenname.)
Looking over the list, I really didn't see anything that looked like it might be used for th e Home Address fields. crap. And except for a couple of attributes, I don't see any of the ones defined in mozillaOrgPerson. double crap. But hmmm. These looked pretty familiar. Where did I see them. Oh, wait, they referenced in that LDAP in Mozilla Thunderbird I had already dismissed. Son of a. It really is the current information on the LDAP integration.
So for now I guess I am SOL. The most I will be able to squeeze out of the Thunderbird Address Book is the name and email, which is OK for many uses. However I will have to use yet another client to see the full records and do general management, which I was hoping to avoid. Fortunately I have found JXplorer. A Java based, Open Source LDAP Browser, which should do the trick for now.
I'm not sure what to take away from this experience. Perhaps one is to scrutinize documents more closely - rereading the LDAP bugs for thunderbird I do see now that none of the work has made it to a general release yet.
|
It looks like the list at LDAP in Mozilla Thunderbird is revised with the current Thunderbird test version 1.6a1. The list of attribute is now complete and covers all fields.
Here's the list of attributes Thunderbird is looking for:
company o title modifytimestamp mozillaHomeState mozillaCustom4 custom4 mozillaHomeUrl homeurl mozillaCustom2 custom2 mozillaHomeCountryName description notes department departmentnumber ou orgunit mobile cellphone carphone mozillaCustom1 custom1 mozillaNickname xmozillanickname mozillaWorkUrl workurl fax facsimiletelephonenumber st region telephoneNumber mozillaHomeStreet mozillaSecondEmail xmozillasecondemail nsAIMid nscpaimscreenname street streetaddress postOfficeBox l locality homePhone displayName cn commonname givenName mozillaHomePostalCode mozillaHomeLocalityName mozillaCustom3 custom3 mozillaWorkStreet2 mozillaUseHtmlMail xmozillausehtmlmail mozillaHomeStreet2 postalCode zip c countryname pager pagerphone mail sn surname birthyear
It looks mutch better now. ;-)
Ciao,
Alec
Posted by Alec on September 13, 2005 at 11:14 AM PDT #
Posted by Don on October 17, 2005 at 08:56 PM PDT #
Posted by Luke on October 28, 2005 at 05:33 PM PDT #
Posted by Paul on November 23, 2005 at 08:12 AM PST #
Posted by Matthew Buckett on April 03, 2006 at 06:17 AM PDT #
Posted by Anthony E. Greene on August 14, 2006 at 01:38 AM PDT #
Posted by Anil Ramsinngh on September 21, 2006 at 12:56 PM PDT #