idnits 2.17.1 draft-jones-msgtrk-def-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-jones-msgtrk-def-00', but the file name used is 'draft-jones-msgtrk-def-00' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 223 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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 an Authors' Addresses Section. ** There are 44 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '... Drafts are w...' == Line 11 has weird spacing: '...cuments of t...' == Line 12 has weird spacing: '... groups may ...' == Line 16 has weird spacing: '... Drafts may ...' == Line 17 has weird spacing: '...iate to use ...' == (5 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MSGTRK BOF G. Jones [gbjones@mitre.org] 2 INTERNET-DRAFT B. Ernst [bruce_ernst@lotus.ssw.com] 3 draft-ietf-jones-msgtrk-def-00.txt G. Vaudreuil [gregv@ons.octel.com] 4 Expires: February 1999 6 Basic Definition of Message Tracking 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 25 ftp.ietf.org (US East Coast), or ftp.isi.edu(US West Coast). 27 Abstract 29 This document defines message tracking as a prelude to the creation of 30 a message tracking model. Message tracking is a messaging management 31 function; it provides the ability to find out, after the fact, the path 32 that a particular message took through the messaging system, the current 33 status of that message, and its characteristics. 35 Definition 37 Message tracking refers, in its simplest form, to determining the path an 38 RFC822 message has taken, its current location, and its characteristics. 39 Message tracking allows the originator of a message to issue a request 40 about a previously sent message, the answer to which contains the delivery 41 status, delivery time, delivered recipients, and other information about 42 the message. This is different from the delivery status notification (DSN) 43 function in use today, because DSNs are requested at the time of submission 44 and are generated automatically; alternatively a tracking request is 45 generated independently of the previously submitted message's status and is 46 done so on demand. 48 This capability is analogous to the service provided by carriers of 49 conventional paper mail - the ability to quickly locate where a package is, 50 and to determine whether or not the package has been delivered to its 51 destination. An Internet-standard approach will allow development of 52 message tracking applications that can operate in a multi-vendor messaging 53 environment, and will encourage operation of the function across 54 administrative boundaries. 56 One might ask: why should there be a standard for message tracking when 57 Internet domains will be unwilling to open themselves up to outside 58 tracking requests ? This is one reason why we design and implement 59 Internet standards. So that there is a reliable, secure, agreed upon 60 mechanism for message tracking that people will be willing to use. 62 Companies have implemented and are implementing message tracking today. 63 Standardization of this technique will aid the Internet user community, 64 make Internet messaging more profitable, and fulfill a key messaging 65 management need. 67 Reasons for Message Tracking 69 Message tracking is useful for determining the whereabouts and status of 70 "lost" messages, and for several other purposes: 72 o When there is a lack of trust in the messaging system, such as when an 73 originator claims a message failed to be delivered, the point of failure 74 may be isolated. This includes messages that were never delivered or 75 messages that were delivered incorrectly. Message tracking thus adds to the 76 overall reliability of the mail system; 78 o Per-message information can be used for accounting, billing, and 79 performance purposes. Traffic can be itemized on a per-origin or per- 80 destination basis by system or originator. This typically involves two 81 steps - collection of message traffic data, followed by the gehe time they 82 are submitted to an MTA up until the time a network of MTAs discharges the 83 message onward to another entity (e.g. a proprietary mail server, IMAP 84 server, and so on). 86 o Message tracking information adds security in that the origins of 87 potential security threats can be more precisely determined. If a system 88 were flooded with traffic, for instance, the origin of this traffic would 89 become known. Message tracking information is suitable for routine security 90 audits containing the details of messaging traffic over specific time 91 intervals; 93 o End-to-end delivery time could be measured; 95 o Message tracking would aid in message loop detection, since unique 96 message identifiers of looping messages, when these exist, would be 97 recorded multiple times; 99 o Performance characteristics about the type of messaging traffic could be 100 determined, such as when an inbound message causes the creation of multiple 101 outbound messages, and the percentage of messages that were actually 102 delivery reports or receipts. This is valuable for performance 103 measurement, among other reasons; 105 o Standardized message tracking information acts as a bridge between 106 dissimilar messaging systems and dissimilar messaging communities; 108 Tracking Messages on the Public Internet 110 One might ask: why bother to track messages if a majority of public 111 Internet traffic is point to point; messages don't live long enough to be 112 trackable, and are not an interesting event to track since you always 113 know the next point ? Just because you know where a message went that 114 doesn't mean you know what happened to it, how fast it got there, or what 115 was in it. As the Internet is used more and more for commercial/official 116 purposes a logging function is commonly embedded in the messaging system 117 internally. Even if most of the message traffic is point to point, this 118 point-to-point traffic is inter-domain, across firewalls, and thus it is 119 even more important to have a reliable tracking mechanism that 120 organizations can agree on. It is something that intra-domain messaging 121 users want. Even if 95% of transactions are point to point, the 5% that is 122 non point-to-point is still a huge amount of traffic, and this is exactly 123 the traffic that users will want to track. Once messaging traffic enters an 124 intranet or domain of any size it invariably encounters a more hierarchical 125 routing structure. 127 Who is Allowed to Track Messages 129 Only the originators of messages are allowed to track their messages. 130 Optionally, an originator may delegate this responsibility to a third 131 party, but this is left for future study. 133 How Tracking is Done: Requests and Responses 135 The originator will issue a message tracking request using the Unique 136 Message Identifier plus security information. The originator (of both 137 the message and the query at this point) will receive optional response 138 criteria such as the message disposition, delivered recipients, delivery 139 time, and the names of MTAs that handled the message. 141 Security for Message Originators 143 One option for message security is that the originator calculates a hash A 144 to be equal to the hash of the message ID + time stamp + a per-user secret. 145 The user then calculates hash B to be the hash of A. The user includes B in 146 the submitted message, and retains A. Later, when the user makes a message 147 tracking request to the messaging system or tracking entity, it submits A 148 in the racking request. The entity receiving the tracking request then uses 149 A to calculate B, since it was already provided B, verifying that the 150 requestor is authentic. Summarily 152 A = H(message ID + time stamp + secret) 153 B = H(A) 155 If the originator of a message were to delegate his or her tracking request 156 to a third party by sending them A, this would be vulnerable to snooping 157 over unencrypted sessions, but the user can decide on a message-by-message 158 basis if this risk is acceptable. 160 Three Possible Architectures 162 There are ways of accomplishing message tracking without mandating the 163 addition of large amounts of new infrastructure on the participants. 164 Optionally, if more infrastructure is proven to be a good and necessary 165 thing, it should be considered. 167 In all cases, messages are only tracked from the time they are submitted 168 to an MTA up until the time a network of MTAs discharges the message 169 onward to another entity (e.g. a proprietary mail server, IMAP server, and 170 so on). 172 The three architectural alternatives offered by the start-up working group 173 to date might be called "ask later", "ask now", and "ask someone else." 175 Under "ask later", a user requests tracking as a service when submitting a 176 message, and then at a later time issues a separate tracking request to the 177 mail system. The user receives a response to the request from the tracking 178 entity. This has the advantage of being deployable within the existing SMTP 179 infrastructure. 181 Under "ask now", a user requests tracking as a service while submitting a 182 message, and receives a step-by-step report contemporaneously from each MTA 183 that handles the message. This provides the user with a high level of 184 service, but also causes extra overhead: an additional message generated 185 for each hop the original message takes. 187 Under "ask someone else", the user issues a separate message tracking 188 request to an entity other than the messaging system at a later time. 189 The user receives a response to the request from this same third-party 190 tracking entity. This has the advantage of allowing tracking to occur when 191 the messaging process has failed but the platform is still working. It also 192 off-loads the tracking function from the messaging system itself. It may, 193 however, require new infrastructure in order to support it. 195 One possibility would be to implement "ask now" and "ask later" as SMTP 196 extensions. One could implement "ask someone else" as a UDP- or TCP-based 197 protocol, among other options. 199 Acknowledgments 201 Thanks to all those who participated in the message tracking meetings. 202 Many thanks to Ned Freed and Harald Alvesrand for the hashing material. 204 Internet Draft Expires February 1999 Internet Draft