draft-ietf-appsawg-received-state-01.txt   draft-ietf-appsawg-received-state-02.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 19, 2012 Cloudmark, Inc. Expires: December 23, 2012 Cloudmark, Inc.
May 18, 2012 June 21, 2012
Indicating Email Handling States in Trace Fields Indicating Email Handling States in Trace Fields
draft-ietf-appsawg-received-state-01 draft-ietf-appsawg-received-state-02
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, content conversion, or other delivery, queueing for further analysis, content conversion, or other
similar causes, as well as optionally identifying normal handling similar causes, as well as optionally identifying normal handling
queues. queues.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 19, 2012. This Internet-Draft will expire on December 23, 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 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" header field. These are typically used to record an
trail of the path a message follows from origin to destination, with audit trail of the path a message follows from origin to destination,
one such field added each time a message moves from one host to the with one such field added each time a message moves from one host to
next. the next.
Section 3.7.2 of that memo mentions that "the most important use of Section 3.7.2 of that memo mentions that "the most important use of
of Received: lines is for debugging mail faults [...]". of Received: lines is for debugging mail faults [...]".
There are some cases where there may be large time gaps between trace There are some cases where there may be large time gaps between trace
fields. Though this might be caused by transient communication fields. Though this might be caused by transient communication
issues, they might also be caused by policy decisions or special issues, they might also be caused by policy decisions or special
processing regarding the content of the message, authorization of processing regarding the content of the message, authorization of
some identity on the message, or transitions between major software some identity on the message, or transitions between major software
components. Common examples include message quarantines (filters components. Common examples include message quarantines (filters
skipping to change at page 3, line 43 skipping to change at page 3, line 43
2. Key Words 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 within Received header fields (see Section 4.4 of [SMTP]) to
message toward its recipient(s). It is followed by a single keyword indicate the nature of a delay imposed on relaying of a message
that provides that detail. A Mail Transfer Agent (MTA) or other toward its recipient(s). It is followed by a single keyword that
handling agent that determines a message has entered a state other provides that detail. A Mail Transfer Agent (MTA) or other handling
than normal queueing of messages for relaying or delivery MAY agent that determines a message has entered a state other than normal
generate a trace field including one of these clauses. That is, the queueing of messages for relaying or delivery MAY generate a trace
presence of this clause on a trace field is an indication of the field including one of these clauses. That is, the presence of this
entry of the message into that state; a later trace field added would clause on a trace field is an indication of the entry of the message
indicate its departure from that state. into that state; a later trace field added would indicate its
departure from that state.
Appropriate use of this mechanism does not include associating meta- Appropriate use of this mechanism does not include associating meta-
data with the message, such as categorizing the message (e.g., the data with the message, such as categorizing the message (e.g., the
notions of "is spam" or "was 8-bit, converted to 7-bit"). notions of "is spam" or "was 8-bit, converted to 7-bit").
Use of this clause by transfer agents is OPTIONAL.
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. convert: The message entered a queue pending content conversion.
skipping to change at page 4, line 34 skipping to change at page 4, line 36
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
by other keywords in this list, and not for transient technology by other keywords in this list, and not for transient technology
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 header 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, such as is defined in [FUTURERELEASE]. 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 *( "/" 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" /
"outbound" / "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
value = unstructured
unreg-state-keyword = unstructured unreg-state-keyword = unstructured
; from [MAIL]
"FWS" and "CFWS" are defined in [MAIL]; "value" is defined in [MIME]. "unstructured", "FWS" and "CFWS" are defined in [MAIL]
A transfer agent making use of this extension MAY also include header A transfer agent making use of this extension MAY also include header
field comments to provide additional information. field comments to provide additional information.
Use of this clause by transfer agents is OPTIONAL. The "value" is available for providing additional labels as
explanation for the state transition. Examples could include:
o convert/unicode2ascii
o moderation/not-subscribed
o quarantine/spam
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
when a message enters a handling queue where substantial delay is when a message enters a handling queue where substantial delay 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 header fields denoting each
these states. However, where they are all done as part of a single of these states. However, where they are all done as part of a
system process, in a single pass, doing so would be considered single 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.
Rather, an agent that wishes to make a state annotation SHOULD add Rather, an agent that wishes to make a state annotation SHOULD add
only a single Received field including such annotation, thus only a single Received header field including such annotation, thus
indicating (a) the time of completion of its handling of the message indicating (a) the time of completion of its handling of the message
via the date portion of the field, and (b) the final disposition of via the date portion of the field, and (b) the final disposition of
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
skipping to change at page 6, line 31 skipping to change at page 6, line 39
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
originating MTA. In circumstances needing very fine-grained trace originating MTA. In circumstances needing very fine-grained trace
information, fields might be created to note all of these information, fields might be created to note all of these
"significant" network architecture transitions. "significant" network architecture transitions.
One should note, however, when choosing higher levels of granularity, One should note, however, when choosing higher levels of granularity,
that the Received fields present on a message could be counted by that the Received header fields present on a message could be counted
MTAs when trying to decide whether or not a message routing loop is by MTAs when trying to decide whether or not a message routing loop
in effect. A message with an abundance of these might cause an is in effect. A message with an abundance of these might cause an
incorrect determination that the message is in a delivery loop, incorrect determination that the message is in a delivery loop,
causing it to be removed from the mail stream. See Section 6.3 of causing it to be removed from the mail stream. See Section 6.3 of
[SMTP] for further discussion. [SMTP] for further discussion.
6. IANA Considerations 6. IANA Considerations
6.1. Mail Parameters Additional-registered-clauses Sub-Registry 6.1. Mail Parameters Additional-registered-clauses Sub-Registry
This memo adds to the "Additional-registered-clauses" sub-registry of This memo adds to the "Additional-registered-clauses" sub-registry of
the "Mail Parameters" registry, created by [SMTP], the following the "Mail Parameters" registry, created by [SMTP], the following
skipping to change at page 7, line 4 skipping to change at page 7, line 8
6.1. Mail Parameters Additional-registered-clauses Sub-Registry 6.1. Mail Parameters Additional-registered-clauses Sub-Registry
This memo adds to the "Additional-registered-clauses" sub-registry of This memo adds to the "Additional-registered-clauses" sub-registry of
the "Mail Parameters" registry, created by [SMTP], the following the "Mail Parameters" registry, created by [SMTP], the following
entry: entry:
Clause name: state Clause name: state
Description: Indicates entry into a special queue state Description: Indicates entry into a special queue state
Syntax Summary: state <state-name> Syntax Summary: state <state-name>
Reference: [this memo] Reference: [this memo]
6.2. Mail Parameters Registered-states Sub-Registry 6.2. Mail Parameters Registered-states Sub-Registry
The "Mail Parameters" registry at IANA is updated by the creation of The "Mail Parameters" registry at IANA is updated by the creation of
the "Registered-states" sub-registry to contain valid state keywords the "Registered-states" sub-registry to contain valid state keywords
for use with this specification. Updates to this registry are for use with this specification. Updates to this registry are
governed by the Specification Required rules of [IANA]. governed by the First Come First Served rules of [IANA] for new
registrations. Changes to the status of existing entries are limited
to the original registrant or IESG approval.
Discussion of all registry updates is encouraged via one or more IETF
mailing lists that typically cover email-related subjects prior to
approval of the change, as a way of documenting the work.
Note that only registrations of queue state keywords are permitted.
The registry is not to be used for specifying secondary information
(i.e., the "value" part of the ABNF in Section 3).
Registrations must include the following entries: Registrations must include the following entries:
Name: The name of the state keyword being defined or updated Name: The name of the state keyword being defined or updated, which
conforms to the ABNF shown in Section 3
Description: A brief description of the keyword's meaning Description: A brief description of the keyword's meaning
Specification: The specification document that defines the queue Specification: The specification document that defines the queue
state being registered state being registered
Use: One of "current" (the state keyword is in current use), Use: One of "current" (the state keyword is in current use),
"deprecated" (the state keyword is in use but not recommended for "deprecated" (the state keyword is in use but not recommended for
new implementations), or "historic" (the state keyword is no new implementations), or "historic" (the state keyword is no
longer in substantial current use). longer in substantial current use).
skipping to change at page 8, line 44 skipping to change at page 8, line 44
| 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.
Further discussion about trace field security can be found in Section
7.6 of [SMTP].
8. References 8. References
8.1. Normative References 8.1. Normative References
[IANA] Narten, T. and H. Alvestrand, "Guidelines for [IANA] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008. BCP 26, RFC 5226, May 2008.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
RFC 5321, October 2008. RFC 5321, October 2008.
8.2. Informative References 8.2. Informative References
[FUTURERELEASE] White, G. and G. Vaudreuil, "SMTP Submission Service [FUTURERELEASE] White, G. and G. Vaudreuil, "SMTP Submission Service
Extension for Future Message Release", RFC 4865, Extension for Future Message Release", RFC 4865,
May 2007. May 2007.
Appendix A. Trace Field Examples Appendix A. Trace Field Examples
skipping to change at page 9, line 44 skipping to change at page 9, line 43
for <recipient@example.net>; for <recipient@example.net>;
Fri, Feb 15 2002 17:19:22 -0800 Fri, Feb 15 2002 17:19:22 -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 <recipient@example.net>; for <recipient@example.net>;
Fri, Feb 15 2002 17:19:08 -0800 Fri, Feb 15 2002 17:19:08 -0800
Example 1: Typical message delivery with no appreciable handling Example 1: Typical message delivery with no appreciable handling
delays; only Received fields shown delays; only Received header fields shown
A.2. Delivery With Moderation A.2. Delivery With Moderation
Message delivery after moderation Message delivery after moderation
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 header 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, Ned Freed, Carl constructive criticisms of this proposal: Tony Finch, Ned Freed, Carl
S. Gutenkunst, John Levine, Bill McQuillan, Alexey Melnikov, Robert S. Gutenkunst, John Levine, Bill McQuillan, S. Moonesamy, Alexey
A. Rosenberg, Hector Santos, Rolf Sonneveld, and Mykyta Yevstifeyev. Melnikov, Robert 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
EMail: dcrocker@bbiw.net EMail: dcrocker@bbiw.net
URI: http://bbiw.net URI: http://bbiw.net
Murray S. Kucherawy Murray S. Kucherawy
Cloudmark, Inc. Cloudmark, Inc.
128 King St., 2nd Floor 128 King St., 2nd Floor
San Francisco, CA 94107 San Francisco, CA 94107
US US
Phone: +1 415 946 3800 EMail: superuser@gmail.com
EMail: msk@cloudmark.com
 End of changes. 24 change blocks. 
39 lines changed or deleted 64 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/