Have you ever had a business associate call to say that they never received the message you promised? If so, you probably searched through your archives to verify that you actually sent the message and did not receive a return error message. Once you verified that you did everything right, did you begin to wonder where the message was, and whether it would ever make it through the myriad of connections necessary to move the message from your computer to your associate’s?
Using another means of communication, like a telephone call or a fax, to verify receipt of electronic messages wastes time and energy. You can encrypt your message for security, and affix a digital signature for identity-assurance, but you can’t really ensure that it gets from your computer to the intended recipient’s. There simply is no electronic mechanism available today that will accurately verify receipt. In some cases, a delivery status notification will tell you that your message arrived at its destination, but if you don’t receive the notification, the status of the message remains ambiguous. If you knew the path that the message took, message administrators could verify its appearance on each of the messaging systems used along the path. Even with the path information, however, tracking a message isn’t easy. As a result, today’s businesses are demanding an easy-to-use tracking system that retains both security and privacy.
E-mail and other forms of electronic communication have become the backbone of today’s business-to-business com-munications. A message transmission error has the potential to cause disaster—a missed deadline, a miscommunication, lost business, or worse. In Messaging in the Millennium: Support for Secure Electronic Com-merce (published in the March/April 1999 issue of this magazine), Hammond and Fisher noted that, to prevent these disas-ters, businesses are demanding secure and reliable transfer of information from sender to recipient, with the capability to verify that the transfer actually occurred.
To address these business needs, the Internet Engineering Task Force (IETF) has been working on a document to define message tracking 1 . Their definition of message tracking goes beyond tracing and proof of delivery. To increase security, the definition requires an audit trail of origination, including monitoring the performance of each transit messaging system, as well as the quality of end-to-end service, including delivery time, message loop detection, and performance characteristics. The definition also requires a link between the distributed messaging systems and the dissimilar messaging communities.

A Historical Perspective
Message tracking wasn’t always this difficult. A little more than a decade ago, most messaging systems were single servers running a single, proprietary messaging application. Off-net messaging was rare and controllable, with defined protocols used to ensure acknowledgement of deliveries between messaging systems through a defined business and operating agreement. While not easy, it was possible for the systems administrator to prove delivery by reviewing message logs. As networks grew, messaging systems multiplied. Businesses no longer needed a commercial mail system, because they could run their own messaging systems. With the number of messaging systems increasing, however, a single message no longer carried the tracks of its entire jour-ney. The path a message took became difficult to find, and nearly impossible to trace.

Current Work on Message Tracking
Message tracking is the means for deter-mining the path that a message object has taken, the current location of the message within its “life” path, and any characteristics that have been assigned to the message over the course of its path. The major hurdle in the development of an efficient tracking mechanism is the distributed nature of both the servers and the client. The server-side of the tracking mechanism must retain sufficient information to obtain and report on the status of the message. The client-side of the tracking mechanism must enable the user to efficiently access the information.
The IETF Message Tracking Working Group (WG) is proposing to use a number of standards (some existing and some to be written) to define how to best accomplish message tracking. The WG will attempt to define a message-tracking model, as well as a protocol design, to address this problem. Additional working drafts that wrestle with many of the server and client issues are forthcoming from this and other groups.
Message tracking is a particularly interesting problem for those involved with directories. Directories in general, and metadirectories in particular, have features that can solve many of the problems associated with message tracking. In fact, metadirectories may be the ideal e-com-merce agent to query the stored message information. Message Tracking By Steve Primost, Fischer International Systems Corporation E-mail and other forms of electronic communication have become the backbone of today’s business-to-business communications. A message transmission error has the potential to cause disaster—a missed deadline, a miscommunication, lost business, or worse. 24 Messaging Magazine November/December

A Quick Review of “Metadirectory”2
A metadirectory extends the directory model of LDAP and X.500 to the “real world” of globally distributed information, not only among organizations but also among disparate database structures. It serves as a central clearinghouse for access to corporate information, while providing security, integrity, authentication, and authorization.
According to the Gartner Group, the directory model can be extended to the “meta” model using the replication-based, information broker, or virtual directory methods. While each of these methods may be relevant to message tracking, the model proposed in this article specifically requires pointers to information in other repositories, as in the information broker method, in order to make the most efficient use of the directory.

Using Metadirectories for Message Tracking
To explore the use of metadirectories for message tracking, we must first model how the various message tracking functions are distributed between the server-side and the client-side. Figure 1 graphically depicts how messages and message tracking data would move between two computers in this model.

Requirements for Server-Side Handling of Message-Tracking Information
As illustrated in Figure 1, there are four general requirements for the server-side of the model:

• As the collection point for all of the information within its domain, the message transfer agents (MTAs) must have the capability to store a substantial amount of information (specifically, transactional states). The database requirements are heavily “write-oriented,” with substantial scalability issues. A distributed model best fits this requirement.
  
• While most messaging traffic is point-to-point, the traffic of interest in this discussion has a multiple-hop profile (i.e., interceding-relay MTAs). The delivery status information must therefore contain link information, including both forward and backward MTA addresses.
  
• The nature of the data (which by definition assumes e-commerce importance) requires guarantees regarding the security of the message, as well as the MTAs. The server-side of the model must also provide confirmation regarding the existence of the message, and even the existence of the MTA. As a result, the server-side of the message tracking model must either perform authentication before yielding information, or must allow trusted agents to access the information.
  
• It is difficult to impose further “quality of service” requirements within a distributed messaging system for reporting status information. Each MTA supplies information for which the service provider can, theoretically, charge a premium. It is easiest, however, for the client’s service provider to charge this fee directly to the client, even though the majority of the work was done by servers outside its influence. How much information is provided for what fee becomes a business decision for each service provider.

Requirements for Client-Side Handling of Message-Tracking Information In general, we would all prefer not to have another piece of client software on the desktop. If we have no choice, however, the soft-ware must be simple to use and support, yet sufficiently distinct to be saleable as a “premium service.” As illustrated in Figure 1, the client-side of the message-tracking model has the following requirements:

• The client-side of the message tracking model assumes that most user-friendly software has an add-on for message tracking, similar to the add-on that Microsoft’s Outlook 98 client uses for LDAP directory access.
• It seems logical to reuse an existing protocol, or to agree to extensions of an existing protocol that is downward compatible. At the very least, the new protocol should be compatible with anything currently available in the field.
• The protocol selected for the client software used to access the information must be independent of the protocol selected for use by the servers in building the information.
  
• To keep millions of copies of client software from becoming obsolete, it seems logical to rely on some form of middleware to bridge existing software to the message tracking software. In that capacity, the middleware would serve as the “arbitrator” of what is expected of the client software and what is required to access the desired information.
  
• To ensure the security of information critical part of message tracking as previously discussed), the client-side of the model should allow for authentication, authoriza-tion, and delegation (trust). Ideally, this task should use existing operational models.

An Example of How A Metadirectory Can Be Of Use
To provide the necessary functions for message tracking, metadirectories must have both a transaction service and an inquiry service in place. The transaction acquisition service accumulates the necessary message-tracking status information as transactions occur. The inquiry service provides the status-response capability for message tracking status information.

Transaction Acquisition Service
The metadirectory model assumes that each messaging domain maintains its own data repository. Although we can use any access protocol, this model also assumes that an agent using SMTP with extensions handles the transactions between the MTA and its data repository. Figure 2 illustrates the components used in this model.
The client and associated messaging software (shown as a laptop computer in Figure 2), the originator of the message, submits a message object to its registered MTA using SMTP protocol with extensions. A unique message identifier (UMI), the address of the MTA, and security information is returned to the client upon successful acceptance by the MTA. One basic assumption of the model is that the address of the associated MTA contains the address/port of the agent software that provides access to the message-tracking information repository (MTIR). The client software can then enter the information into the directory using LDAP according to the security rules established by its rela-tionship with the directory.
The MTA (or its related MTAs within the client’s messaging domain) continues to write transaction-related information to the MTIR as it passes through its domain. One of the most important attributes of the transaction-related information is the address of the “next MTA” or transit point (assuming that the system allows message relay). An MTIR transaction record is written at each MTA, and the security informa-tion is attached to each transaction-log entry (most likely as an SMTP extension). As part of each transaction record, the MTA adds the backward (previous hop) and forward (next hop) MTAs to the message- tracking information. At the final destination, the MTA also writes transaction-related information, as well as final-disposition information once the message object is ultimately delivered (i.e., the recipient retrieves the message).

Inquiry Service
The client and associated messaging software (shown as a laptop in Figure 3) are allowed to track the progress or final disposition of a message (administered by the service provider and class-of-service para-meter). By visiting the directory, the client can choose a UMI. Most likely, the UMI will consist of some human-intelligent identification such as the subject line and intended recipient of the message.
Selecting the message causes the system to query the directory (using an LDAP search) for attributes associated with the entry represented by the UMI. The directory then retrieves this information on behalf of the user through its facilities as an information broker.

• The initial retrieval step yields a pointer to the first MTIR. The directory initiates a query to the MTA on behalf of the client, using the security information provided in the entry. The query returns the transaction-status information at the initial state, as well as a pointer to the next MTA and the associated MTIR.
  
• Retrieval steps at each of the subsequent MTAs yield a pointer to the subsequent MTIR as well as transaction-status information. Each retrieval is accompanied by the related security information, which is provided by the directory and verified by the MTA.
  
• The intended recipient’s MTA and the final disposition information are found at the end of the chain, and receipt of the disposition information ends the string of queries.
  It is up to the client software to either display the progress of the queries as each messaging domain reports the status, or save the information for display once the process is complete. The directory server should accept and allow either behavior. The major error condition in this model would arise if the message transited a mes-saging domain that could not handle message tracking. The status-reply message would then have to report the conditions of this failure, along with the conditions of any other instance in which the directory failed to contact an information repository. This would constitute “normal” error behavior by the information broker.

Conclusions
This article outlines in broad strokes how the metadirectory could provide a possible solution to the client-side of message tracking (i.e., inquiry of the message status). The directory can easily provide the structure and the common protocol to the client. The “meta” methodology provides a means to manage both the process automation and the politics of information ownership in a distributed environment.
The example presented shows only the use of SMTP with extensions as the protocol to access the data repository. In the real world, the distributed knowledge base across multiple enterprise platforms will be more complex, and will need to handle other technologies as required by the diverse configuration of other information repositories.
One of the most important demands of message tracking is the requirement that the metadirectory must adequately protect information as it flows through the chain of information repositories. One possible means to ensure this protection is to use the security details contained within the tracking-status information. In this scenario, each message includes a password or key that could be used by a query to authenti-cate tracking. Only queries carrying the appropriate key would be supplied information by the MTAs in the transmission chain. In addition to providing this security, the metadirectory backbone can provide the authentication service required to protect the privacy of the information.