idnits 2.17.1 draft-ietf-msgtrk-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 229 has weird spacing: '..."active enabl...' == Line 248 has weird spacing: '...ted are as f...' == Line 320 has weird spacing: '...rmation sourc...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2000) is 8566 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-822' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1894 (ref. 'RFC-DSN') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1891 (ref. 'RFC-ESMTP-DSN') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2298 (ref. 'RFC-MDN') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 1892 (ref. 'RFC-REPORT') (Obsoleted by RFC 3462) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft T. Hansen 2 draft-ietf-msgtrk-model-03.txt AT&T Laboratories 3 Valid for six months November 2, 2000 5 Message Tracking Model and Requirements 7 9 Authors' version: 1.13 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This memo and its companions are discussed on the MSGTRK working 32 group mailing list, ietf-msgtrk@imc.org. To subscribe, send a message 33 with the word "subscribe" in the body (on a line by itself) to the 34 address ietf-msgtrk-request@imc.org. An archive of the mailing list may 35 be found at http://www.ietf.org/archive/msgtrk. 37 Copyright Notice 39 Copyright (C) The Internet Society (1999). All Rights Reserved. 41 Abstract 43 Customers buying enterprise message systems often ask: Can I track 44 the messages? Message tracking is the ability to find out the path that 45 a particular message has taken through a messaging system and the 46 current routing status of that message. This document provides a model 47 of message tracking that can be used for understanding the Internet-wide 48 message infrastructure and to further enhance those capabilities to 49 include message tracking, as well as requirements for proposed message 50 tracking solutions. 52 1. Problem Statement 54 Consider sending a package through a package delivery company. 55 Once you've sent a package, you would like to be able to find out if the 56 package has been delivered or not, and if not, where that package 57 currently is and what its status is. Note that the status of a package 58 may not include whether it was delivered to its addressee, but just the 59 destination. Many package carriers provide such services today, often 60 via a web interface. 62 Message tracking extends that capability to the Internet-wide mes- 63 sage infrastructure, analogous to the service provided by package car- 64 riers: the ability to quickly locate where a message (package) is, and 65 to determine whether or not the message (package) has been delivered to 66 its final destination. An Internet-standard approach will allow the 67 development of message tracking applications that can operate in a 68 multi-vendor messaging environment, and will encourage the operation of 69 the function across administrative boundaries. 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS]. 75 2. Definitions 76 The following terms are relevant to message tracking. The terms Track- 77 ing User Agent and Tracking Server are new, while all other terms have 78 been collected here from other sources. 80 Originating Mail User Agent (MUA) 81 The originating mail user agent is the software used to 82 compose and originate a message. It is the software sit- 83 ting on a person's desktop. 85 Originating Mail Submission Agent (MSA) 86 The Mail Submission Agent accepts a message from a User 87 Agent, adds or modifies it as required for Internet stan- 88 dards and/or site policy, and injects the message into 89 the network. The MSA may be the initial MTA or may hand 90 off the message to an MTA. 92 Message Transfer Agent (MTA) 93 A Message Transfer Agent accepts a message and moves it 94 forward towards its destination. That destination may be 95 local or reached via another MTA. It may use a local 96 queue to store the message before transferring it 97 further. Any MTA may generate a Non-Delivery Notifica- 98 tion. 100 Intermediate Message Transfer Agent (MTA) 101 An Intermediate MTA is an MTA that accepts a message for 102 transfer somewhere else. 104 Final Message Transfer Agent (MTA) 105 A Final MTA is an MTA that accepts a message for local 106 delivery. It is the final place that a message is 107 accepted. The final MTA is what sends any Delivery 108 Status Notificatons (DSNs). (Intermediate MTA's may also 109 send a DSN if it relays to a non-DSN aware MTA.) 111 Foreign Message Transfer Agent 112 A foreign MTA provides delivery of messages using other 113 protocols than those specified for Internet mail, such as 114 an X.400 mail system. 116 Gateway Message Transfer Agent (GW-MTA) 117 A gateway MTA accepts a message for transfer to a foreign 118 MTA outside of the Internet protocol space. 120 Local Delivery Agent (LDA) 121 The local Delivery Agent delivers the message to the 122 local message store. (The MTA and LDA are often combined 123 into the same program.) 125 Delivery Status Notification (DSN) 126 A Delivery Status Notification [RFC-DSN] is produced by 127 an MTA when a message is unsuccessfully delivered, either 128 to its next hop or the final message store, or when it is 129 successfully delivered, either to a foreign MTA, to a 130 local delivery agent, or a non-DSN aware MTA. Positive 131 notifications are only performed [RFC-ESMTP-DSN] when 132 specifically requested. 134 Non-Delivery Notification (NDN) 135 A non-delivery notification is a special form of DSN 136 indicating unsuccessful delivery. 138 Message Disposition Notification (MDN) 139 A Message Disposition Notification is used to report the 140 disposition of a message after it has been successfully 141 delivered to a recipient. 143 Tracking User Agent (TUA) 144 A tracking user agent wants to find information on a mes- 145 sage on the behalf of a user. It is the requestor or 146 initiator of such a request. (The MUA and TUA could be 147 combined into the same program.) 149 Tracking Server 150 A tracking server provides tracking information to a 151 tracking client. It is the repository of the information 152 about a message for the traversal through a particular 153 MTA. (The tracking server and MTA may run on the same 154 system.) 156 3. Entities 158 The entities involved in message tracking are: message user 159 agents, message submission agents, message transfer agents, tracking 160 user agents and tracking servers. 162 4. Requirements 164 These are requirements that any message tracking solution must be 165 able to satisfy: 167 The message tracking solution: 169 ** MUST scale to the internet. 171 ** MUST be easy to deploy. 173 ** SHOULD maximize the reuse of existing, already deployed tech- 174 nology and infrastructure. 176 ** If possible, SHOULD extend existing protocols and not invent 177 new ones. 179 ** SHOULD have a low implementation cost. (This makes it easy to 180 incorporate into existing products.) 182 ** MUST restrict tracking of a message to the originator of the 183 message (or a delegate). 185 ** MUST be able to do authentication. 187 ** MAY allow an originator to delegate this responsibility to a 188 third party. 190 ** SHOULD have the property that they would allow per-message 191 delegation of the tracking responsibility. 193 ** MUST require a tracking user agent to prove that they are per- 194 mitted to request the tracking information. 196 ** MUST be able to uniquely identify messages. 198 ** MUST require every message to have unique identification. 200 5. Interaction Models 202 There are several models by which tracking of messages can be 203 enabled, by which messages can be tracked, and by which information can 204 be requested and gathered. 206 5.1. Tracking Enabling Models 208 Either the envelope or message header must contain enough informa- 209 tion to track a message and securely retrieve information about the mes- 210 sage. Any message that does not have enough information to track it is 211 by definition not trackable. 213 If there is not enough information available in current standard 214 envelopes or message headers, then the current standards will need to be 215 extended. Either the MUA or MSA must determine the additional informa- 216 tion and enable the tracking by adding the additional information to 217 either the envelope or header. 219 This leads to two tracking enabling models: passive enabling and 220 active enabling. 222 5.1.1. Passive Enabling Model 223 The "passive enabling" model assumes that there is sufficient informa- 224 tion available. No UA or MSA interaction occurs to turn tracking on; it 225 is on by default. 227 5.1.2. Active Enabling Model 229 The "active enabling" model requires that the MUA and MSA exchange 230 information when the message is submitted. This exchange indicates that 231 logging of the message's traversal should be performed, as well as pro- 232 viding enough additional information to allow the message to be tracked. 233 This information will need to be passed on to subsequent MTAs as needed. 235 5.2. Tracking Request Models 236 There are several models by which tracking information may be requested. 238 5.2.1. Passive Request Model 240 The "passive request" model requires active enabling to indicate 241 that some form of tracking is to be performed. The tracking information 242 can be sent back immediately (as a form of telemetry) or sent to a 3rd 243 party for later retrieval. 245 5.2.2. Passive Request Tracking Information 247 Forms of passive tracking information that could potentially be 248 requested are as follows. Note that mechanisms already exist for 249 requesting the information marked with a (+). The references for such 250 mechanisms are listed at the end of each such entry. 252 ** send a DSN of a message arriving at an intermediate MTA 254 ** (+) send a DSN of a message being rejected while at an inter- 255 mediate MTA [RFC-DSN] 257 ** (+) send a DSN of a message leaving an intermediate MTA and 258 going to another MTA [RFC-DELIVER-BY] 260 ** send a DSN of a message arriving at a final MTA 262 ** (+) send a DSN of a message being rejected while at a final 263 MTA [RFC-DSN] 265 ** (+) send a DSN of a message being delivered to a user's mes- 266 sage store [RFC-DSN] 268 ** (+) send a DSN of a message being delivered to a foreign MTA 269 [RFC-DSN] 271 ** (+) send an MDN of a message being read by an end user [RFC- 272 MDN] 274 5.3. Active Request Model 276 The "active request" model requires an active query by a user's 277 user agent to the MSA, intermediate MTAs and final MTA, or to a third 278 party, to find the message's status as known by that MTA. Active 279 request will work with either passive enabling or active enabling. 281 5.3.1. Server Chaining vs. Server Referrals 282 When a tracking server has been asked for tracking information, and the 283 message has been passed on to another MTA of which this tracking server 284 has no tracking knowledge, there are two modelling choices: 286 ** the first tracking server will contact the next tracking 287 server to query for status and pass back the combined status 288 (server chaining), or 290 ** the first tracking server will return the address of the next 291 MTA and the tracking client has the responsibility of contact- 292 ing the next tracking server (server referrals). 294 5.3.2. Active Request Tracking Information 295 Forms of active tracking information that could potentially be requested 296 are as follows. (Note that no mechanisms currently exist for requesting 297 such information.) 299 ** the message has been queued for later delivery 301 ** the message was delivered locally 303 ** the message was delivered to another MTA, 305 ** the message was delivered to a foreign MTA 307 ** ask a different tracking server, 309 ** I know but can't tell you, 311 ** I don't know. 313 5.4. Combining DSN and MDN Information with Message Tracking Informa- 314 tion 316 The information that would be retrieved by message tracking and the 317 information that is returned for DSN and MDN requests all attempt to 318 answer the question of "what happened to message XX"? The information 319 provided by each is complementary in nature, but similar. A tracking 320 user agent could use all three possible information sources to present 321 a total view of the status of a message. 323 Both DSN and MDN notifications utilize the formats defined by RFC 324 1892 [RFC-REPORT]. This suggests that the information returned by mes- 325 sage tracking solutions should also be similar. 327 6. Security 329 This is a security model for message identification and authentica- 330 tion that could be deployed. (There may be others.) 332 A Tracking User Agent must prove that they are permitted to request 333 tracking information about a message. Every [RFC-822]-compliant message 334 is supposed to contain a Message-Id header. One possible mechanism is 335 for the originator to calculate a one-way hash A from the message ID + 336 time stamp + a per-user secret. The user then calculates another one- 337 way hash B to be the hash of A. The user includes B in the submitted 338 message, and retains A. Later, when the user makes a message tracking 339 request to the messaging system or tracking entity, it submits A in the 340 tracking request. The entity receiving the tracking request then uses A 341 to calculate B, since it was already provided B, verifying that the 342 requestor is authentic. In summary, 344 A = H(message ID + time stamp + secret) 346 B = H(A) 348 Another possible mechanism for A is to ignore the message ID and time 349 stamp and just use a one-way hash from a large (>128 bits) random 350 number. B would be calculated as before. In summary, 352 A = H(large-random-number) 354 B = H(A) 356 This is similar in technique to the methods used for One-Time Passwords 357 [RFC-OTP]. The success of these techniques is dependent on the random- 358 ness of the per-user secret or the large random number, which can be 359 incredibly difficult in some environments. 361 If the originator of a message were to delegate his or her tracking 362 request to a third party by sending it A, this would be vulnerable to 363 snooping over unencrypted sessions. The user can decide on a message- 364 by-message basis if this risk is acceptable. 366 7. References 368 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 369 Text Messages", STD 11, RFC 822, UDEL, August 1982. 371 [RFC-DELIVER-BY] 372 Newman, D., "Deliver By SMTP Service Extension", draft- 373 newman-deliver-02.txt, Innosoft, January 1999. 375 [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For- 376 mat for Delivery Status Notifications", RFC 1894, Univer- 377 sity of Tennessee, Octel Network Services, January 1996. 379 [RFC-ESMTP-DSN] 380 Moore, K., "SMTP Service Extension for Delivery Status 381 Notifications", RFC 1891, University of Tennessee, Janu- 382 ary 1996. 384 [RFC-KEYWORDS] 385 Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", RFC 2119, Harvard University, March 387 1997. 389 [RFC-MDN] Fajman, R., "An Extensible Message Format for Message 390 Disposition Notifications", RFC 2298, National Institutes 391 of Health, March 1998. 393 [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw, M., "A One-Time 394 Password System", RFC 2289, Bellcore, Kaman Sciences Cor- 395 poration, Nesser & Nesser Consulting, Bellcore, February 396 1998. 398 [RFC-REPORT] 399 Vaudreuil, G., "The Multipart/Report Content Type for the 400 Reporting of Mail System Administrative Messages", RFC 401 1892, Octel Network Services, January 1996. 403 [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 404 821, USC/Information Sciences Institute, August 1982. 406 8. Acknowledgements 408 This document is the product of input from many people and many 409 sources, including all of the members of the Message Tracking Working 410 Group. It owes much to earlier work by Gordon Jones, Bruce Ernst and 411 Greg Vaudreuil. In particular, I'd like to also thank Ken Lin for his 412 considerable contributions to the early drafts. 414 9. Authors' Addresses 415 Tony Hansen 416 AT&T Laboratories 417 Lincroft, NJ 07738 418 USA 420 Phone: +1 732 576-3207 421 E-Mail: tony@att.com 423 10. Full Copyright Statement 425 Copyright (C) The Internet Society (1999). All Rights Reserved. 427 This document and translations of it may be copied and furnished to 428 others, and derivative works that comment on or otherwise explain it or 429 assist in its implmentation may be prepared, copied, published and dis- 430 tributed, in whole or in part, without restriction of any kind, provided 431 that the above copyright notice and this paragraph are included on all 432 such copies and derivative works. However, this document itself may not 433 be modified in any way, such as by removing the copyright notice or 434 references to the Internet Society or other Internet organisations, 435 except as needed for the purpose of developing Internet standards in 436 which case the procedures for copyrights defined in the Internet Stan- 437 dards process must be followed, or as required to translate it into 438 languages other than English. 440 The limited permissions granted above are perpetual and will not be 441 revoked by the Internet Society or its successors or assigns. 443 This document and the information contained herein is provided on 444 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 445 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 446 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 447 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 448 FITNESS FOR A PARTICULAR PURPOSE. 450 This document expires May 2, 2001.