7Internet Engineering Task Force (IETF) D. Crocker
8Request for Comments: 6729 Brandenburg InternetWorking
9Category: Standards Track M. Kucherawy
10ISSN: 2070-1721 Cloudmark, Inc.
14 Indicating Email Handling States in Trace Fields
18 This document registers a trace field clause for use in indicating
19 transitions between handling queues or processing states, including
20 enacting inter- and intra-host message transitions. This might
21 include message quarantining, mailing list moderation, timed
22 delivery, queuing for further analysis, content conversion, or other
23 similar causes, as well as optionally identifying normal handling
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc6729.
42 Copyright (c) 2012 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
58Crocker & Kucherawy Standards Track [Page 1]
60RFC 6729 Email Handling States September 2012
65 1. Introduction ....................................................2
66 2. Key Words .......................................................3
67 3. Trace Clause ....................................................3
68 4. Discussion ......................................................6
69 5. Granularity .....................................................6
70 6. IANA Considerations .............................................7
71 6.1. MAIL Parameters Additional-registered-clauses
72 Sub-Registry ...............................................7
73 6.2. MAIL Parameters Registered-states Sub-Registry .............7
74 7. Security Considerations .........................................9
75 8. References .....................................................10
76 8.1. Normative References ......................................10
77 8.2. Informative References ....................................10
78 Appendix A. Trace Field Examples .................................11
79 A.1. Typical Delivery without Obvious Extra Handling ...........11
80 A.2. Delivery with Moderation ..................................11
81 Appendix B. Acknowledgements .....................................12
85 [SMTP] defines the content of email message trace fields, commonly
86 the "Received" header field. These are typically used to record an
87 audit trail of the path a message follows from origin to destination,
88 with one such field added each time a message moves from one host to
91 Section 3.7.2 of that document mentions that "the most important use
92 of Received: lines is for debugging mail faults [...]".
94 There are some cases where there may be large time gaps between trace
95 fields. Though this might be caused by transient communication
96 issues, they might also be caused by policy decisions or special
97 processing regarding the content of the message, authorization of
98 some identity on the message, or transitions between major software
99 components. Common examples include message quarantines (filters
100 that cause a message to be held pending further evaluation or
101 delivery of a message pending manual operator action), pending
102 content analysis, or mailing list servers that impose moderation
103 rules (mailing list owner action required regarding mail from authors
104 not subscribed to those lists).
114Crocker & Kucherawy Standards Track [Page 2]
116RFC 6729 Email Handling States September 2012
119 This document registers a new optional clause that can be used in
120 trace fields to indicate that a message entered such a special
121 processing queue or state for some period. This allows inspection of
122 the trace information to reveal that the cause for a time gap in
123 trace fields was imposed by additional processing rather than one
124 caused by transient technical difficulties.
128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
130 document are to be interpreted as described in [KEYWORDS].
134 This specification defines a clause, called "state", which MAY be
135 used when creating a Received header field (see Section 4.4 of
136 [SMTP]) to indicate the nature of additional handling imposed on the
137 relaying of a message toward its recipient(s). It is followed by a
138 single keyword that provides that detail. A Mail Transfer Agent
139 (MTA) or other handling agent that determines a message has entered a
140 state other than normal queuing of messages for relaying or delivery
141 MAY generate a trace field including one of these clauses. That is,
142 the presence of this clause on a trace field is an indication of the
143 entry of the message into that state; a later trace field added would
144 indicate its departure from that state.
146 An MTA implementing this specification SHOULD add a Received field as
149 a. It determines that a special handling condition will occur and
150 places it into that condition; or
152 b. It determines that no special handling is required and prepares
153 it for relay to the next handling agent.
155 An MTA need not add a Received field indicating preparation for
156 normal handoff to the next handling agent if it has already added a
157 Received field for some other reason. Trace data added by the next
158 handling agent will imply the message's exit from the special
161 If a single MTA processes a message through multiple special handling
162 conditions, it MAY add a Received field for each distinct condition.
170Crocker & Kucherawy Standards Track [Page 3]
172RFC 6729 Email Handling States September 2012
175 For example, presume a message will be injected into MTA-1, then
176 travel to MTA-3 via MTA-2, and then MTA-3 will enact final delivery.
177 At MTA-2, it is determined that some action will be taken that will
178 cause the message to undergo some handling change that is outside of
179 typical message flow. In this case:
181 1. MTA-1 adds a typical Received field and relays it to MTA-2.
183 2. MTA-2 determines that the atypical handling will occur and adds a
184 Received field using the extension specified here.
186 3. On completion of the atypical handling, MTA-2 relays the message
189 4. MTA-3 adds a typical Received field and enacts final delivery of
192 Appropriate use of this mechanism does not include associating meta-
193 data with the message, such as categorizing the message (e.g., the
194 notions of "is spam" or "was 8-bit, converted to 7-bit"). Processing
195 agents also cannot reliably use this mechanism to determine anything
196 about the message content, since there is no guarantee that all
197 agents in the chain of handling made such annotations to allow
198 correct conclusions. The sole purpose here is to allow one to
199 determine the point(s) in the chain of custody of a message at which
200 the message was subjected to handling outside of normal message
203 The following state keywords are defined in this document; extensions
204 may define other registered keywords (see Section 6.2):
206 auth: The message entered a queue pending authentication of some
207 identifier in the message.
209 content: The message entered a queue pending content analysis, such
210 as scanning for spam or viruses.
212 convert: The message entered a queue pending content conversion.
214 moderation: The message entered a hold pending mailing list
217 normal: The message is not in an administrative hold and is queued
218 for or is being handed off to the next handling agent (which may
219 be local delivery). This is the default interpretation when no
220 "state" clause is present.
226Crocker & Kucherawy Standards Track [Page 4]
228RFC 6729 Email Handling States September 2012
231 other: The message entered a hold or queue for reasons not covered
232 by other keywords in this list and not for transient technology
235 outbound: The message entered a queue for outbound relaying. This
236 is typically the last case added for a single host, and the next
237 Received header field is expected to be added by some other host.
239 quarantine: The message entered a hold in an isolation queue pending
240 operator action for local policy reasons.
242 timed: The message entered a hold in order to meet a requested
243 delivery window, such as is defined in [FUTURERELEASE].
245 In Section 6, the "state" clause is added to the Additional-
246 Registered-Clauses IANA sub-registry. The ABNF for this clause is:
248 State = CFWS "state" FWS queue-state-keyword [ "/" value ]
250 queue-state-keyword = ( reg-state-keyword / unreg-state-keyword )
252 reg-state-keyword = ( "auth" / "content" / "convert" /
253 "moderation" / "normal" / "other" /
254 "outbound" / "quarantine" / "timed" /
255 additional-state-keyword )
257 additional-state-keyword = token
258 ; MUST be registered; see
259 ; "IANA Considerations" below
263 unreg-state-keyword = token
265 "FWS" and "CFWS" are defined in [MAIL]. "token" is defined in [MIME].
267 A transfer agent making use of this extension MAY also include header
268 field comments to provide additional information.
270 The "value" is available for providing additional labels as
271 explanation for the state transition. Examples could include:
273 o convert/unicode2ascii
275 o moderation/not-subscribed
282Crocker & Kucherawy Standards Track [Page 5]
284RFC 6729 Email Handling States September 2012
289 Handling agents are not expected to implement or support all of
290 these. Indeed, recording trace information for all of the states
291 described above could make the header of a message inordinately
292 large. Rather, an agent is encouraged to apply state annotations
293 when a message enters a handling queue where a significant condition
294 occurs or where significant additional processing or delay is
295 possible, and especially when a handoff has occurred between two
296 different, independent agents.
298 For example, an MTA receiving a message, doing message
299 authentication, scanning for viruses and spam, and then putting it in
300 an outbound queue could add four Received header fields denoting each
301 of these states. However, where they are all done as part of a
302 single system process, in a single pass, doing so would be considered
303 unusual (and extremely verbose). This method SHOULD NOT be applied
304 except when doing detailed analysis of a single component to identify
305 performance issues with those steps.
307 Rather, an agent that wishes to make a state annotation SHOULD add
308 only a single Received header field including such annotation, thus
309 indicating (a) the time of completion of its handling of the message
310 via the date portion of the field and (b) the final disposition of
311 that message relative to that agent. For example, an MTA receiving a
312 message that performs various checks on the message before
313 immediately handing it off to a Mailing List Manager (MLM) would only
314 record a "normal" state, assuming it passes those checks. The MLM
315 would then evaluate the message and record its own state once it
316 decides what the next step will be for the handling of that message.
320 The degree of granularity -- and therefore the degree of verbosity --
321 recorded through the use of this additional trace clause is likely to
322 vary depending on circumstances. It will typically be the case that
323 use of this clause will be limited to "unusual" transitions, such as
324 when a message requires additional scrutiny or other processing or
325 needs to be quarantined.
327 Somewhat greater granularity might also include transitions of
328 administrative responsibility, such as between a Mail Transfer Agent
329 (MTA) operator and a Mailing List Manager (MLM) operator. This could
330 be further enhanced to note some transitions that are interesting
331 only when other transitions have occurred, such as noting entry to
332 the outbound queue only when the message is originating from an
333 "interesting" source, like an MLM, since an MLM can introduce
334 significant changes to the message or delivery delay and it could be
338Crocker & Kucherawy Standards Track [Page 6]
340RFC 6729 Email Handling States September 2012
343 useful to know when it completed its processing, as distinct from the
344 subsequent processing by the originating MTA. In circumstances
345 needing very fine-grained trace information, fields might be created
346 to note all of these "significant" network architecture transitions.
348 One should note, however, when choosing higher levels of granularity,
349 that the Received header fields present on a message could be counted
350 by MTAs when trying to decide whether or not a message routing loop
351 is in effect. A message with an abundance of these might cause an
352 incorrect determination that the message is in a delivery loop,
353 causing it to be removed from the mail stream. See Section 6.3 of
354 [SMTP] for further discussion.
3566. IANA Considerations
3586.1. MAIL Parameters Additional-registered-clauses Sub-Registry
360 This document adds the following entry to the "Additional-registered-
361 clauses" sub-registry of the "MAIL Parameters" registry, created by
366 Description: Indicates entry into a special queue state
368 Syntax Summary: state <state-name>
3726.2. MAIL Parameters Registered-states Sub-Registry
374 The "MAIL Parameters" registry at IANA has been updated by the
375 creation of the "Registered-states" sub-registry to contain valid
376 state keywords for use with this specification. Updates to this
377 registry are governed by the First Come, First Served rules of [IANA]
378 for new registrations. Changes to the status of existing entries are
379 limited to the original registrant or IESG approval.
381 Discussion of all registry updates is encouraged via one or more IETF
382 mailing lists that typically cover email-related subjects prior to
383 approval of the change, as a way of documenting the work. The
384 ietf-smtp@ietf.org list is suggested.
386 Note that only registrations of queue state keywords are permitted.
387 The registry is not to be used for specifying secondary information
388 (i.e., the "value" part of the ABNF in Section 3).
394Crocker & Kucherawy Standards Track [Page 7]
396RFC 6729 Email Handling States September 2012
399 Registrations are to include the following entries:
401 Name: The name of the state keyword being defined or updated, which
402 conforms to the ABNF shown in Section 3.
404 Description: A brief description of the keyword's meaning.
406 Specification: The specification document that defines the queue
407 state being registered, or if no stable reference exists, a more
408 detailed explanation of the queue state than is in the
409 "Description", sufficient to allow interoperability.
411 Use: One of "current" (the state keyword is in current use),
412 "deprecated" (the state keyword is in use but not recommended for
413 new implementations), or "historic" (the state keyword is no
414 longer in substantial current use).
450Crocker & Kucherawy Standards Track [Page 8]
452RFC 6729 Email Handling States September 2012
455 The initial registration set is as follows:
457 +------------+------------------------+-----------------+---------+
458 | Name | Description | Specification | Use |
459 +------------+------------------------+-----------------+---------+
460 | auth | Held for message | [RFC6729] | current |
461 | | authentication | | |
462 +------------+------------------------+-----------------+---------+
463 | content | Held for message | [RFC6729] | current |
464 | | content analysis | | |
465 +------------+------------------------+-----------------+---------+
466 | convert | Held for message | [RFC6729] | current |
467 | | content conversion | | |
468 +------------+------------------------+-----------------+---------+
469 | moderation | Held for list | [RFC6729] | current |
471 +------------+------------------------+-----------------+---------+
472 | normal | Message is not being | [RFC6729] | current |
473 | | held other than to | | |
474 | | accommodate typical | | |
475 | | relaying handling | | |
476 +------------+------------------------+-----------------+---------+
477 | other | Held for causes not | [RFC6729] | current |
478 | | covered by other | | |
479 | | registered state | | |
481 +------------+------------------------+-----------------+---------+
482 | outbound | Message placed in | [RFC6729] | current |
483 | | outbound queue | | |
484 +------------+------------------------+-----------------+---------+
485 | quarantine | Held for operator | [RFC6729] | current |
486 | | action due to content | | |
487 | | analysis or local | | |
489 +------------+------------------------+-----------------+---------+
490 | timed | Held to accommodate a | [RFC6729] | current |
491 | | specific requested | | |
492 | | delivery window | | |
493 +------------+------------------------+-----------------+---------+
4957. Security Considerations
497 The use of this trace information can reveal hints as to local policy
498 that was in effect at the time of message handling.
500 Further discussion about trace field security can be found in Section
506Crocker & Kucherawy Standards Track [Page 9]
508RFC 6729 Email Handling States September 2012
5138.1. Normative References
515 [IANA] Narten, T. and H. Alvestrand, "Guidelines for
516 Writing an IANA Considerations Section in RFCs",
517 BCP 26, RFC 5226, May 2008.
519 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
520 Requirement Levels", BCP 14, RFC 2119, March 1997.
522 [MAIL] Resnick, P., Ed., "Internet Message Format",
523 RFC 5322, October 2008.
525 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet
526 Mail Extensions (MIME) Part One: Format of Internet
527 Message Bodies", RFC 2045, November 1996.
529 [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
530 RFC 5321, October 2008.
5328.2. Informative References
534 [FUTURERELEASE] White, G. and G. Vaudreuil, "SMTP Submission Service
535 Extension for Future Message Release", RFC 4865,
562Crocker & Kucherawy Standards Track [Page 10]
564RFC 6729 Email Handling States September 2012
567Appendix A. Trace Field Examples
569 This section includes a sample of the new trace field clause in use.
571A.1. Typical Delivery without Obvious Extra Handling
573 Typical message delivery
575 Received: from newyork.example.com
576 (newyork.example.com [192.0.2.250])
577 by mail-router.example.net (8.11.6/8.11.6)
578 with ESMTP id i7PK0sH7021929
579 for <recipient@example.net>;
580 Fri, Feb 15 2002 17:19:22 -0800
581 Received: from internal.example.com
582 (internal.example.com [192.168.0.1])
583 by newyork.example.com (8.11.6/8.11.6)
584 with ESMTP id i9MKZCRd064134
585 for <recipient@example.net>;
586 Fri, Feb 15 2002 17:19:08 -0800
588 Example 1: Typical message delivery with no appreciable extra
589 handling; only Received header fields shown
591A.2. Delivery with Moderation
593 Message delivery after moderation
595 Received: from newyork.example.com
596 (newyork.example.com [192.0.2.250])
597 by mail-router.example.net (8.11.6/8.11.6)
598 with ESMTP id i7PK0sH7021929
599 for <recipient@example.net>;
600 Fri, Feb 15 2002 18:33:29 -0800
601 Received: from internal.example.com
602 (internal.example.com [192.168.0.1])
603 by newyork.example.com (8.11.6/8.11.6)
604 with ESMTP id i9MKZCRd064134
605 for <secret-list@example.com>
606 state moderation (sender not subscribed);
607 Fri, Feb 15 2002 17:19:08 -0800
609 Example 2: Message held for moderation; only Received header fields
612 The message passed from internal.example.com to newyork.example.com
613 intended for a mailing list hosted at the latter. For list
614 administrative reasons, the message is held there for moderation. It
618Crocker & Kucherawy Standards Track [Page 11]
620RFC 6729 Email Handling States September 2012
623 is finally released over an hour later and passed to the next host.
624 A comment after the state expression indicates the actual cause for
625 the administrative hold.
627Appendix B. Acknowledgements
629 The authors wish to acknowledge the following for their reviews and
630 constructive criticisms of this proposal: Tony Finch, Ned Freed, Carl
631 S. Gutenkunst, John Levine, Bill McQuillan, S. Moonesamy, Alexey
632 Melnikov, Robert A. Rosenberg, Hector Santos, Rolf Sonneveld, and
638 Brandenburg InternetWorking
643 Phone: +1.408.246.8253
644 EMail: dcrocker@bbiw.net
650 128 King St., 2nd Floor
651 San Francisco, CA 94107
654 EMail: superuser@gmail.com
674Crocker & Kucherawy Standards Track [Page 12]