MSGMIB Working Group (proposed) G. Jones INTERNET-DRAFT MITRE Corporation [gbjones@mitre.org] Bruce Ernst Lotus Development Corporation [bernst@softsw.ssw.com] Greg Vaudreuil Octel Network Service [greg.vaudreuil@octel.com] March 1998 Message Tracking Model Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract This document defines an SNMP-based message tracking model for electronic messaging management usage. Message tracking is the ability to find out, after the fact, the path that a particular message took through the messaging system, the current status of that message, and its characteristics. This document defines the model, architecture, and requirements for message tracking. An SNMP MIB to support message tracking is found in a related document. Expires: September 1, 1998 [Page 1] Internet Draft March 1998 1. The SNMP Network Management Framework. The major components of the SNMP Network Management framework are described in the documents listed below. o RFC 1902 [1] defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management. o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed objects (MO) for the Internet suite of protocols. o RFC 1905 [3] defines the protocol used for network access to managed objects. o [ADD SNMPv3 HERE] The framework is adaptable/extensible by defining new MIBs to suit the requirements of specific applications/protocols/situations. Managed objects are accessed via a virtual information store, the MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, which is an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, often a textual string, termed the descriptor, is used to refer to the object type. 2. Message Tracking and the Need for Message Tracking Message tracking refers, in its simplest form, to determining the path a message has taken, its current location, and its characteristics. This capability is analogous to the service provided by carriers of conventional paper mail - the ability to quickly locate where a package is, and to determine whether or not the package has been delivered to its destination. This document discusses a specific SNMP-based per-message mechanism to query the messaging system to perform message tracking. SNMP is an established network and application management technology that provides an abundance of user tools and a cross- vendor, cross-technology ubiquity. As SNMP continues to evolve (e.g. SNMPv3), the mechanisms in this document will leverage those new technologies. Use of the approach in this document will allow development of message tracking applications that can operate in a multi-vendor messaging environment: Expires: September 1, 1998 [Page 2] Internet Draft March 1998 o When there is a lack of trust in the messaging system, such as when an originator claims a message failed to be delivered, the point of failure may be isolated. This includes messages that were never delivered of messages that were delivered incorrectly. Message tracking thus adds to the overall reliability of the mail system; o Per-message information can be used for accounting, billing, and performance purposes. Traffic can be itemized on a per-origin or per-destination basis by system or originator. This typically involves two steps - collection of message traffic data, followed by the generation of appropriate reports and/or billing. o Message tracking information adds security in that the origins of potential security threats can be more precisely determined. If a system were flooded with traffic, for instance, the origin of this traffic would become known. Message tracking information is suitable for routine securty audits containing the details of messaging traffic over specific time intervals; o The message tracking MIB would aid in message loop detection, since unique message identifiers of looping messages, when these exist, would be recorded multiple times; o Performance characteristics about the type of messaging traffic could be determined, such as when an inbound message causes the creation of multiple outbound messages, and the percentage of messages that were actually delivery reports or receipts. This is valuable for performance measurement, among other reasons; o Standardized message tracking information acts as a bridge between dissimilar messaging systems and dissimilar messaging communities; 3. Requirements The following requirements and definitions are agreed upon by the group: o A query is a question that a user asks to get message tracking information. One or more SNMP operations may be necessary to complete a query. o A user is either an individual mail user or a mail system administrator. o A message tracking domain consists of all MTAs under the control of an administrator. Expires: September 1, 1998 [Page 3] Internet Draft March 1998 o The user should be able to query based upon - unique message identifier - recipient - originator - time range (start time-to-end time) o The user should be able to use wild-carded values. o The user should be able to narrow the scope of the query using multiple criteria and combinations of criteria from items (3) and (4). o End users should only be able to get responses to queries about mail they have sent or received. o Privileged persons (system administrators) should be able to get responses to queries about mail sent by or received by people for whom they are designated or trusted administrators. (Remember one may be a self-appointed yet legitimate system administer for a domain of only 2 mailboxes....) o "Queries" that span domain boundaries have to be restricted to traffic that left one domain for another o The system must scale to the size of the email Internet o The system must respond within a reasonable period to any request. We would propose 10 seconds for a 3 hop path as reasonable. o Queries should place no unreasonable burden upon the managed systems. We propose an assumption of 1 query per 5,000 messages for purpose of evaluating this requirement. [THE FOLLOWING MATERIAL WAS PREVIOUSLY POSTED AND MUST AGREE WITH THE ABOVE LIST] The Messaging Manager must be able to trace a message on behalf of a user, to discover whether the message was in fact delivered, or to determine where the message may be stuck in the system. Message Tracking is often required more by end users during times when they distrust the System - when moving from a real-time delivery system to a store-and-forward system, or when the System is new, or is undergoing significant change. The management information described in this document provides for tracking on a per-message, per-recipient basis. A message's current status, as well as the complete path taken by a message, on a per-recipient basis, can be obtained by consulting Messaging Management agents which comply with this specification. Expires: February 1, 1998 [Page 4] Internet Draft March 1998 As the Messaging System shifts to being used for applications which require higher reliability (e.g., EDI), Message Tracking will be required to assure the users that the requisite reliability is indeed in place. If a question of "lost mail" arises, the mail manager must be able to track the message from its entry into the mail system until it is delivered, non-delivered, or passes outside the management sphere into another management sphere. The track must be able to cross multiple messaging components from multiple vendors. There must be provision for passing the query to the appropriate authority in the next management sphere so that the track can be continued there. Cross-jurisdictional, agent-based message tracking, as described in this document, addresses this equirement. In addition to being multi-component and multi-vendor, this specification also addresses multiple management technologies. Messages must be trackable from point of origin, based on the sender providing the posting date and time and destination. This includes one Mail Manager asking the Mail Manager of the next management sphere to continue the track of a message entering that sphere at a specific date and time from a stated point of origin. Message tracking queries, filtered based on time and recipient (i.e., in the case when a specific message ID is not known) is included in this specification. Note however that support for this sort of filtering is optional. Messages must also be trackable across domains - from one enterprise, across the public wide-area network, and into the destination enterprise. 4. Architecture Let [us] define three actors for the message trace model. The first is the MTA that may have knowledge of a message and is the target of the query. The second is the email system used to send messages. This sending email system is broadly defined such that sending system is able to provide to the originator or recipient key information necessary to initiate a trace. This information may include anything available in a message header including date, recipient, and message-ID plus important attributes such as the first-hop MTA the message was sent to. This is more broadly defined than a typical email user agent in that the senders email gateway may be considered part of the sending system. (For this model, the sendmail that adds the date and message-ID is part of the sending "system". The proprietary-to-Internet gateway that creates internet-legal email addresses and message-id's is also part of the sending system). Expires: September 1, 1998 [Page 5] Internet Draft March 1998 The third is a message tracking client. This may be integrated into the email client, stand-alone, hosted on a web server, or otherwise able to generate an SNMP query in response to input from an end user or administrator. The following "use case" illustrate the relationships between the actors. a. End users creates a email messages from the sending system through one or more MTA's. b. The originator desires a trace and forms a query from the message tracking client using available from the message sending system. c. The message trace clients issues the query to the first MTA in the path. If successful, the MTA returns information regarding the message including the canonical name of the next MTA in the path. The message trace issues a subsequent query against the next MTA in the path until either the query fails of the MTA indicates the delivery was successful. [NOTE: You need to expand item 3 to add the following: a utility might also want to visit a list of MTAs simulataneously, in parallel, and later correlate the information about path in a central place. You also might not know the starting point, so you have to kick off a parallel trace to a (hopefully limited) number of candidate MTAs in order to find out the starting point. Thirdly, it might make sense to set up a periodic "pull" of information from a list of MTAs at predefined intervals.] The Outbox Model. In the message trace model, the sending system is considered to be atomic. In the current universe, there are various boundaries between the user agent and the balance of the sending system. In some cases the sending system is an all-in-one mail system. In others the traditional Unix email client/Sendmail split is present. In many corporate and proprietary email systems, the client, intermediate post offices, and the Internet gateway together are a sending system. Further, these systems have varying trust relationships between the various part of the system. It may be useful to define a separate model for those implementations where the user interface portion of the sending system does not have sufficient information to create a message trace query and must rely upon a repository of general information stored elsewhere in the sending system. Expires: September 1, 1998 [Page 6] Internet Draft March 1998 If one defines there to be an outbox agent as part of the balance of the message sending system, one may consider there to be a query protocol between the message trace client and the outbox agent. This protocol must provide an authenticated link between the user and the information necessary to create a message trace query. Okay then, have we answered all of the following questions (probably not yet): a. What components are in the messaging system ? The management system ? Define each one (MTA, UA, agent, manager). Is a "message store" the same as an MTA for our purposes ? Is a "gateway" the same as an MTA ? What components are out of scope ? b. What does it mean to "track" a message ? What is the path of the message through the components; e.g., what are we tracking and what are we not tracking ? (the charter says we only track a message from the time an MTA accepts it to the time it is handed off to something other than an MTA. This should be restated here) c. What is routing ? What is a "previous hop" MTA and what is a "next hop" MTA ? d. What is a MIB and what is SNMP ? e. Which versions of SNMP are we using (assume both v1 and v3) and what are their differences ? f. Are we addressing control functions; that is, the ability to control individual messages (beware, if this genie gets out of the bottle I'm going to ask whoever proposes it to write a separate document) 5. Security Topics 5.1 Tracking under SNMPv1 a. What technical information is available in SNMPv1 to support security ? We may have to mention the definition of community string, access controls, additional MIB variables to support security since MIB variables in v1 might have to serve as replacement for functions in v3 b. What types of users will be allowed to track messages ? Perhaps there should be two levels of access: an "ordinary" user and an "adminstrative" user. For example, the ordinary user will have to have an exact-match message ID; the administrative user will be allowed to get messages using the delivery time and other people's e-mail addresses c. An SNMPv1 community string serves as a password. If an e-mail user asks his/her provider to track a message given a (sufficiently long) message ID and a community string, isn't this the same as or better than a customer calling his/her bank with a social security ID and a mother's maiden name on an unsecured phone line ? Note: such a scheme is still vulnerable to replay attack. What about router management today. The control of IP routers is performed using community strings in the clear, so why not message tracking ? Expires: September 1, 1998 [Page 7] Internet Draft March 1998 d. Can we restrict requests to certain recipient names or ranges of message IDs ? For example, bar the ability to track messages going to/from the president of the company ? Could high-importance messages be assigned IDs in a particular range to soignify their importance (note this is probably too complicated to implement) ? 5.2 Tracking under SNMPv3 At the moment, the SNMPv3 security model that exists (user-based) assumes that there are a countable number of interested parties, and an agent will have a trust relationship with each one. Access by "a fairly sophisticated application" may mean 2 different things, like this: o User -----|-----> Application -----> SNMP agent trust boundary non-SNMP proto SNMP o User ---------> Application -----|----> SNMP agent anything trust boundary SNMP In the first case, the application is trusted by the SNMP agent, and has the job of verifying what the user is allowed to see. In this case, we should be designing the non-SNMP protocol, not the MIB, since that's the interface that has to be open. In the second case, the application has exactly the same trust as the user, and adding it into the chain contributes *nothing* to the trust model; the application is, conceptually, just part of the user's User Interface. The idea of "locally applied policy" is reasonable, but the protocol MUST supply enough handles for at least ONE reasonable security policy to work (apart from "everyone can see everything). That said, we must look at the following: a. What technical information is available in SNMPv3 to support security ? SNMPv3 has authentication features (USM) and access controls (VACM). Additional MIBs were defined to support security, we think b. We still want to have levels of users. Here is an example: when there is no authentication, use the scheme defined above for SNMPv1. When an "ordinary" user authenticates, allow that user to track only those messages he/she is the originator or recipient of. When an "administrative" user authenticates, allow tracking using full range of criteria including time ranges and wild-cards. c. Note about the authentication feature in SNMPv3: when a user requests to authenticate, asks to track a message, claims to be the originator of the message, and supplies the e-mail address to be tracked, there has to be a way to correlate the authentication key with the e-mail address of the requestor Expires: September 1, 1998 [Page 8] Internet Draft March 1998 5.3 For both v1 and v3 a. What is the role of access control ? Can we use built-in access control mechanisms to restrict access to certain ranges of OIDs for certain lists of users ? b. What is the role of firewalls and transport layer security ? Is there something we can leverage here ? c. We can restrict the information that queries contain but we can also restrict the information returned in the response; for instance, I can limit the response to contain only the message disposition status (it got there or it didn't) if I really wanted to be fussy about it 6. Inter-domain Tracking a. There are two walls we hit here: when a request to track a message reaches a "domain boundary" it gets complicated EITHER because the IP address of the next hop MTA is not known (needs to be looked up) OR access to the agent at the next hop is denied. In the first case, should mention that there must be a way to look these things up (DNS, SQL database, table lookup) ? For the second case, read on... b. Should out-of-domain access be treated as a MAY ? c. Do we need to define a class of user like an "out of domain" user, who can only track messages entering or leaving their domain ? Could we use the domain names in the e-mail addresses they are tracking to support this ? Can we limit the amount of information in the query response so we don't give away important operational information ? d. When a tracking request reaches a domain "boundary", do we want to issue a referral such as the e-mail address of an administrator, a phone number, a person's name, or an IP address ? e. Should we specify that each domain supply a special "boundary agent", which, when it receives a request, queries other agents in the domain and correlates the responses ? f. In all cases, should we declare that the responsiblity for delivering a message stops at the domain boundary ? Expires: September 1, 1998 [Page 9] Internet Draft March 1998 7. Authors Addresses Gordon Jones MITRE Corporation 1820 Dolley Madison Blvd. McLean, VA 22102-3481 Phone: +1 703 883 7670 E-Mail: gbjones@mitre.org Bruce Ernst Lotus Development Corporation Phone: +1 610 251 3404 E-Mail: bernst@softsw.ssw.com Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 Phone/Fax: +1-214-733-2722 E-Mail: Greg.Vaudreuil@Octel.Com