idnits 2.17.1 draft-ietf-msgtrk-trkstat-00.txt: ** The Abstract section seems to be numbered 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. ** 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 62 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. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations: discussed in section 4 of this memo.' ) ** 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.) ** There are 89 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC-ESMTP], [RFC-DSN-STAT], [RFC-MIME], [DRAFT-MTRK-SMTPEXT], [RFC-MDN], [DRAFT-MTRK-MTQP], [RFC-DSN-SMTP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '... This docum...' == Line 13 has weird spacing: '...-Drafts are...' == Line 14 has weird spacing: '...working docum...' == Line 15 has weird spacing: '...ups may also ...' == Line 19 has weird spacing: '...eted by other...' == (84 more instances...) -- 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 (December 14, 2000) is 8505 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) -- Missing reference section? 'RFC-DSN-SMTP' on line 355 looks like a reference -- Missing reference section? 'RFC-MDN' on line 384 looks like a reference -- Missing reference section? 'RFC-MIME' on line 388 looks like a reference -- Missing reference section? 'RFC-DSN-STAT' on line 359 looks like a reference -- Missing reference section? 'DRAFT-MTRK-MTQP' on line 338 looks like a reference -- Missing reference section? 'RFC-ESMTP' on line 367 looks like a reference -- Missing reference section? 'DRAFT-MTRK-SMTPEXT' on line 342 looks like a reference -- Missing reference section? 'DRAFT-MTRK-MODEL' on line 334 looks like a reference -- Missing reference section? 'RFC-ABNF' on line 346 looks like a reference -- Missing reference section? 'RFC-MSGFMT' on line 393 looks like a reference -- Missing reference section? 'RFC-HOSTREQ' on line 372 looks like a reference -- Missing reference section? 'RFC-KEYWORDS' on line 376 looks like a reference -- Missing reference section? 'RFC-RELATED' on line 397 looks like a reference -- Missing reference section? 'RFC-EMSSC' on line 363 looks like a reference -- Missing reference section? 'RFC-LMTP' on line 380 looks like a reference -- Missing reference section? 'RFC-DSN-REPT' on line 350 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft E. Allman 2 draft-ietf-msgtrk-trkstat-00.txt Sendmail, Inc. 3 Valid for six months December 14, 2000 4 Updates: RFC 1893 6 The Message/Tracking-Status MIME Extension 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also dis- 16 tribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at: 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at: 29 http://www.ietf.org/shadow.html 31 This document is a submission by the MSGTRK Working Group of the 32 Internet Engineering Task Force (IETF). Comments should be submitted 33 to the msgtrk@imc.org mailing list. An archive of the mailing list 34 may be found at 36 http://www.ietf.org/archive/msgtrk 38 Distribution of this memo is unlimited. 40 1. Abstract 42 Message Tracking is expected to be used to determine the sta- 43 tus of undelivered e-mail upon request. Tracking is used in con- 44 junction with Delivery Status Notifications [RFC-DSN-SMTP] and Mes- 45 sage Disposition Notifications [RFC-MDN]; generally, a message 46 tracking request will be issued only when a DSN or MDN has not been 47 received within a reasonable timeout period. 49 This memo defines a MIME [RFC-MIME] content-type for message 50 tracking status in the same spirit as RFC 1894, ``An Extensible 51 Message Format for Delivery Status Notifications'' [RFC-DSN-STAT]. 53 It is to be issued upon a request as described in ``Message Track- 54 ing Query Protocol'' [DRAFT-MTRK-MTQP]. This memo defines only the 55 format of the status information. An extension to SMTP [RFC-ESMTP] 56 to label messages for further tracking and request tracking status 57 is defined in a separate memo [DRAFT-MTRK-SMTPEXT]. 59 2. Other Documents and Conformance 61 The model used for Message Tracking is described in [DRAFT- 62 MTRK-MODEL]. 64 Message tracking is intended for use as a "last resort" mecha- 65 nism. Normally, Delivery Status Notifications (DSNs) [RFC-DSN- 66 SMTP] and Message Disposition Notifications (MDNs) [RFC-MDN] would 67 provide the primary delivery status. Only if no response from 68 either of these mechanisms would Message Tracking be used. 70 This document is based on [RFC-DSN-STAT]. Sections 1.3 (Ter- 71 minology), 2.1.1 (General conventions for DSN fields), 2.1.2 72 ("*-type" subfields), and 2.1.3 (Lexical tokens imported from RFC 73 822) of [RFC-DSN-STAT] are included into this document by refer- 74 ence. Other sections are further incorporated as described herein. 76 Syntax notation in this document conforms to [RFC-ABNF]. 78 The following lexical tokens, defined in [RFC-MSGFMT], are 79 used in the ABNF grammar for MTSNs: atom, CHAR, comment, CR, CRLF, 80 DIGIT, LF, linear-white-space, SPACE, text. The date-time lexical 81 token is defined in [RFC-HOSTREQ]. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 84 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 85 in this document are to be interpreted as described in RFC 2119 86 [RFC-KEYWORDS]. 88 3. Format of a Message Tracking Status Notification 90 A Message Tracking Status Notification (MTSN) is intended to 91 be returned as the body of a Message Tracking request [DRAFT-MTRK- 92 MTQP]. The actual body MUST be a multipart/related [RFC-RELATED] 93 with type of "tracking-status"; each subpart MUST be type "mes- 94 sage/tracking-status" as described herein. 96 3.1. The message/tracking-status content-type 98 The message/tracking-status content-type is defined as fol- 99 lows: 101 MIME type name: message 102 MIME subtype name: tracking-status 103 Optional parameters: none 104 Encoding considerations: "7bit" encoding is sufficient and 105 MUST be used to maintain readability 106 when viewed by non-MIME mail readers. 107 Security considerations: discussed in section 4 of this memo. 109 The body of a message/tracking-status is modeled after 110 [RFC-DSN-STAT]. That body consists of one or more "fields" for- 111 matted to according to the ABNF of RFC 822 headers "fields" (see 112 [RFC-MSGFMT]). The per-message fields appear first, followed by 113 a blank line. Following the per-message fields are one or more 114 groups of per-recipient fields. Each group of per-recipient 115 fields is preceded by a blank line. Formally, the syntax of the 116 message/tracking-status content is as follows: 118 tracking-status-content = 119 per-message-fields 1*( CRLF per-recipient-fields ) 121 The per-message fields are described in section 3.2. The per- 122 recipient fields are described in section 3.3. 124 3.1.1. General conventions for MTSN fields 126 Section 2.1.1 (General conventions for DSN fields) of 127 [RFC-DSN-STAT] is included herein by reference. Notably, the 128 definition of xtext is identical to that of that document. 130 3.1.2. *-type subfields 132 Section 2.1.2 (*-type subfields) of [RFC-DSN-STAT] is 133 included herein by reference. Notably, the definitions of 134 address-type, diagnostic-type, and MTA-name type are identi- 135 cal to that of RFC 1894. 137 3.2. Per-Message MTSN Fields 139 Some fields of an MTSN apply to all of the addresses in a 140 single envelope. These fields may appear at most once in any 141 MTSN. These fields are used to correlate the MTSN with the 142 original message transaction and to provide additional informa- 143 tion which may be useful to gateways. 145 per-message-fields = 146 original-envelope-id-field CRLF 147 reporting-mta-field CRLF 148 arrival-date CRLF 149 *( extension-field CRLF ) 151 3.2.1. The Original-Envelope-Id field 153 The optional Original-Envelope-Id field is defined as in 154 section 2.2.1 of [RFC-DSN-STAT]. This field is REQUIRED. 156 3.2.2. The Reporting-MTA field 158 The Reporting-MTA field is defined as in section 2.2.2 159 of [RFC-DSN-STAT]. This field is REQUIRED. 161 3.2.3. The Arrival-Date field 163 The Arrival-Date field is defined as in section 2.2.5 of 164 [RFC-DSN-STAT]. This field is REQUIRED. 166 3.3. Per-Recipient MTSN fields 168 An MTSN contains information about attempts to deliver a 169 message to one or more recipients. The delivery information for 170 any particular recipient is contained in a group of contiguous 171 per-recipient fields. Each group of per-recipient fields is 172 preceded by a blank line. 174 The syntax for the group of per-recipient fields is as fol- 175 lows: 177 per-recipient-fields = 178 original-recipient-field CRLF 179 final-recipient-field CRLF 180 action-field CRLF 181 status-field CRLF 182 [ remote-mta-field CRLF ] 183 [ last-attempt-date-field CRLF ] 184 [ will-retry-until-field CRLF ] 185 *( extension-field CRLF ) 187 3.3.1. Original-Recipient field 189 The optional Original-Recipient field is defined as in 190 section 2.3.1 of [RFC-DSN-STAT]. This field is REQUIRED. 192 3.3.2. Final-Recipient field 194 The required Final-Recipient field is defined as in sec- 195 tion 2.3.2 of [RFC-DSN-STAT]. This field is REQUIRED. 197 3.3.3. Action field 199 The required Action field indicates the action performed 200 by the Reporting-MTA as a result of its attempt to delivery 201 the message to this recipient address. This field MUST be 202 present for each recipient named in the MTSN. The syntax is 203 as defined in section 2.3.3 of RFC 1894. This field is 204 REQUIRED. 206 Valid actions are: 208 failed The message could not be delivered. If DSNs 209 have been enabled, a "failed" DSN should already 210 have been returned. 212 delayed The message is currently waiting in the MTA 213 queue for future delivery. Essentially, this 214 action means "the message is located, and it is 215 here." 217 delivered The message has been successfully delivered to 218 the final recipient. This includes "delivery" 219 to a mailing list exploder. No further informa- 220 tion is available; in particular, the tracking 221 agent SHOULD NOT attempt further "downstream" 222 tracking requests. 224 relayed The message has been delivered into an environ- 225 ment that does not support message tracking. No 226 further information is available; in particular, 227 the tracking agent SHOULD NOT attempt further 228 "downstream" tracking requests. 230 transferred The message has been transferred to another 231 MTRK-compliant MTA. The tracking agent SHOULD 232 attempt further "downstream" tracking requests. 234 opaque The message may or may not have been seen by 235 this system. No further information is avail- 236 able or forthcoming. 238 3.3.4. Status field 240 The Status field is defined as in RFC 1894 section 241 2.3.4. A new code is added to RFC 1893 [RFC-EMSSC], 242 "Enhanced Mail System Status Codes", 244 X.1.9 Message relayed to non-compliant mailer" 246 The mailbox address specified was valid, but the mes- 247 sage has been relayed to a system that does not speak 248 this protocol; no further information can be pro- 249 vided. 250 A 2.1.9 Status field MUST be used exclusively with a 251 "relayed" Action field. This field is REQUIRED. 253 3.3.5. Remote-MTA field 255 The Remote-MTA field is defined as in section Reference 256 2.3.5 of [RFC-DSN-STAT]. This field MUST NOT be included if 257 no delivery attempts have been made or if the Action field 258 has value "opaque". If delivery to some agent other than an 259 MTA (for example, a Local Delivery Agent) then this field MAY 260 be included, giving the name of the host on which that agent 261 was contacted. 263 3.3.6. Last-Attempt-Date field 265 The Last-Attempt-Date field is defined as in section 266 Reference 2.3.7 of [RFC-DSN-STAT]. This field is REQUIRED if 267 any delivery attempt has been made, in which case it will 268 specify when it last attempted to deliver this message to 269 another MTA or other Delivery Agent. This field MUST NOT be 270 included if no delivery attempts have been made. 272 3.3.7. Will-Retry-Until field 274 The Will-Retry-Until field is defined as in section Ref- 275 erence 2.3.8 of [RFC-DSN-STAT]. This field is REQUIRED if 276 the message is still in the MTA queue. This field MUST NOT 277 be included if the message is not in the local queue. 279 3.4. Extension fields 281 Future extension fields may be defined as defined in sec- 282 tion 2.4 of [RFC-DSN-STAT]. 284 3.5. Interaction Between MTAs and LDAs 286 A message that has been delivered to an LDA that under- 287 stands message tracking (in particular, an LDA speaking LMTP 288 [RFC-LMTP] that supports the MTRK extension) SHOULD pass the 289 tracking request to the LDA. In this case, the Action field for 290 the MTA->LDA exchange will look the same as a transfer to a com- 291 pliant MTA; that is, a "transferred" tracking status will be 292 issued. 294 4. Security Issues 296 4.1. Forgery 298 Malicious servers may attempt to subvert message tracking 299 and return false information. This could result in misdirection 300 or misinterpretation of results. 302 4.2. Confidentiality 304 Another dimension of security is confidentiality. There 305 may be cases in which a message recipient is autoforwarding mes- 306 sages but does not wish to divulge the address to which the mes- 307 sages are autoforwarded. The desire for such confidentiality 308 will probably be heightened as "wireless mailboxes", such as 309 pagers, become more widely used as autoforward addresses. 311 MTA authors are encouraged to provide a mechanism which 312 enables the end user to preserve the confidentiality of a for- 313 warding address. Depending on the degree of confidentiality 314 required, and the nature of the environment to which a message 315 were being forwarded, this might be accomplished by one or more 316 of: 318 (a) respond with a "relayed" tracking status when a message is 319 forwarded to a confidential forwarding address, and dis- 320 abling further message tracking requests. 322 (b) declaring the message to be delivered, issuing a "deliv- 323 ered" tracking status, re-sending the message to the confi- 324 dential forwarding address, and disabling further message 325 tracking requests. 327 The tracking algorithms MUST NOT allow tracking through 328 list expansions. When a message is delivered to a list, a 329 tracking request MUST respond with an "expanded" tracking status 330 and MUST NOT display the contents of the list. 332 5. References 334 [DRAFT-MTRK-MODEL] 335 T. Hansen, ``Message Tracking Model and Requirements.'' 336 draft-ietf-msgtrk-model-03.txt. November 2000. 338 [DRAFT-MTRK-MTQP] 339 T. Hansen, ``Message Tracking Query Protocol.'' draft-ietf- 340 msgtrk-mtqp-01.txt. November 2000. 342 [DRAFT-MTRK-SMTPEXT] 343 E. Allman, ``SMTP Service Extension for Message Tracking.'' 344 draft-ietf-msgtrk-smtpext-00.txt. December 2000. 346 [RFC-ABNF] 347 Crocker, D., Editor, and P. Overell, ``Augmented BNF for Syn- 348 tax Specifications: ABNF'', RFC 2234, November 1997. 350 [RFC-DSN-REPT] 351 G. Vaudreuil, ``The Multipart/Report Content Type for the 352 Reporting of Mail System Administrative Messages.'' RFC 1892. 353 January 1996. 355 [RFC-DSN-SMTP] 356 K. Moore, ``SMTP Service Extension for Delivery Status Notifi- 357 cations.'' RFC 1891. January 1996. 359 [RFC-DSN-STAT] 360 K. Moore and G. Vaudreuil, ``An Extensible Message Format for 361 Delivery Status Notifications.'' RFC 1894. January 1996. 363 [RFC-EMSSC] 364 G. Vaudreuil, ``Enhanced Mail System Status Codes.'' RFC 365 1893. January 1996. 367 [RFC-ESMTP] 368 Rose, M., Stefferud, E., Crocker, D., Klensin, J. and N. 369 Freed, ``SMTP Service Extensions.'' STD 10, RFC 1869. Novem- 370 ber 1995. 372 [RFC-HOSTREQ] 373 R. Braden (ed.), ``Requirements for Internet Hosts -- Applica- 374 tion and Support.'' STD 3, RFC 1123. October 1989. 376 [RFC-KEYWORDS] 377 S. Bradner, ``Key words for use in RFCs to Indicate Require- 378 ment Levels.'' RFC 2119. March 1997. 380 [RFC-LMTP] 381 J. Myers, ``Local Mail Transfer Protocol.'' RFC 2033. Octo- 382 ber 1996. 384 [RFC-MDN] 385 R. Fajman, ``An Extensible Message Format for Message Disposi- 386 tion Notifications.'' RFC 2298. March 1998. 388 [RFC-MIME] 389 N. Freed and N. Borenstein, ``Multipurpose Internet Mail 390 Extensions (MIME) Part One: Format of Internet Message Bod- 391 ies.'' RFC 2045. November 1996. 393 [RFC-MSGFMT] 394 D. Crocker, ``Standard for the Format of ARPA Internet Text 395 Messages.'' RFC 822. August 1982. 397 [RFC-RELATED] 398 E. Levinson, ``The MIME Multipart/Related Content-type.'' RFC 399 2387. August 1998. 401 6. Author's Address 403 Eric Allman 404 Sendmail, Inc. 405 6603 Shellmound 406 Emeryville, CA 94608 407 U.S.A. 409 E-Mail: eric@Sendmail.COM 410 Phone: +1 510 594 5501 411 Fax: +1 510 594 5411