idnits 2.17.1 draft-ietf-msgtrk-model-07.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 230 has weird spacing: '..."active enabl...' == Line 249 has weird spacing: '...ted are as f...' == Line 321 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 (October 24, 2002) is 7854 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 394, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1894 (ref. 'RFC-DSN') (Obsoleted by RFC 3464) -- Obsolete informational reference (is this intentional?): RFC 1891 (ref. 'RFC-ESMTP-DSN') (Obsoleted by RFC 3461) -- Obsolete informational reference (is this intentional?): RFC 2298 (ref. 'RFC-MDN') (Obsoleted by RFC 3798) -- Obsolete informational reference (is this intentional?): RFC 1892 (ref. 'RFC-REPORT') (Obsoleted by RFC 3462) -- No information found for draft-ietf-msgtrk-smtpext- - is the name correct? -- No information found for draft-ietf-msgtrk-trkstat- - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-msgtrk-mtqp-01 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Hansen 3 draft-ietf-msgtrk-model-07.txt AT&T Laboratories 4 Valid for six months October 24, 2002 6 Message Tracking Model and Requirements 8 10 Authors' version: 1.20 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This memo and its companions are discussed on the MSGTRK working 33 group mailing list, ietf-msgtrk@imc.org. To subscribe, send a message 34 with the word "subscribe" in the body (on a line by itself) to the 35 address ietf-msgtrk-request@imc.org. An archive of the mailing list may 36 be found at http://www.ietf.org/archive/msgtrk. 38 Copyright Notice 40 Copyright (C) The Internet Society (%Dy%). All Rights Reserved. 42 Abstract 44 Customers buying enterprise message systems often ask: Can I track 45 the messages? Message tracking is the ability to find out the path that 46 a particular message has taken through a messaging system and the 47 current routing status of that message. This document provides a model 48 of message tracking that can be used for understanding the Internet-wide 49 message infrastructure and to further enhance those capabilities to 50 include message tracking, as well as requirements for proposed message 51 tracking solutions. 53 1. Problem Statement 55 Consider sending a package through a package delivery company. 56 Once you've sent a package, you would like to be able to find out if the 57 package has been delivered or not, and if not, where that package 58 currently is and what its status is. Note that the status of a package 59 may not include whether it was delivered to its addressee, but just the 60 destination. Many package carriers provide such services today, often 61 via a web interface. 63 Message tracking extends that capability to the Internet-wide mes- 64 sage infrastructure, analogous to the service provided by package car- 65 riers: the ability to quickly locate where a message (package) is, and 66 to determine whether or not the message (package) has been delivered to 67 its final destination. An Internet-standard approach will allow the 68 development of message tracking applications that can operate in a 69 multi-vendor messaging environment, and will encourage the operation of 70 the function across administrative boundaries. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC-KEYWORDS]. 76 2. Definitions 77 The following terms are relevant to message tracking. The terms Track- 78 ing User Agent and Tracking Server are new, while all other terms have 79 been collected here from other sources. 81 Originating Mail User Agent (MUA) 82 The originating mail user agent is the software used to 83 compose and originate a message. It is the software sit- 84 ting on a person's desktop. 86 Originating Mail Submission Agent (MSA) 87 The Mail Submission Agent accepts a message from a User 88 Agent, adds or modifies it as required for Internet stan- 89 dards and/or site policy, and injects the message into 90 the network. The MSA may be the initial MTA or may hand 91 off the message to an MTA. 93 Message Transfer Agent (MTA) 94 A Message Transfer Agent accepts a message and moves it 95 forward towards its destination. That destination may be 96 local or reached via another MTA. It may use a local 97 queue to store the message before transferring it 98 further. Any MTA may generate a Non-Delivery Notifica- 99 tion. 101 Intermediate Message Transfer Agent (MTA) 102 An Intermediate MTA is an MTA that accepts a message for 103 transfer somewhere else. 105 Final Message Transfer Agent (MTA) 106 A Final MTA is an MTA that accepts a message for local 107 delivery. It is the final place that a message is 108 accepted. The final MTA is what sends any Delivery 109 Status Notifications (DSNs). (Intermediate MTA's may 110 also send a DSN if it relays to a non-DSN aware MTA.) 112 Foreign Message Transfer Agent 113 A foreign MTA provides delivery of messages using other 114 protocols than those specified for Internet mail, such as 115 an X.400 mail system. 117 Gateway Message Transfer Agent (GW-MTA) 118 A gateway MTA accepts a message for transfer to a foreign 119 MTA outside of the Internet protocol space. 121 Local Delivery Agent (LDA) 122 The local Delivery Agent delivers the message to the 123 local message store. (The MTA and LDA are often combined 124 into the same program.) 126 Delivery Status Notification (DSN) 127 A Delivery Status Notification [RFC-DSN] is produced by 128 an MTA when a message is unsuccessfully delivered, either 129 to its next hop or the final message store, or when it is 130 successfully delivered, either to a foreign MTA, to a 131 local delivery agent, or a non-DSN aware MTA. Positive 132 notifications are only performed [RFC-ESMTP-DSN] when 133 specifically requested. 135 Non-Delivery Notification (NDN) 136 A non-delivery notification is a special form of DSN 137 indicating unsuccessful delivery. 139 Message Disposition Notification (MDN) 140 A Message Disposition Notification is used to report the 141 disposition of a message after it has been successfully 142 delivered to a recipient. 144 Tracking User Agent (TUA) 145 A tracking user agent wants to find information on a mes- 146 sage on the behalf of a user. It is the requestor or 147 initiator of such a request. (The MUA and TUA could be 148 combined into the same program.) 150 Tracking Server 151 A tracking server provides tracking information to a 152 tracking client. It is the repository of the information 153 about a message for the traversal through a particular 154 MTA. (The tracking server and MTA may run on the same 155 system.) 157 3. Entities 159 The entities involved in message tracking are: message user 160 agents, message submission agents, message transfer agents, tracking 161 user agents and tracking servers. 163 4. Requirements 165 These are requirements that any message tracking solution must be 166 able to satisfy: 168 The message tracking solution: 170 ** MUST scale to the internet. 172 ** MUST be easy to deploy. 174 ** SHOULD maximize the reuse of existing, already deployed tech- 175 nology and infrastructure. 177 ** If possible, SHOULD extend existing protocols and not invent 178 new ones. 180 ** SHOULD have a low implementation cost. (This makes it easy to 181 incorporate into existing products.) 183 ** MUST restrict tracking of a message to the originator of the 184 message (or a delegate). 186 ** MUST be able to do authentication. 188 ** MAY allow an originator to delegate this responsibility to a 189 third party. 191 ** SHOULD have the property that they would allow per-message 192 delegation of the tracking responsibility. 194 ** MUST require a tracking user agent to prove that they are per- 195 mitted to request the tracking information. 197 ** MUST be able to uniquely identify messages. 199 ** MUST require every message to have unique identification. 201 5. Interaction Models 203 There are several models by which tracking of messages can be 204 enabled, by which messages can be tracked, and by which information can 205 be requested and gathered. 207 5.1. Tracking Enabling Models 209 Either the envelope or message header must contain enough informa- 210 tion to track a message and securely retrieve information about the mes- 211 sage. Any message that does not have enough information to track it is 212 by definition not trackable. 214 If there is not enough information available in current standard 215 envelopes or message headers, then the current standards will need to be 216 extended. Either the MUA or MSA must determine the additional informa- 217 tion and enable the tracking by adding the additional information to 218 either the envelope or header. 220 This leads to two tracking enabling models: passive enabling and 221 active enabling. 223 5.1.1. Passive Enabling Model 224 The "passive enabling" model assumes that there is sufficient informa- 225 tion available. No UA or MSA interaction occurs to turn tracking on; it 226 is on by default. 228 5.1.2. Active Enabling Model 230 The "active enabling" model requires that the MUA and MSA exchange 231 information when the message is submitted. This exchange indicates that 232 logging of the message's traversal should be performed, as well as pro- 233 viding enough additional information to allow the message to be tracked. 234 This information will need to be passed on to subsequent MTAs as needed. 236 5.2. Tracking Request Models 237 There are several models by which tracking information may be requested. 239 5.2.1. Passive Request Model 241 The "passive request" model requires active enabling to indicate 242 that some form of tracking is to be performed. The tracking information 243 can be sent back immediately (as a form of telemetry) or sent to a 3rd 244 party for later retrieval. 246 5.2.2. Passive Request Tracking Information 248 Forms of passive tracking information that could potentially be 249 requested are as follows. Note that mechanisms already exist for 250 requesting the information marked with a (+). The references for such 251 mechanisms are listed at the end of each such entry. 253 ** send a DSN of a message arriving at an intermediate MTA 255 ** (+) send a DSN of a message being rejected while at an inter- 256 mediate MTA [RFC-DSN] 258 ** (+) send a DSN of a message leaving an intermediate MTA and 259 going to another MTA [RFC-DELIVER-BY] 261 ** send a DSN of a message arriving at a final MTA 263 ** (+) send a DSN of a message being rejected while at a final 264 MTA [RFC-DSN] 266 ** (+) send a DSN of a message being delivered to a user's mes- 267 sage store [RFC-DSN] 269 ** (+) send a DSN of a message being delivered to a foreign MTA 270 [RFC-DSN] 272 ** (+) send an MDN of a message being read by an end user [RFC- 273 MDN] 275 5.3. Active Request Model 277 The "active request" model requires an active query by a user's 278 user agent to the MSA, intermediate MTAs and final MTA, or to a third 279 party, to find the message's status as known by that MTA. Active 280 request will work with either passive enabling or active enabling. 282 5.3.1. Server Chaining vs. Server Referrals 283 When a tracking server has been asked for tracking information, and the 284 message has been passed on to another MTA of which this tracking server 285 has no tracking knowledge, there are two modelling choices: 287 ** the first tracking server will contact the next tracking 288 server to query for status and pass back the combined status 289 (server chaining), or 291 ** the first tracking server will return the address of the next 292 MTA and the tracking client has the responsibility of contact- 293 ing the next tracking server (server referrals). 295 5.3.2. Active Request Tracking Information 296 Forms of active tracking information that could potentially be requested 297 are as follows. (Note that no mechanisms currently exist for requesting 298 such information.) 300 ** the message has been queued for later delivery 302 ** the message was delivered locally 304 ** the message was delivered to another MTA, 306 ** the message was delivered to a foreign MTA 308 ** ask a different tracking server, 310 ** I know but can't tell you, 312 ** I don't know. 314 5.4. Combining DSN and MDN Information with Message Tracking Informa- 315 tion 317 The information that would be retrieved by message tracking and the 318 information that is returned for DSN and MDN requests all attempt to 319 answer the question of "what happened to message XX"? The information 320 provided by each is complementary in nature, but similar. A tracking 321 user agent could use all three possible information sources to present 322 a total view of the status of a message. 324 Both DSN and MDN notifications utilize the formats defined by RFC 325 1892 [RFC-REPORT]. This suggests that the information returned by mes- 326 sage tracking solutions should also be similar. 328 6. Security Considerations 330 6.1. Security Considerations Summary 332 Security vulnerabilities are detailed in [DRAFT-MTRK-ESMTP], 333 [DRAFT-MTRK-TSN] and [DRAFT-MTRK-MTQP]. These consideratons include: 335 ** vulnerability to snooping or replay attacks when using unen- 336 crypted sessions 338 ** a dependency on the randomness of the per-message secret 340 ** reliance on TLS 342 ** man-in-the-middle attacks 344 ** reliance on the server maintaining the security level when it 345 performs chaining 347 ** denial of service 349 ** confidentiality concerns 351 ** forgery by malicious servers 353 6.2. Message Identification and Authentication 355 This is a security model for message identification and authentica- 356 tion that could be deployed. (There may be others.) 358 A Tracking User Agent must prove that they are permitted to request 359 tracking information about a message. Every [RFC-822]-compliant message 360 is supposed to contain a Message-Id header. One possible mechanism is 361 for the originator to calculate a one-way hash A from the message ID + 362 time stamp + a per-user secret. The user then calculates another one- 363 way hash B to be the hash of A. The user includes B in the submitted 364 message, and retains A. Later, when the user makes a message tracking 365 request to the messaging system or tracking entity, it submits A in the 366 tracking request. The entity receiving the tracking request then uses A 367 to calculate B, since it was already provided B, verifying that the 368 requestor is authentic. In summary, 370 A = H(message ID + time stamp + secret) 372 B = H(A) 374 Another possible mechanism for A is to ignore the message ID and time 375 stamp and just use a one-way hash from a large (>128 bits) random 376 number. B would be calculated as before. In summary, 378 A = H(large-random-number) 380 B = H(A) 382 This is similar in technique to the methods used for One-Time Passwords 383 [RFC-OTP]. The success of these techniques is dependent on the random- 384 ness of the per-user secret or the large random number, which can be 385 incredibly difficult in some environments. 387 If the originator of a message were to delegate his or her tracking 388 request to a third party by sending it A, this would be vulnerable to 389 snooping over unencrypted sessions. The user can decide on a message- 390 by-message basis if this risk is acceptable. 392 7. Informational References 394 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet 395 Text Messages", STD 11, RFC 822, UDEL, August 1982. 397 [RFC-DELIVER-BY] 398 Newman, D., "Deliver By SMTP Service Extension", draft- 399 newman-deliver-02.txt, Innosoft, January 1999. 401 [RFC-DSN] Moore, K., and G. Vaudreuil, "An Extensible Message For- 402 mat for Delivery Status Notifications", RFC 1894, Univer- 403 sity of Tennessee, Octel Network Services, January 1996. 405 [RFC-ESMTP-DSN] 406 Moore, K., "SMTP Service Extension for Delivery Status 407 Notifications", RFC 1891, University of Tennessee, Janu- 408 ary 1996. 410 [RFC-KEYWORDS] 411 Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", RFC 2119, Harvard University, March 413 1997. 415 [RFC-MDN] Fajman, R., "An Extensible Message Format for Message 416 Disposition Notifications", RFC 2298, National Institutes 417 of Health, March 1998. 419 [RFC-OTP] Haller, N., Metz, C., Nesser, P., Straw, M., "A One-Time 420 Password System", RFC 2289, Bellcore, Kaman Sciences Cor- 421 poration, Nesser & Nesser Consulting, Bellcore, February 422 1998. 424 [RFC-REPORT] 425 Vaudreuil, G., "The Multipart/Report Content Type for the 426 Reporting of Mail System Administrative Messages", RFC 427 1892, Octel Network Services, January 1996. 429 [RFC-SMTP]Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 430 821, USC/Information Sciences Institute, August 1982. 432 [DRAFT-MTRK-ESMTP] 433 draft-ietf-msgtrk-smtpext-*.txt, E. Allman, T. Hansen, 434 "SMTP Service Extension for Message Tracking", Sendmail, 435 Inc., AT&T Laboratories, TBD 2002. 437 [DRAFT-MTRK-TSN] 438 draft-ietf-msgtrk-trkstat-*.txt, E. Allman, "The 439 Message/Tracking-Status MIME Extension", Sendmail, Inc., 440 TBD 2002. 442 [DRAFT-MTRK-MTQP] 443 draft-ietf-msgtrk-mtqp-01.txt T. Hansen, "Message Track- 444 ing Query Protocol", TBD 2000. 446 8. Acknowledgements 448 This document is the product of input from many people and many 449 sources, including all of the members of the Message Tracking Working 450 Group, including Philip Hazel, Alexey Melnikov, Lyndon Nerenberg, Chris 451 Newman, and Gregory Neil Shapiro. It owes much to earlier work by Gor- 452 don Jones, Bruce Ernst and Greg Vaudreuil. In particular, I'd like to 453 also thank Ken Lin for his considerable contributions to the early 454 drafts. 456 9. Authors' Addresses 457 Tony Hansen 458 AT&T Laboratories 459 Middletown, NJ 07748 460 USA 462 Phone: +1.732.420.8934 463 E-Mail: tony@att.com 465 10. Full Copyright Statement 467 Copyright (C) The Internet Society (%Dy%). All Rights Reserved. 469 This document and translations of it may be copied and furnished to 470 others, and derivative works that comment on or otherwise explain it or 471 assist in its implementation may be prepared, copied, published and dis- 472 tributed, in whole or in part, without restriction of any kind, provided 473 that the above copyright notice and this paragraph are included on all 474 such copies and derivative works. However, this document itself may not 475 be modified in any way, such as by removing the copyright notice or 476 references to the Internet Society or other Internet organizations, 477 except as needed for the purpose of developing Internet standards in 478 which case the procedures for copyrights defined in the Internet Stan- 479 dards process must be followed, or as required to translate it into 480 languages other than English. 482 The limited permissions granted above are perpetual and will not be 483 revoked by the Internet Society or its successors or assigns. 485 This document and the information contained herein is provided on 486 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 487 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 488 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 489 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 490 FITNESS FOR A PARTICULAR PURPOSE. 492 This document expires April 24, 2003.