Wrestling Tiger Mail.app and LDAP into submission

Mail.app in Tiger is a very nice mail application. Unfortunately, in our environment, when we upgraded to Tiger, address completion started to behave very badly. You’d start a new message, start typing an address, and suddenly the spinning rainbow of death would appear, making Mail.app completely unresponsive for up to several minutes.

Automatically complete addresses
If you turned off “Automatically complete addresses” in Mail->Preferences->Composing, the issue would go away. But then you couldn’t easily send mail to anyone not in your local address book (or in your brain), so that was a poor solution. I wrestled with the issue for a few days, trying different LDAP configurations, but wasn’t able to make any progress.

Entourage is our “supported” email client here because some of our people are on Exchange, so I eventually gave up and moved back to Entourage. But while working on Portable Home Directories, I was motivated once again to look at Mail.app, because the way it handles mail works better with Portable Home Directories.

Entourage stores everything – all mail, contacts, and calendar items in a single database file. So when your home syncs, this giant file must be copied to and from your network home every time. Worse, the mail that is on IMAP and Exchange servers is cached in this Entourage database, and adds to the size of the database and the time it takes to sync.

Mail.app, on the other hand, stores mail data in ~/Library/Mail in subdirectories. When you sync, only the changed files (indexes, attachments, and messages) need to sync. Even better, since IMAP message caches are kept in ~/Library/Mail/IMAP-* (and .mac and Exchange mail are stored in their own folders), the Portable Home Directory sync process can simply skip those directories. Local mail can be synchronized, but there is no real reason to synchronize mail that is also on the mail server(s). This has two benefits: shorter sync times, and less disk space used on the network home.

So it seems like a good idea to use Mail.app with Portable Home Directories if you can; at least compared to using Entourage. But my original issue still plagued me: when addressing messages, I would offten get the spinning rainbow of death.

I finally solved the issue (I think and I hope).

Mail.app and Address Book.app are configured to look at three LDAP directories:
Mail.app LDAP
FA is the internal Feature Animation directory; Disney is the whole company, and FA Pager is just pager addresses for FA people. I tried various combinations, but no combination made the spinning rainbow of death go away. So I started looking at the system log at /var/log/system.log, and noticed messages like this:


Apr 2 20:36:18 istanbul DirectoryService[45]: Search connection failure: During an attempt to bind to [xxx.xx.xx.xxx] LDAP server.
Apr 2 20:36:18 istanbul DirectoryService[45]: Search connection failure: Disabled future attempts to bind to [xxx.xx.xx.xxx] LDAP server for next 120 seconds.
Apr 2 20:37:05 istanbul DirectoryService[45]: Search connection failure: During an attempt to bind to [xxx.xx.xx.xxx] LDAP server.
Apr 2 20:37:05 istanbul DirectoryService[45]: Search connection failure: Disabled future attempts to bind to [xxx.xx.xx.xxx] LDAP server for next 120 seconds.

(where ‘[xxx.xx.xx.xxx]’ was the IP address of one of our LDAP servers)
These seemed to correspond to the spinning rainbows of death. There were matching lines in /Library/Logs/Console//console.log. Acting on a hunch, or maybe a dimly percieved racial memory, or perhaps a fuzzy memory of a maillist posting somewhere, I opened the Directory Access application, selected the contacts tab, and removed the LDAPv3 server from the Contacts search path:

Directory Access
I clicked “Apply”, and then quit Directory Access. Then I started addressing messages in Mail.app.

No spinning rainbows of death. No “Search connection failure” messages in the logs. It seems the problem is solved. There is no reduced functionality that I can see in Mail.app or Address Book.

Yay! Now I can use Mail.app in Tiger day-to-day in my organization and use Portable Home Directories more efficiently.

Wrestling Tiger Mail.app and LDAP into submission

8 thoughts on “Wrestling Tiger Mail.app and LDAP into submission

  1. I posted about this the other day on MacEnterprise I think it was.

    It seems like the ‘Contacts’ node searching is kind of dumb, and doesn’t just look at the user branch. I haven’t put DS into API debugging mode to find out, but it’s also possible that it’s being badly behaved and grabbing all node info, rather than just the bits that are relevant to an address book entry…

    I experimented with setting up a dedicated Contacts node that only had the cn=users branch (I’m using OD) and it was better, but still not as good as simply specifying Mail.app and AddressBook to look at a branch manually.

  2. JM says:

    Greg, I’ve been meaning to ask about a similar thing I’ve been experiencing: a two-minute hang when logging in or out, or when diong anything that would create a file while logged into my AD mobile home directory when there is an internet connection present, but I am not connected via VPN to campus (I’m at a university). Shutting off the internet connection first makes everything as zippy as it should be. None of that seems to involve LDAP as far as I know, but while we’re on the topic of system hangs — do you have any ideas? As it is, this pretty much makes off-campus laptops useless.

    Thanks again for sharing your work!

  3. There’s been some recent discussion of this exact topic on the MacEnterprise.org mailing list – the beginning of the thread is here: http://listserv.cuny.edu/Scripts/wa.exe?A2=ind0603&L=macenterprise&T=0&P=63692

    Lance Ogletree is testing a workaround.

    I think this is a bug that surfaces when the AD controllers have DNS names that resolve from the Internet, but I haven’t been able to confirm this. Disney’s AD controllers are (mostly) on private subnets and their DNS names are not resolvable outside the Disney network.

  4. physh says:

    To have the LDAP address completion to work, use TCP/3268 instead of TCP/389. This worked great for me.

Comments are closed.