idnits 2.17.1 draft-ietf-appsawg-received-state-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2012) is 4292 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) ** Obsolete normative reference: RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Standards Track M. Kucherawy 5 Expires: December 29, 2012 Cloudmark, Inc. 6 June 27, 2012 8 Indicating Email Handling States in Trace Fields 9 draft-ietf-appsawg-received-state-04 11 Abstract 13 This document registers a trace field clause for use in indicating 14 transitions between handling queues or processing states, including 15 enacting inter- and intra-host message transitions. This might 16 include message quarantining, mailing list moderation, timed 17 delivery, queueing for further analysis, content conversion, or other 18 similar causes, as well as optionally identifying normal handling 19 queues. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 29, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Trace Clause . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Granularity . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Mail Parameters Additional-registered-clauses 62 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.2. Mail Parameters Registered-states Sub-Registry . . . . . . 8 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Appendix A. Trace Field Examples . . . . . . . . . . . . . . . . 10 69 A.1. Typical Delivery Without Obvious Extra Handling . . . . . 11 70 A.2. Delivery With Moderation . . . . . . . . . . . . . . . . . 11 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 [SMTP] defines the content of email message trace fields, commonly 76 the "Received" header field. These are typically used to record an 77 audit trail of the path a message follows from origin to destination, 78 with one such field added each time a message moves from one host to 79 the next. 81 Section 3.7.2 of that document mentions that "the most important use 82 of of Received: lines is for debugging mail faults [...]". 84 There are some cases where there may be large time gaps between trace 85 fields. Though this might be caused by transient communication 86 issues, they might also be caused by policy decisions or special 87 processing regarding the content of the message, authorization of 88 some identity on the message, or transitions between major software 89 components. Common examples include message quarantines (filters 90 that cause a message to be held pending further evaluation, or 91 delivery of a message pending manual operator action), pending 92 content analysis, or mailing list servers that impose moderation 93 rules (mailing list owner action required regarding mail from authors 94 not subscribed to those lists). 96 This document registers a new optional clause that can be used in 97 trace fields to indicate that a message entered such a special 98 processing queue or state for some period. This allows inspection of 99 the trace information to reveal that the cause for a time gap in 100 trace fields was imposed by additional processing rather than one 101 caused by transient technical difficulties. 103 2. Key Words 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [KEYWORDS]. 109 3. Trace Clause 111 This specification defines a clause, called "state", which MAY be 112 used when creating a Recevied header field (see Section 4.4 of 113 [SMTP]) to indicate the nature of additional handling imposed on the 114 relaying of a message toward its recipient(s). It is followed by a 115 single keyword that provides that detail. A Mail Transfer Agent 116 (MTA) or other handling agent that determines a message has entered a 117 state other than normal queueing of messages for relaying or delivery 118 MAY generate a trace field including one of these clauses. That is, 119 the presence of this clause on a trace field is an indication of the 120 entry of the message into that state; a later trace field added would 121 indicate its departure from that state. 123 An MTA implementing this specification SHOULD add a Received field as 124 described whenever: 126 a. It determines that a special handling condition will occur, and 127 places it into that condition; or 129 b. It determines that no special handling is required, and prepares 130 it for relay to the next handling agent. 132 An MTA need not add a Received field indicating preparation for 133 normal handoff to the next handling agent if it has already added a 134 Received field for some other reason. Trace data added by the next 135 handling agent will imply the message's exit from the special 136 handling condition. 138 If a single MTA processes a message through multiple special handling 139 conditions, it MAY add a Received for each distinct condition. 141 For example: Presume a message will be injected into MTA-1, then 142 travel to MTA-3 via MTA-2, and then MTA-3 enacts final delivery. At 143 MTA-2, it is determined that some action will be taken that will 144 cause the message to undergo some handling change that is outside of 145 typical message flow. In this case: 147 1. MTA-1 adds a typical Received field and relays it to MTA-2 149 2. MTA-2 determines that the atypical handling will occur and adds a 150 Received field using the extension specified here 152 3. On completion of the atypical handling, MTA-2 relays the message 153 to MTA-3 155 4. MTA-3 adds a typical Received field and enacts final delivery of 156 the message 158 Appropriate use of this mechanism does not include associating meta- 159 data with the message, such as categorizing the message (e.g., the 160 notions of "is spam" or "was 8-bit, converted to 7-bit"). Processing 161 agents also cannot reliably use this mechanism to determine anything 162 about the message content, since there is no guarantee that all 163 agents in the chain of handling made such annotations allowing 164 correct conclusions. The sole purpose here is to allow one to 165 determine the point(s) in the chain of custody of a message at which 166 the message was subjected to handling outside of normal message 167 routing and queueing. 169 The following state keywords are defined in this document; extensions 170 may define other registered keywords (see Section 6.2): 172 auth: The message entered a queue pending authentication of some 173 identifier in the message. 175 content: The message entered a queue pending content analysis, such 176 as scanning for spam or viruses. 178 convert: The message entered a queue pending content conversion. 180 moderation: The message entered a hold pending mailing list 181 moderator action. 183 normal: The message is not in an administrative hold and is queued 184 for or is being handed off to the next handling agent (which may 185 be local delivery). This is the default interpretation when no 186 "state" clause is present. 188 other: The message entered a hold or queue for reasons not covered 189 by other keywords in this list, and not for transient technology 190 issues. 192 outbound: The message entered a queue for outbound relaying. This 193 is typically the last case added for a single host, and the next 194 Received header field is expected to be added by some other host. 196 quarantine: The message entered a hold in an isolation queue pending 197 operator action for local policy reasons. 199 timed: The message entered a hold in order to meet a requested 200 delivery window, such as is defined in [FUTURERELEASE]. 202 The "state" clause is added in Section 6 to the Additional- 203 Registered-Clauses IANA sub-registry. The ABNF for this clause is: 205 State = CFWS "state" FWS queue-state-keyword [ "/" value ] 207 queue-state-keyword = ( reg-state-keyword / unreg-state-keyword ) 209 reg-state-keyword = ( "auth" / "content" / "convert" / 210 "moderation" / "normal" / "other" / 211 "outbound" / "quarantine" / "timed" / 212 additional-state-keyword ) 214 additional-state-keyword = token 215 ; MUST be registered; see 216 ; "IANA Considerations" below 218 value = token 220 unreg-state-keyword = token 222 "FWS" and "CFWS" are defined in [MAIL]. "token" is defined in [MIME]. 224 A transfer agent making use of this extension MAY also include header 225 field comments to provide additional information. 227 The "value" is available for providing additional labels as 228 explanation for the state transition. Examples could include: 230 o convert/unicode2ascii 232 o moderation/not-subscribed 234 o quarantine/spam 236 4. Discussion 238 Handling agents are not expected to implement or support all of 239 these. Indeed, recording trace information for all of the states 240 described above could make the header of a message inordinately 241 large. Rather, an agent is encouraged to apply state annotations 242 when a message enters a handling queue where a significant condition 243 occurs or where significant additional processing or delay is 244 possible, and especially when a handoff has occurred between two 245 different, independent agents. 247 For example, an MTA receiving a message, doing message 248 authentication, scanning for viruses and spam, and then putting it in 249 an outbound queue could add four Received header fields denoting each 250 of these states. However, where they are all done as part of a 251 single system process, in a single pass, doing so would be considered 252 unusual (and extremely verbose). This method SHOULD NOT be applied 253 except when doing detailed analysis of a single component to identify 254 performance issues with those steps. 256 Rather, an agent that wishes to make a state annotation SHOULD add 257 only a single Received header field including such annotation, thus 258 indicating (a) the time of completion of its handling of the message 259 via the date portion of the field, and (b) the final disposition of 260 that message relative to that agent. For example, an MTA receiving a 261 message that performs various checks on the message before 262 immediately handing it off to a Mailing List Manager (MLM) would only 263 record a "normal" state, assuming it passes those checks. The MLM 264 would then evaluate the message and record its own state once it 265 decides what the next step will be for the handling of that message. 267 5. Granularity 269 The degree of granularity -- and therefore the degree of verbosity -- 270 recorded through the use of this additional trace clause is likely to 271 vary depending on circumstances. It will typically be the case that 272 use of this clause will be limited to "unusual" transitions, such as 273 when a message requires additional scrutiny or other processing, or 274 needs to be quarantined. 276 Somewhat greater granularity might also include transitions of 277 administrative responsibility, such as between an Mail Transfer Agent 278 (MTA) operator and a Mailing List Manager (MLM) operator. This could 279 be further enhanced to note some transitions that are interesting 280 only when other transitions have occurred, such as noting entry to 281 the outbound queue only when the message is originating from an 282 "interesting" source, like an MLM, since an MLM can introduce 283 significant changes to the message or delivery delay and it could be 284 useful to know when it completed its processing, as distinct from the 285 subsequent processing by the originating MTA. In circumstances 286 needing very fine-grained trace information, fields might be created 287 to note all of these "significant" network architecture transitions. 289 One should note, however, when choosing higher levels of granularity, 290 that the Received header fields present on a message could be counted 291 by MTAs when trying to decide whether or not a message routing loop 292 is in effect. A message with an abundance of these might cause an 293 incorrect determination that the message is in a delivery loop, 294 causing it to be removed from the mail stream. See Section 6.3 of 295 [SMTP] for further discussion. 297 6. IANA Considerations 298 6.1. Mail Parameters Additional-registered-clauses Sub-Registry 300 This document adds to the "Additional-registered-clauses" sub- 301 registry of the "Mail Parameters" registry, created by [SMTP], the 302 following entry: 304 Clause name: state 306 Description: Indicates entry into a special queue state 308 Syntax Summary: state 310 Reference: [this document] 312 6.2. Mail Parameters Registered-states Sub-Registry 314 The "Mail Parameters" registry at IANA is updated by the creation of 315 the "Registered-states" sub-registry to contain valid state keywords 316 for use with this specification. Updates to this registry are 317 governed by the First Come First Served rules of [IANA] for new 318 registrations. Changes to the status of existing entries are limited 319 to the original registrant or IESG approval. 321 Discussion of all registry updates is encouraged via one or more IETF 322 mailing lists that typically cover email-related subjects prior to 323 approval of the change, as a way of documenting the work. The 324 ietf-smtp@ietf.org list is suggested. 326 Note that only registrations of queue state keywords are permitted. 327 The registry is not to be used for specifying secondary information 328 (i.e., the "value" part of the ABNF in Section 3). 330 Registrations are to include the following entries: 332 Name: The name of the state keyword being defined or updated, which 333 conforms to the ABNF shown in Section 3. 335 Description: A brief description of the keyword's meaning. 337 Specification: The specification document that defines the queue 338 state being registered, or if no stable reference exists, a more 339 detailed explanation of the queue state than is in the 340 "Description", sufficient to allow interoperability. 342 Use: One of "current" (the state keyword is in current use), 343 "deprecated" (the state keyword is in use but not recommended for 344 new implementations), or "historic" (the state keyword is no 345 longer in substantial current use). 347 The initial registration set is as follows: 349 +------------+------------------------+-----------------+---------+ 350 | Name | Description | Specification | Use | 351 +------------+------------------------+-----------------+---------+ 352 | auth | Held for message | [this document] | current | 353 | | authentication | | | 354 +------------+------------------------+-----------------+---------+ 355 | content | Held for message | [this document] | current | 356 | | content analysis | | | 357 +------------+------------------------+-----------------+---------+ 358 | convert | Held for message | [this document] | current | 359 | | content conversion | | | 360 +------------+------------------------+-----------------+---------+ 361 | moderation | Held for list | [this document] | current | 362 | | moderation | | | 363 +------------+------------------------+-----------------+---------+ 364 | normal | Message is not being | [this document] | current | 365 | | held other than to | | | 366 | | accommodate typical | | | 367 | | relaying handling | | | 368 +------------+------------------------+-----------------+---------+ 369 | other | Held for causes not | [this document] | current | 370 | | covered by other | | | 371 | | registered state | | | 372 | | keywords | | | 373 +------------+------------------------+-----------------+---------+ 374 | outbound | Message placed in | [this document] | current | 375 | | outbound queue | | | 376 +------------+------------------------+-----------------+---------+ 377 | quarantine | Held for operator | [this document] | current | 378 | | action due to content | | | 379 | | analysis or local | | | 380 | | policy | | | 381 +------------+------------------------+-----------------+---------+ 382 | timed | Held to accommodate a | [this document] | current | 383 | | specific requested | | | 384 | | delivery window | | | 385 +------------+------------------------+-----------------+---------+ 387 7. Security Considerations 389 The use of this trace information can reveal hints as to local policy 390 that was in effect at the time of message handling. 392 Further discussion about trace field security can be found in Section 393 7.6 of [SMTP]. 395 8. References 397 8.1. Normative References 399 [IANA] Narten, T. and H. Alvestrand, "Guidelines for 400 Writing an IANA Considerations Section in RFCs", 401 BCP 26, RFC 5226, May 2008. 403 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 407 October 2008. 409 [MIME] Freed, N. and N. Borenstein, "Simple Mail Transfer 410 Protocol", RFC 2045, November 1996. 412 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", 413 RFC 5321, October 2008. 415 8.2. Informative References 417 [FUTURERELEASE] White, G. and G. Vaudreuil, "SMTP Submission Service 418 Extension for Future Message Release", RFC 4865, 419 May 2007. 421 Appendix A. Trace Field Examples 423 This section includes a sample of the new trace field clause in use. 425 A.1. Typical Delivery Without Obvious Extra Handling 427 Typical message delivery 429 Received: from newyork.example.com 430 (newyork.example.com [192.0.2.250]) 431 by mail-router.example.net (8.11.6/8.11.6) 432 with ESMTP id i7PK0sH7021929 433 for ; 434 Fri, Feb 15 2002 17:19:22 -0800 435 Received: from internal.example.com 436 (internal.example.com [192.168.0.1]) 437 by newyork.example.com (8.11.6/8.11.6) 438 with ESMTP id i9MKZCRd064134 439 for ; 440 Fri, Feb 15 2002 17:19:08 -0800 442 Example 1: Typical message delivery with no appreciable extra 443 handling; only Received header fields shown 445 A.2. Delivery With Moderation 447 Message delivery after moderation 449 Received: from newyork.example.com 450 (newyork.example.com [192.0.2.250]) 451 by mail-router.example.net (8.11.6/8.11.6) 452 with ESMTP id i7PK0sH7021929 453 for ; 454 Fri, Feb 15 2002 18:33:29 -0800 455 Received: from internal.example.com 456 (internal.example.com [192.168.0.1]) 457 by newyork.example.com (8.11.6/8.11.6) 458 with ESMTP id i9MKZCRd064134 459 for 460 state moderation (sender not subscribed); 461 Fri, Feb 15 2002 17:19:08 -0800 463 Example 2: Message held for moderation; only Received header fields 464 shown 466 The message passed from internal.example.com to newyork.example.com 467 intended for a mailing list hosted at the latter. For list 468 administrative reasons, the message is held there for moderation. It 469 is finally released over an hour later and passed to the next host. 470 A comment after the state expression indicates the actual cause for 471 the administrative hold. 473 Appendix B. Acknowledgements 475 The authors wish to acknowledge the following for their reviews and 476 constructive criticisms of this proposal: Tony Finch, Ned Freed, Carl 477 S. Gutenkunst, John Levine, Bill McQuillan, S. Moonesamy, Alexey 478 Melnikov, Robert A. Rosenberg, Hector Santos, Rolf Sonneveld, and 479 Mykyta Yevstifeyev. 481 Authors' Addresses 483 D. Crocker 484 Brandenburg InternetWorking 485 675 Spruce Dr. 486 Sunnyvale 94086 487 USA 489 Phone: +1.408.246.8253 490 EMail: dcrocker@bbiw.net 491 URI: http://bbiw.net 493 Murray S. Kucherawy 494 Cloudmark, Inc. 495 128 King St., 2nd Floor 496 San Francisco, CA 94107 497 US 499 EMail: superuser@gmail.com