idnits 2.17.1 draft-kucherawy-received-state-02.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 (January 13, 2012) is 4484 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: July 16, 2012 Cloudmark, Inc. 6 January 13, 2012 8 Indicating Email Handling States in Trace Fields 9 draft-kucherawy-received-state-02 11 Abstract 13 This memo 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, or other similar causes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 16, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. New Trace Clause . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Mail Parameters Additional-registered-clauses 59 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.2. Mail Parameters Registered-states Sub-Registry . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Trace Field Examples . . . . . . . . . . . . . . . . . 8 64 A.1. Typical Delivery Without Obvious Delays . . . . . . . . . . 8 65 A.2. Delivery With Moderation . . . . . . . . . . . . . . . . . 9 66 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 [SMTP] defines the content of email message trace fields, commonly 71 the "Received" field. These are typically used to record an audit 72 trail of the path a message follows from origin to destination, with 73 one such field added each time a message moves from one host to the 74 next. 76 There are some cases where there may be large time gaps between trace 77 fields. Though this might be caused by transient communication 78 issues, they might also be caused by policy decisions or special 79 processing regarding the content of the message, authorization of 80 some identity on the message, or transitions between major software 81 components. Common examples include message quarantines (filters 82 that delay relaying or delivery of a message pending manual operator 83 action), pending content analysis, or mailing list servers that 84 impose moderation rules (mailing list owner action required regarding 85 mail from authors not subscribed to those lists). 87 This memo registers a new optional clause that can be used in trace 88 fields to indicate that a message entered such a special processing 89 queue for some period. This allows inspection of the trace 90 information to reveal that the cause for a time gap in trace fields 91 was an imposed delay rather than one caused by transient technical 92 difficulties. 94 The degree of granularity -- and therefore the degree of verbosity -- 95 will vary according to the needs of the operator making use of this 96 specification. In normal operation, the verbosity would likely be 97 limited to record only "unusual" transitions, such as to a 98 quarantine. 100 Somewhat greater granularity might also include transitions of 101 administrative responsibility, such as between an Mail Transfer Agent 102 (MTA) operator and a Mailing List Manager (MLM) operator. This could 103 be further enhanced to note some transitions that are interesting 104 only when other transitions have occurred, such as noting entry to 105 the outbound queue only when the message is originating from an 106 "interesting" source, such as an MLM, since an MLM can introduce 107 significant delay and it could be useful to know when it completed 108 its processing, as distinct from the subsequent processing by the 109 originating MTA. In circumstances needing very fine-grained trace 110 information, fields might be created to note all of these 111 "significant" network architecture transitions. 113 2. Keywords 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [KEYWORDS]. 119 3. New Trace Clause 121 This memo creates a new trace field clause, called "state", which can 122 be used to indicate the nature of a delay imposed on relaying of a 123 message toward its recipient(s). It is followed by a single keyword 124 that provides that detail. An Mail Transfer Agent (MTA) or other 125 handling agent that determines a message has entered a state other 126 than normal queueing of messages for relaying or delivery MAY 127 generate a trace field including one of these clauses. That is, the 128 presence of this clause on a trace field is an indication of the 129 entry of the message into that state; a later trace field added would 130 indicate its departure from that state. 132 Appropriate use of this mechanism does not include associating meta- 133 data with the message, such as categorizing the message (e.g., the 134 notions of "is spam" or "was 8-bit, converted to 7-bit"). 136 The following keywords are defined in this document; extensions may 137 define other registered keywords (see Section 5.2): 139 auth: The message entered a queue pending authentication of some 140 identifier in the message. 142 content: The message entered a queue pending content analysis, such 143 as scanning for spam or viruses. 145 convert: The message entered a queue pending content conversion for 146 passage through a gateway. 148 moderation: The message entered a hold pending mailing list 149 moderator action. 151 normal: The message is not in an administrative hold and is queued 152 for or is being handed off to the next handling agent (which may 153 be local delivery). This is the default interpretation when no 154 "state" clause is present. 156 other: The message entered a hold or queue for reasons not covered 157 by other keywords in this list, and not for transient technology 158 issues. 160 outbound: The message entered a queue for outbound relaying. This 161 is typically the last case added for a single host, and the next 162 Received field is expected to be added by some other host. 164 quarantine: The message entered a hold in an isolation queue pending 165 operator action for local policy reasons. 167 timed: The message entered a hold in order to meet a requested 168 delivery window. 170 The ABNF for this clause: 172 State = CFWS "state" FWS queue-state-keyword *( "/" 1*value ) 174 queue-state-keyword = ( reg-state-keyword / unreg-state-keyword ) 176 reg-state-keyword = ( "auth" / "content" / "convert" / 177 "moderation" / "normal" / "other" / 178 "quarantine" / "timed" / 179 additional-state-keyword ) 181 additional-state-keyword = unstructured 182 ; see "IANA Considerations" below 184 unreg-state-keyword = unstructured 185 ; from [MAIL] 187 "FWS" and "CFWS" are defined in [MAIL]; "value" is defined in [MIME]. 189 A transfer agent making use of this extension MAY also include header 190 field comments to provide additional information. 192 Use of this clause by transfer agents is OPTIONAL. 194 4. Discussion 196 Handling agents are not expected to implement or support all of 197 these. Indeed, recording trace information for all of the states 198 described above could make the header of a message inordinately 199 large. Rather, an agent is encouraged to apply state annotations 200 only when a message enters a handling queue where substantial delay 201 is possible, and especially when a handoff has occurred between two 202 different, independent agents. 204 For example, an MTA receiving a message, doing message 205 authentication, scanning for viruses and spam, and then putting it in 206 an outbound queue could add four Received fields denoting each of 207 these states. However, where they are all done as part of a single 208 system process, in a single pass, doing so would be considered 209 unusual (and extremely verbose). This method SHOULD NOT be applied 210 except when doing detailed analysis of a single component to identify 211 performance issues with those steps. 213 Rather, an agent that wishes to make a state annotation SHOULD add 214 only a single Received field including such annotation indicating (a) 215 the time of completion of its handling of the message via the date 216 portion of the field, and (b) the final disposition of that message 217 relative to that agent. For example, an MTA receiving a message that 218 performs various checks on the message before immediately handing it 219 off to a Mailing List Manager (MLM) would only record a "normal" 220 state, assuming it passes those checks. The MLM would then evaluate 221 the message and record its own state once it decides what the next 222 step will be for the handling of that message. 224 5. IANA Considerations 226 5.1. Mail Parameters Additional-registered-clauses Sub-Registry 228 This memo adds to the "Additional-registered-clauses" sub-registry of 229 the "Mail Parameters" registry, created by [SMTP], the following 230 entry: 232 Clause name: state 234 Description: Indicates special queue state entry 236 State Summary: state 238 Reference: [this memo] 240 5.2. Mail Parameters Registered-states Sub-Registry 242 The "Mail Parameters" registry at IANA is updated by the creation of 243 the "Registered-states" sub-registry to contain valid state keywords 244 for use with this specification. Updates to this registry are 245 governed by the Specification Required rules of [IANA]. 246 Registrations must include the following entries: 248 Name: The name of the state keyword being defined or updated 250 Description: A brief description of the keyword's meaning 252 Specification: The specification document that defines the queue 253 state being registered 255 Use: One of "current" (the state keyword is in current use), 256 "deprecated" (the state keyword is in use but not recommended for 257 new implementations), or "historic" (the state keyword is no 258 longer in substantial current use). 260 The initial registration set is as follows: 262 +------------+---------------------------+---------------+---------+ 263 | Name | Description | Specification | Use | 264 +------------+---------------------------+---------------+---------+ 265 | auth | Held for message | [this memo] | current | 266 | | authentication | | | 267 +------------+---------------------------+---------------+---------+ 268 | content | Held for message | [this memo] | current | 269 | | content analysis | | | 270 +------------+---------------------------+---------------+---------+ 271 | convert | Held for message | [this memo] | current | 272 | | content conversion | | | 273 +------------+---------------------------+---------------+---------+ 274 | moderation | Held for list moderation | [this memo] | current | 275 +------------+---------------------------+---------------+---------+ 276 | normal | Message is not being held | [this memo] | current | 277 | | other than to accommodate | | | 278 | | typical relaying delays | | | 279 +------------+---------------------------+---------------+---------+ 280 | other | Held for causes not | [this memo] | current | 281 | | covered by other | | | 282 | | registered state keywords | | | 283 +------------+---------------------------+---------------+---------+ 284 | quarantine | Held for operator action | [this memo] | current | 285 | | due to content analysis | | | 286 | | or local policy | | | 287 +------------+---------------------------+---------------+---------+ 288 | timed | Held to accommodate a | [this memo] | current | 289 | | specific requested | | | 290 | | delivery window | | | 291 +------------+---------------------------+---------------+---------+ 293 6. Security Considerations 295 The use of this trace information can reveal hints as to local policy 296 that was in effect at the time of message handling. 298 7. Normative References 300 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 301 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 302 May 2008. 304 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 308 October 2008. 310 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 311 Extensions (MIME) Part One: Format of Internet Message 312 Bodies", RFC 2045, November 1996. 314 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 315 October 2008. 317 Appendix A. Trace Field Examples 319 This section includes a sample of the new trace field clause in use. 321 A.1. Typical Delivery Without Obvious Delays 323 Typical message delivery 325 Received: from newyork.example.com 326 (newyork.example.com [192.0.2.250]) 327 by mail-router.example.net (8.11.6/8.11.6) 328 with ESMTP id i7PK0sH7021929 329 for ; 330 Fri, Feb 15 2002 17:19:22 -0800 331 Received: from internal.example.com 332 (internal.example.com [192.168.0.1]) 333 by newyork.example.com (8.11.6/8.11.6) 334 with ESMTP id i9MKZCRd064134 335 for ; 336 Fri, Feb 15 2002 17:19:08 -0800 338 Example 1: Typical message delivery with no appreciable handling 339 delays; only Received fields shown 341 A.2. Delivery With Moderation 343 Message delivery after moderation 345 Received: from newyork.example.com 346 (newyork.example.com [192.0.2.250]) 347 by mail-router.example.net (8.11.6/8.11.6) 348 with ESMTP id i7PK0sH7021929 349 for ; 350 Fri, Feb 15 2002 18:33:29 -0800 351 Received: from internal.example.com 352 (internal.example.com [192.168.0.1]) 353 by newyork.example.com (8.11.6/8.11.6) 354 with ESMTP id i9MKZCRd064134 355 for