During the next year, expect to see additional support for LDAP among messaging clients and servers. Novell and Microsoft will use their messaging products to force users into their enterprise directory solutions, while messaging vendors with proprietary directories will continue to expose their directories via LDAP. Since the goal of one unified enterprise directory service will be delayed indefinitely while the Microsoft and Novell directory products continue to mature, a metadirectory service is the best solution for current directory synchronization issues.

Internet Messaging: A World Standard "What do you mean I can't send messages to the Internet?" "Why is the Internet gateway so slow?" Until recently, these were the main issues concerning Internet messaging. But the explosive growth of Internet mail now makes it critical to have a reliable Internet gateway to corporate messaging systems.

Support for a full-featured Internet mail gateway tends to push IT departments to offer ISP services to handle technical issues--addressing users' demand for expanded access to their corporate e-mailbox, security, "spam" filters, protection against mail relay attacks, and passwords protected from clear text transfer over the Internet.

But Internet messaging support raises other serious policy issues--including whether to publish directory information such as individual names, e-mail addresses and other contact information outside the firewall, and whether to grant the entire workforce access to Internet mail. These policies may require an enterprise messaging system to restrict access to Internet mail gateways.

As for user interfaces, if corporate users rely on Internet mail, addressing can be a major issue. RFC822 designates only a standard addressing scheme for routing messages to a specific mailbox on a specific mail server based on DNS addressing. It allows each individual mail server to specify the format of the mailbox, thus leaving anything to the left of the "@" sign specific to each mail server. While this is appropriate behavior for a mail routing standard, it necessitates another service to help locate specific user mailboxes by name.

Every enterprise messaging system worth its salt offers users some type of global address book, but the only directory service supported on the Internet is DNS, which enables only direct queries for domain names and MX records used in mail routing. Vendors tout the virtues of LDAP as an Internet directory access standard, but it lacks a locator service. For instance, a user can specifically configure his or her local mail client to search a corporate directory via LDAP, but this has to be specifically configured for each directory server. There's no way to locate the e-mail address of a user "somewhere on the Internet."

Global LDAP-accessible directory services, like BigFoot and Four11, attempt to address this. But these systems suffer from four critical disadvantages: They organize names within a flat name space, so they cannot be browsed by category, such as company name, location or other identifiers; they rely on users' individual names, which aren't sufficiently unique once you get past several hundred users; they are primarily geared toward personal use; and they are managed by a single company, making them largely useless when trying to locate a person within another company.

To be effective, enterprise messaging systems must help users search or browse to locate specific users or roles and job functions within an outside organization, such as a supplier or partner company. By leveraging the directory service to publish specific types of information both within and outside the firewall, messaging systems can more effectively help users route messages.

But these directory functions are moot without an effective directory location service. As it stands, there is no way to leverage existing systems such as DNS to locate an appropriate LDAP service within an organization. Add to this the fact that LDAP relies on a naming notation derived from X.500 (for example, cn=Dan Backman, ou=Editorial, o=Network Computing Magazine, c=US), as opposed to the well-accepted DNS naming conventions. While this issue is far from resolved, the architecture of Microsoft's forthcoming Active Directory Service (which leverages DNS for locator services and LDAP for directory access) provides an interesting glimpse at a solution. Using "DC=" notation within LDAP (which maps DNS domain name hierarchies into X.500 name hierarchies) and directory server resource records within DNS, ADS can theoretically handle automatic directory location across the Internet. But like any Internet protocol, it must be widely supported to offer any value.