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
<draft-jones-msgmib-model-00.txt>
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