A while back I wrote an article about the lack of directory services on the Macintosh for MacWEEK, and as is often the case with paper publications, felt that I couldn't fit all the information I had into the article. So, here's another take on the subject from a rather different point of view.
It all started when I asked my editor at MacWEEK if I could write about using Internet email servers in an intranet situation. I find intranets quite amusing, since their entire point is that they use standard Internet protocols and software, and yet somehow they're big news in the trade publications. Nonetheless, email is one of my favorite topics, and since we run a large mailing list with TidBITS, we have an intimate knowledge of the limitations of most LAN email packages gatewayed onto the Internet. In many situations where an office has an Internet connection, it's easier, cheaper, and friendlier to run a real SMTP/POP server than something like QuickMail, cc:Mail, or FirstClass.
There are a number of complete SMTP/POP servers for the Mac now, ranging from the free Apple Internet Mail Server (AIMS) to Stalker Software's Swiss Army knife of email servers, CommuniGate, to Sonic Systems' SonicMail. For offices not already connected to the Internet, Claris's OfficeMail speaks SMTP and POP to email clients like Eudora and Emailer, and UUCP to get out to the Internet (see TidBITS-336). There's also a new Mac SMTP/POP mail server called RingTwice in beta testing, but it too seems to lack directory services features. Add all this to Tenon Intersystem's plans to bring out an industrial-strength mail server based on Post.Office, and you have a wide range of choices.
However, because I don't work in a large organization, there's a problem I hadn't anticipated when I wrote that article: directory services. How can you look up the email address of someone else in your large organization? I was a surprised by the number of comments about this topic, because I always considered the Internet to be my "large organization," and on the Internet there's no guaranteed way to look up email addresses. (There are attempts of varying success; the links under Finding People on the home page for Internet Starter Kit for Macintosh take you to most of them).
Let's assume that everyone in a large organization lives and dies by the address book in their LAN email program. I haven't run QuickMail since 1989, and I've never seen cc:Mail in person, but it seems unlikely all of these address books contain much more than fields for name and email address. What if an address book feature lacks a phone field, a fax field, or a snail mail address field? And who's in charge of getting and filling in all that information for local people? I'm sure organizations try to handle the issue - one person who has worked at several large publications said that they always tried to keep an organization-wide contact database in Now Contact or something similar, but these databases always fell prey to incorrect data and other problems. In other words, it's my suspicion that existing solutions in LAN email packages don't always solve the entire problem.
Existing Solutions -- That said, how can we solve this problem of a lack of directory services for current Internet email servers? There are plenty of possibilities, some of which depend on which email server you use and which email client you use. The problem breaks down into roughly three parts: dealing with the information at the server, manipulating the information in the middle, and searching it on the client.
Of the Mac Internet email servers, only CommuniGate has address book functionality built in (although it's only accessible with the CommuniGator client software), and you can export the address book of local users to a tab-delimited text file. That's not possible in SonicMail or Claris OfficeMail at all, and is only possible for AIMS with the freeware MailShare Loader, available only at the URL below.
If you create users in either AIMS or CommuniGate, exporting a list to a tab-delimited text file offers a variety of options. My inclination would be to import it into either a custom database in something like FileMaker Pro or into Now Contact. You might have to do some work to set up the import filters (or even manipulate the text file first). Once you have your users in a database, you can add fields not supported by the email server, sort the list in a variety of ways, and of course, export it to a variety of formats.
One possibility is simply to make the database accessible to everyone in the company. That might prove financially difficult if it involved a site license for a contact database, although a FileMaker Pro database could be used as a runtime. Both FileMaker Pro and Now Contact are sufficiently scriptable that someone could write a script to send email via a scriptable email client like Eudora. I'm not a fan of brittle scripting solutions, though, and I'd consider this an interim hack.
I'm more in favor of exporting the user list from the database into a couple possible formats. If you have a site license for Eudora Pro 3.0, you could export to a Eudora nicknames file, put it on a central server, and copy an alias of it into each user's Nicknames Folder in their Eudora Folder. Eudora Pro 3.0 handles these nickname file aliases perfectly, although you might want to lock the original to prevent unauthorized changes. So, if you use Eudora Pro, this suddenly gives you an organization-wide address book, complete with phone numbers and snail mail addresses. This technique doesn't work with Eudora Light, which only supports a single Eudora Nicknames file.
Alternately, how about exporting to a Web page? HTML is sufficiently simple that it isn't difficult turn an exported text file into HTML with a Nisus Writer macro or another text tool. Take the entire concept one step further with a CGI like Tango, WEBFM, ROFM, or Lasso, and you could link your database directly to your intranet or the Web.
And, lest I be accused of forgetting too many possibilities, there are a number of Web servers built on databases that might be able to do this stuff in their sleep. Possibilities include Web Server 4D, NetWings, and Webink.
Making the information available on a Web page is great, but predisposew people to using the mediocre email clients in most Web browsers. If you like Netscape Navigator's email client, fine, but you can set up Navigator so mailto links are passed off to a different program. Just copy this tiny AppleScript into Script Editor, change it so it matches the name of your copy of Netscape and the creator code of your email program (if not Eudora, as shown below), and run it. To be honest, I'm not sure which other email programs can work with Navigator in this way, although betas of Eudora Light 3.0.1 appear to do so.
tell application "Netscape Navigator 3.0" register protocol "CSOm" for protocol "mailto:" end tell
Without getting into the nuances of scripting Web browsers, this technique should work with Microsoft Internet Explorer and Spyglass Mosaic, though you may need to run the script each time you launch the browser. If you need to restore your browser's default behavior, change "CSOm" to the creator code for your browser ("MOSS", in Netscape's case) and run the script again. If you use Eudora Light 1.5.4, you can set the script to use the Eudora GURL Helper application that comes with Internet Config instead of Eudora Light itself.
Finally, although it lacks elegance and integration with email programs other than Eudora, there's always the Finger protocol. Finger has been around for a long time and can be used to make directory services information available. There are a couple of Finger servers (such as FingerToys from Acme Technologies and Peter Lewis's Daemon) and Finger clients (including Peter's Finger and a Finger HyperCard stack, not to mention Eudora Light and Pro), but I haven't heard of many people utilizing Finger to solve directory services problems, which leads me to believe it's not really a viable solution.
Future Solutions -- These hacks are fun to invent, but they aren't the best way to solve the directory services problem. For that, I believe we need support for a directory services protocol in Mac email servers or a link with a generalized directory services server.
One possibility is the Ph protocol Eudora author Steve Dorner developed. It's a simple, text-based protocol that provides a sufficient amount of information and already has some support in Eudora and in John Norstad's free Mac Ph client.
No one has yet developed a Ph server (properly called a qi server) for the Mac, which has proven an obstacle to further acceptance of Ph. Rumor has it Ph support will be forthcoming in a future version of CommuniGate and in AIMS 2.0, so perhaps Ph will enjoy a resurgence.
As attractive as Ph might be, thanks to its ease of implementation and text-based nature, a different protocol has the backing of most big companies. LDAP, or Lightweight Directory Access Protocol, started life at the University of Michigan as a subset of the X.500 directory access protocol. LDAP developer Tim Howes and two others at the University of Michigan who worked on the project now work at Netscape Communications. Needless to say, Netscape is in favor of LDAP, and numerous other large companies have signed on as well.
Mac client support for LDAP comes in the form of a program from the University of Michigan called maX.500, although Gavin Eadie is also working there on a Live Object LDAP browser for Cyberdog. These programs sort of solve the client-side issue, but for a directory services protocol to gain wide acceptance it must be integrated into all the primary email clients. LDAP is more complex than a simple text-based protocol like Ph, which makes supporting it in an email program more difficult. In classic fashion, Steve Dorner noted, "This overwhelming complexity is one of the reasons that X.400 and X.500 have lost the battle, and the Internet has won. LDAP is corporate revenge."
Corporate revenge on programmers LDAP may be, but without support from all the main Mac email clients and some Mac LDAP servers (which haven't yet reared their heads), it's hard to see how LDAP could make significant inroads into the Macintosh world. With sufficient support, it could be the solution so many people are waiting for; until then, Godot could arrive first.
Pie in the Sky Solutions -- The ideal solution to this problem is to have directory services built into the Mac OS. In fact, the much-maligned PowerTalk had some of those capabilities.
It's ironic - PowerTalk was a flop as an email handling technology because Apple ignored most of the email world while PowerTalk was in development. PowerTalk also suffered from interface and architecture oddities, but I've had a number of conversations lately that ended in "Of course, PowerTalk did that." PowerTalk had an OS-level database of sorts, supported OS-level directory services, and had keychain functionality that simplified maintaining numerous userids and passwords for servers. Those technologies - along with the PowerTalk replacement for the embarrassing Chooser - would be welcome today, if only they hadn't carried significant overhead and the baggage of a barely usable email client.
When Apple discontinued PowerTalk, I remember talk of how the technology wouldn't disappear entirely, but would be broken up and implemented differently in a future version of the Mac OS. Perhaps we can look forward to some of these technologies appearing in future releases of the Mac OS - whatever those may be.