draft-ietf-appsawg-received-state-00.txt   draft-ietf-appsawg-received-state-01.txt 
Individual submission D. Crocker Individual submission D. Crocker
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Intended status: Standards Track M. Kucherawy Intended status: Standards Track M. Kucherawy
Expires: November 4, 2012 Cloudmark, Inc. Expires: November 19, 2012 Cloudmark, Inc.
May 3, 2012 May 18, 2012
Indicating Email Handling States in Trace Fields Indicating Email Handling States in Trace Fields
draft-ietf-appsawg-received-state-00 draft-ietf-appsawg-received-state-01
Abstract Abstract
This memo registers a trace field clause for use in indicating This memo registers a trace field clause for use in indicating
transitions between handling queues or processing states, including transitions between handling queues or processing states, including
enacting inter- and intra-host message transitions. This might enacting inter- and intra-host message transitions. This might
include message quarantining, mailing list moderation, timed include message quarantining, mailing list moderation, timed
delivery, queueing for further analysis, or other similar causes. delivery, queueing for further analysis, content conversion, or other
similar causes, as well as optionally identifying normal handling
queues.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2012. This Internet-Draft will expire on November 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Trace Clause . . . . . . . . . . . . . . . . . . . . . . . 3 3. New Trace Clause . . . . . . . . . . . . . . . . . . . . . . . 3
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Granularity . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Granularity . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. Mail Parameters Additional-registered-clauses 6.1. Mail Parameters Additional-registered-clauses
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 6 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Mail Parameters Registered-states Sub-Registry . . . . . . 7 6.2. Mail Parameters Registered-states Sub-Registry . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Trace Field Examples . . . . . . . . . . . . . . . . 9 Appendix A. Trace Field Examples . . . . . . . . . . . . . . . . 9
A.1. Typical Delivery Without Obvious Delays . . . . . . . . . 9 A.1. Typical Delivery Without Obvious Delays . . . . . . . . . 9
A.2. Delivery With Moderation . . . . . . . . . . . . . . . . . 10 A.2. Delivery With Moderation . . . . . . . . . . . . . . . . . 10
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
[SMTP] defines the content of email message trace fields, commonly [SMTP] defines the content of email message trace fields, commonly
the "Received" field. These are typically used to record an audit the "Received" field. These are typically used to record an audit
trail of the path a message follows from origin to destination, with trail of the path a message follows from origin to destination, with
skipping to change at page 3, line 34 skipping to change at page 3, line 34
impose moderation rules (mailing list owner action required regarding impose moderation rules (mailing list owner action required regarding
mail from authors not subscribed to those lists). mail from authors not subscribed to those lists).
This memo registers a new optional clause that can be used in trace This memo registers a new optional clause that can be used in trace
fields to indicate that a message entered such a special processing fields to indicate that a message entered such a special processing
queue or state for some period. This allows inspection of the trace queue or state for some period. This allows inspection of the trace
information to reveal that the cause for a time gap in trace fields information to reveal that the cause for a time gap in trace fields
was an imposed delay rather than one caused by transient technical was an imposed delay rather than one caused by transient technical
difficulties. difficulties.
2. Keywords 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
3. New Trace Clause 3. New Trace Clause
This memo creates a new trace field clause, called "state", which can This memo creates a new trace field clause, called "state", which can
be used to indicate the nature of a delay imposed on relaying of a be used to indicate the nature of a delay imposed on relaying of a
message toward its recipient(s). It is followed by a single keyword message toward its recipient(s). It is followed by a single keyword
skipping to change at page 4, line 18 skipping to change at page 4, line 18
The following state keywords are defined in this document; extensions The following state keywords are defined in this document; extensions
may define other registered keywords (see Section 6.2): may define other registered keywords (see Section 6.2):
auth: The message entered a queue pending authentication of some auth: The message entered a queue pending authentication of some
identifier in the message. identifier in the message.
content: The message entered a queue pending content analysis, such content: The message entered a queue pending content analysis, such
as scanning for spam or viruses. as scanning for spam or viruses.
convert: The message entered a queue pending content conversion for convert: The message entered a queue pending content conversion.
passage through a gateway.
moderation: The message entered a hold pending mailing list moderation: The message entered a hold pending mailing list
moderator action. moderator action.
normal: The message is not in an administrative hold and is queued normal: The message is not in an administrative hold and is queued
for or is being handed off to the next handling agent (which may for or is being handed off to the next handling agent (which may
be local delivery). This is the default interpretation when no be local delivery). This is the default interpretation when no
"state" clause is present. "state" clause is present.
other: The message entered a hold or queue for reasons not covered other: The message entered a hold or queue for reasons not covered
skipping to change at page 4, line 41 skipping to change at page 4, line 40
issues. issues.
outbound: The message entered a queue for outbound relaying. This outbound: The message entered a queue for outbound relaying. This
is typically the last case added for a single host, and the next is typically the last case added for a single host, and the next
Received field is expected to be added by some other host. Received field is expected to be added by some other host.
quarantine: The message entered a hold in an isolation queue pending quarantine: The message entered a hold in an isolation queue pending
operator action for local policy reasons. operator action for local policy reasons.
timed: The message entered a hold in order to meet a requested timed: The message entered a hold in order to meet a requested
delivery window. delivery window, such as is defined in [FUTURERELEASE].
The ABNF for this clause: The ABNF for this clause:
State = CFWS "state" FWS queue-state-keyword *( "/" 1*value ) State = CFWS "state" FWS queue-state-keyword *( "/" 1*value )
queue-state-keyword = ( reg-state-keyword / unreg-state-keyword ) queue-state-keyword = ( reg-state-keyword / unreg-state-keyword )
reg-state-keyword = ( "auth" / "content" / "convert" / reg-state-keyword = ( "auth" / "content" / "convert" /
"moderation" / "normal" / "other" / "moderation" / "normal" / "other" /
"quarantine" / "timed" / "outbound" / "quarantine" / "timed" /
additional-state-keyword ) additional-state-keyword )
additional-state-keyword = unstructured additional-state-keyword = unstructured
; see "IANA Considerations" below ; see "IANA Considerations" below
unreg-state-keyword = unstructured unreg-state-keyword = unstructured
; from [MAIL] ; from [MAIL]
"FWS" and "CFWS" are defined in [MAIL]; "value" is defined in [MIME]. "FWS" and "CFWS" are defined in [MAIL]; "value" is defined in [MIME].
skipping to change at page 5, line 33 skipping to change at page 5, line 33
field comments to provide additional information. field comments to provide additional information.
Use of this clause by transfer agents is OPTIONAL. Use of this clause by transfer agents is OPTIONAL.
4. Discussion 4. Discussion
Handling agents are not expected to implement or support all of Handling agents are not expected to implement or support all of
these. Indeed, recording trace information for all of the states these. Indeed, recording trace information for all of the states
described above could make the header of a message inordinately described above could make the header of a message inordinately
large. Rather, an agent is encouraged to apply state annotations large. Rather, an agent is encouraged to apply state annotations
only when a message enters a handling queue where substantial delay when a message enters a handling queue where substantial delay is
is possible, and especially when a handoff has occurred between two possible, and especially when a handoff has occurred between two
different, independent agents. different, independent agents.
For example, an MTA receiving a message, doing message For example, an MTA receiving a message, doing message
authentication, scanning for viruses and spam, and then putting it in authentication, scanning for viruses and spam, and then putting it in
an outbound queue could add four Received fields denoting each of an outbound queue could add four Received fields denoting each of
these states. However, where they are all done as part of a single these states. However, where they are all done as part of a single
system process, in a single pass, doing so would be considered system process, in a single pass, doing so would be considered
unusual (and extremely verbose). This method SHOULD NOT be applied unusual (and extremely verbose). This method SHOULD NOT be applied
except when doing detailed analysis of a single component to identify except when doing detailed analysis of a single component to identify
performance issues with those steps. performance issues with those steps.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
that message relative to that agent. For example, an MTA receiving a that message relative to that agent. For example, an MTA receiving a
message that performs various checks on the message before message that performs various checks on the message before
immediately handing it off to a Mailing List Manager (MLM) would only immediately handing it off to a Mailing List Manager (MLM) would only
record a "normal" state, assuming it passes those checks. The MLM record a "normal" state, assuming it passes those checks. The MLM
would then evaluate the message and record its own state once it would then evaluate the message and record its own state once it
decides what the next step will be for the handling of that message. decides what the next step will be for the handling of that message.
5. Granularity 5. Granularity
The degree of granularity -- and therefore the degree of verbosity -- The degree of granularity -- and therefore the degree of verbosity --
recorded through the use of this additional trace clause will vary recorded through the use of this additional trace clause is likely to
according to the needs of the operator making use of this vary depending on circumstances. It will typically be the case that
specification. In normal operation, the verbosity would likely be use of this clause will be limited to "unusual" transitions, such as
limited to record only "unusual" transitions, such as to a when a message requires additional scrutiny or other processing, or
quarantine. needs to be quarantined.
Somewhat greater granularity might also include transitions of Somewhat greater granularity might also include transitions of
administrative responsibility, such as between an Mail Transfer Agent administrative responsibility, such as between an Mail Transfer Agent
(MTA) operator and a Mailing List Manager (MLM) operator. This could (MTA) operator and a Mailing List Manager (MLM) operator. This could
be further enhanced to note some transitions that are interesting be further enhanced to note some transitions that are interesting
only when other transitions have occurred, such as noting entry to only when other transitions have occurred, such as noting entry to
the outbound queue only when the message is originating from an the outbound queue only when the message is originating from an
"interesting" source, like an MLM, since an MLM can introduce "interesting" source, like an MLM, since an MLM can introduce
significant delay and it could be useful to know when it completed significant delay and it could be useful to know when it completed
its processing, as distinct from the subsequent processing by the its processing, as distinct from the subsequent processing by the
skipping to change at page 8, line 27 skipping to change at page 8, line 27
| moderation | Held for list moderation | [this memo] | current | | moderation | Held for list moderation | [this memo] | current |
+------------+---------------------------+---------------+---------+ +------------+---------------------------+---------------+---------+
| normal | Message is not being held | [this memo] | current | | normal | Message is not being held | [this memo] | current |
| | other than to accommodate | | | | | other than to accommodate | | |
| | typical relaying delays | | | | | typical relaying delays | | |
+------------+---------------------------+---------------+---------+ +------------+---------------------------+---------------+---------+
| other | Held for causes not | [this memo] | current | | other | Held for causes not | [this memo] | current |
| | covered by other | | | | | covered by other | | |
| | registered state keywords | | | | | registered state keywords | | |
+------------+---------------------------+---------------+---------+ +------------+---------------------------+---------------+---------+
| outbound | Message placed in | [this memo] | current |
| | outbound queue | | |
+------------+---------------------------+---------------+---------+
| quarantine | Held for operator action | [this memo] | current | | quarantine | Held for operator action | [this memo] | current |
| | due to content analysis | | | | | due to content analysis | | |
| | or local policy | | | | | or local policy | | |
+------------+---------------------------+---------------+---------+ +------------+---------------------------+---------------+---------+
| timed | Held to accommodate a | [this memo] | current | | timed | Held to accommodate a | [this memo] | current |
| | specific requested | | | | | specific requested | | |
| | delivery window | | | | | delivery window | | |
+------------+---------------------------+---------------+---------+ +------------+---------------------------+---------------+---------+
7. Security Considerations 7. Security Considerations
The use of this trace information can reveal hints as to local policy The use of this trace information can reveal hints as to local policy
that was in effect at the time of message handling. that was in effect at the time of message handling.
8. Normative References 8. References
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 8.1. Normative References
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [IANA] Narten, T. and H. Alvestrand, "Guidelines for
Requirement Levels", BCP 14, RFC 2119, March 1997. Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
October 2008. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
Extensions (MIME) Part One: Format of Internet Message October 2008.
Bodies", RFC 2045, November 1996.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet
October 2008. Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol",
RFC 5321, October 2008.
8.2. Informative References
[FUTURERELEASE] White, G. and G. Vaudreuil, "SMTP Submission Service
Extension for Future Message Release", RFC 4865,
May 2007.
Appendix A. Trace Field Examples Appendix A. Trace Field Examples
This section includes a sample of the new trace field clause in use. This section includes a sample of the new trace field clause in use.
A.1. Typical Delivery Without Obvious Delays A.1. Typical Delivery Without Obvious Delays
Typical message delivery Typical message delivery
Received: from newyork.example.com Received: from newyork.example.com
skipping to change at page 10, line 19 skipping to change at page 10, line 19
Received: from newyork.example.com Received: from newyork.example.com
(newyork.example.com [192.0.2.250]) (newyork.example.com [192.0.2.250])
by mail-router.example.net (8.11.6/8.11.6) by mail-router.example.net (8.11.6/8.11.6)
with ESMTP id i7PK0sH7021929 with ESMTP id i7PK0sH7021929
for <recipient@example.net>; for <recipient@example.net>;
Fri, Feb 15 2002 18:33:29 -0800 Fri, Feb 15 2002 18:33:29 -0800
Received: from internal.example.com Received: from internal.example.com
(internal.example.com [192.168.0.1]) (internal.example.com [192.168.0.1])
by newyork.example.com (8.11.6/8.11.6) by newyork.example.com (8.11.6/8.11.6)
with ESMTP id i9MKZCRd064134 with ESMTP id i9MKZCRd064134
for <secret-list@example.com> for <secret-list@example.com>
state moderation (sender not subscribed); state moderation (sender not subscribed);
Fri, Feb 15 2002 17:19:08 -0800 Fri, Feb 15 2002 17:19:08 -0800
Example 2: Message held for moderation; only Received fields shown Example 2: Message held for moderation; only Received fields shown
The message passed from internal.example.com to newyork.example.com The message passed from internal.example.com to newyork.example.com
intended for a mailing list hosted at the latter. For list intended for a mailing list hosted at the latter. For list
administrative reasons, the message is held there for moderation. It administrative reasons, the message is held there for moderation. It
is finally released over an hour later and passed to the next host. is finally released over an hour later and passed to the next host.
A comment after the state expression indicates the actual cause for A comment after the state expression indicates the actual cause for
the administrative hold. the administrative hold.
Appendix B. Acknowledgements Appendix B. Acknowledgements
The authors wish to acknowledge the following for their reviews and The authors wish to acknowledge the following for their reviews and
constructive criticisms of this proposal: Tony Finch, Carl S. constructive criticisms of this proposal: Tony Finch, Ned Freed, Carl
Gutenkunst, John Levine, Bill McQuillan, Alexey Melnikov, Robert A. S. Gutenkunst, John Levine, Bill McQuillan, Alexey Melnikov, Robert
Rosenberg, Hector Santos, Rolf Sonneveld, and Mykyta Yevstifeyev. A. Rosenberg, Hector Santos, Rolf Sonneveld, and Mykyta Yevstifeyev.
Authors' Addresses Authors' Addresses
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale 94086 Sunnyvale 94086
USA USA
Phone: +1.408.246.8253 Phone: +1.408.246.8253
 End of changes. 21 change blocks. 
36 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/