draft-ietf-appsawg-received-state-03.txt   draft-ietf-appsawg-received-state-04.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: December 25, 2012 Cloudmark, Inc. Expires: December 29, 2012 Cloudmark, Inc.
June 23, 2012 June 27, 2012
Indicating Email Handling States in Trace Fields Indicating Email Handling States in Trace Fields
draft-ietf-appsawg-received-state-03 draft-ietf-appsawg-received-state-04
Abstract Abstract
This memo registers a trace field clause for use in indicating This document 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.
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
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 December 25, 2012. This Internet-Draft will expire on December 29, 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. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New Trace Clause . . . . . . . . . . . . . . . . . . . . . . . 3 3. Trace Clause . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Granularity . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Granularity . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. Mail Parameters Additional-registered-clauses 6.1. Mail Parameters Additional-registered-clauses
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 6 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Mail Parameters Registered-states Sub-Registry . . . . . . 7 6.2. Mail Parameters Registered-states Sub-Registry . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Trace Field Examples . . . . . . . . . . . . . . . . 9 Appendix A. Trace Field Examples . . . . . . . . . . . . . . . . 10
A.1. Typical Delivery Without Obvious Delays . . . . . . . . . 9 A.1. Typical Delivery Without Obvious Extra Handling . . . . . 11
A.2. Delivery With Moderation . . . . . . . . . . . . . . . . . 10 A.2. Delivery With Moderation . . . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12
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" header field. These are typically used to record an the "Received" header field. These are typically used to record an
audit trail of the path a message follows from origin to destination, audit trail of the path a message follows from origin to destination,
with one such field added each time a message moves from one host to with one such field added each time a message moves from one host to
the next. the next.
Section 3.7.2 of that memo mentions that "the most important use of Section 3.7.2 of that document mentions that "the most important use
of Received: lines is for debugging mail faults [...]". of 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
that delay relaying or delivery of a message pending manual operator that cause a message to be held pending further evaluation, or
action), pending content analysis, or mailing list servers that delivery of a message pending manual operator action), pending
impose moderation rules (mailing list owner action required regarding content analysis, or mailing list servers that impose moderation
mail from authors not subscribed to those lists). rules (mailing list owner action required regarding mail from authors
not subscribed to those lists).
This memo registers a new optional clause that can be used in trace This document registers a new optional clause that can be used in
fields to indicate that a message entered such a special processing trace fields to indicate that a message entered such a special
queue or state for some period. This allows inspection of the trace processing queue or state for some period. This allows inspection of
information to reveal that the cause for a time gap in trace fields the trace information to reveal that the cause for a time gap in
was an imposed delay rather than one caused by transient technical trace fields was imposed by additional processing rather than one
difficulties. caused by transient technical difficulties.
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. Trace Clause
This memo creates a new trace field clause, called "state", which can This specification defines a clause, called "state", which MAY be
be used within Received header fields (see Section 4.4 of [SMTP]) to used when creating a Recevied header field (see Section 4.4 of
indicate the nature of a delay imposed on relaying of a message [SMTP]) to indicate the nature of additional handling imposed on the
toward its recipient(s). It is followed by a single keyword that relaying of a message toward its recipient(s). It is followed by a
provides that detail. A Mail Transfer Agent (MTA) or other handling single keyword that provides that detail. A Mail Transfer Agent
agent that determines a message has entered a state other than normal (MTA) or other handling agent that determines a message has entered a
queueing of messages for relaying or delivery MAY generate a trace state other than normal queueing of messages for relaying or delivery
field including one of these clauses. That is, the presence of this MAY generate a trace field including one of these clauses. That is,
clause on a trace field is an indication of the entry of the message the presence of this clause on a trace field is an indication of the
into that state; a later trace field added would indicate its entry of the message into that state; a later trace field added would
departure from that state. indicate its departure from that state.
An MTA implementing this specification SHOULD add a Received field as
described whenever:
a. It determines that a special handling condition will occur, and
places it into that condition; or
b. It determines that no special handling is required, and prepares
it for relay to the next handling agent.
An MTA need not add a Received field indicating preparation for
normal handoff to the next handling agent if it has already added a
Received field for some other reason. Trace data added by the next
handling agent will imply the message's exit from the special
handling condition.
If a single MTA processes a message through multiple special handling
conditions, it MAY add a Received for each distinct condition.
For example: Presume a message will be injected into MTA-1, then
travel to MTA-3 via MTA-2, and then MTA-3 enacts final delivery. At
MTA-2, it is determined that some action will be taken that will
cause the message to undergo some handling change that is outside of
typical message flow. In this case:
1. MTA-1 adds a typical Received field and relays it to MTA-2
2. MTA-2 determines that the atypical handling will occur and adds a
Received field using the extension specified here
3. On completion of the atypical handling, MTA-2 relays the message
to MTA-3
4. MTA-3 adds a typical Received field and enacts final delivery of
the message
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"). Processing
agents also cannot reliably use this mechanism to determine anything
Use of this clause by transfer agents is OPTIONAL. about the message content, since there is no guarantee that all
agents in the chain of handling made such annotations allowing
correct conclusions. The sole purpose here is to allow one to
determine the point(s) in the chain of custody of a message at which
the message was subjected to handling outside of normal message
routing and queueing.
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.
skipping to change at page 5, line 5 skipping to change at page 6, line 5
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 "state" clause is added in Section 6 to the Additional- The "state" clause is added in Section 6 to the Additional-
Registered-Clauses IANA sub-registry. The ABNF for this clause is: Registered-Clauses IANA sub-registry. The ABNF for this clause is:
State = CFWS "state" FWS queue-state-keyword *( "/" 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 = token
; see "IANA Considerations" below ; MUST be registered; see
; "IANA Considerations" below
value = token value = token
unreg-state-keyword = token unreg-state-keyword = token
"FWS" and "CFWS" are defined in [MAIL]. "token" is defined in [MIME]. "FWS" and "CFWS" are defined in [MAIL]. "token" is defined in [MIME].
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.
skipping to change at page 5, line 41 skipping to change at page 6, line 42
o moderation/not-subscribed o moderation/not-subscribed
o quarantine/spam 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 a significant condition
occurs or where significant additional processing or 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 header fields denoting each an outbound queue could add four Received header fields denoting each
of these states. However, where they are all done as part of a of these states. However, where they are all done as part of a
single 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
skipping to change at page 6, line 32 skipping to change at page 7, line 34
when a message requires additional scrutiny or other processing, or when a message requires additional scrutiny or other processing, or
needs to be quarantined. 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 changes to the message or delivery delay and it could be
its processing, as distinct from the subsequent processing by the useful to know when it completed its processing, as distinct from the
originating MTA. In circumstances needing very fine-grained trace subsequent processing by the originating MTA. In circumstances
information, fields might be created to note all of these needing very fine-grained trace information, fields might be created
"significant" network architecture transitions. to note all of these "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 header fields present on a message could be counted that the Received header fields present on a message could be counted
by MTAs when trying to decide whether or not a message routing loop by MTAs when trying to decide whether or not a message routing loop
is 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
skipping to change at page 6, line 47 skipping to change at page 8, line 4
One should note, however, when choosing higher levels of granularity, One should note, however, when choosing higher levels of granularity,
that the Received header fields present on a message could be counted that the Received header fields present on a message could be counted
by MTAs when trying to decide whether or not a message routing loop by MTAs when trying to decide whether or not a message routing loop
is 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 document adds to the "Additional-registered-clauses" sub-
the "Mail Parameters" registry, created by [SMTP], the following registry of the "Mail Parameters" registry, created by [SMTP], the
entry: following 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 document]
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 First Come First Served rules of [IANA] for new governed by the First Come First Served rules of [IANA] for new
registrations. Changes to the status of existing entries are limited registrations. Changes to the status of existing entries are limited
to the original registrant or IESG approval. to the original registrant or IESG approval.
Discussion of all registry updates is encouraged via one or more IETF Discussion of all registry updates is encouraged via one or more IETF
mailing lists that typically cover email-related subjects prior to mailing lists that typically cover email-related subjects prior to
approval of the change, as a way of documenting the work. approval of the change, as a way of documenting the work. The
ietf-smtp@ietf.org list is suggested.
Note that only registrations of queue state keywords are permitted. Note that only registrations of queue state keywords are permitted.
The registry is not to be used for specifying secondary information The registry is not to be used for specifying secondary information
(i.e., the "value" part of the ABNF in Section 3). (i.e., the "value" part of the ABNF in Section 3).
Registrations must include the following entries: Registrations are to include the following entries:
Name: The name of the state keyword being defined or updated, which Name: The name of the state keyword being defined or updated, which
conforms to the ABNF shown in Section 3 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, or if no stable reference exists, a more
detailed explanation of the queue state than is in the
"Description", sufficient to allow interoperability.
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).
The initial registration set is as follows: The initial registration set is as follows:
+------------+---------------------------+---------------+---------+ +------------+------------------------+-----------------+---------+
| Name | Description | Specification | Use | | Name | Description | Specification | Use |
+------------+---------------------------+---------------+---------+ +------------+------------------------+-----------------+---------+
| auth | Held for message | [this memo] | current | | auth | Held for message | [this document] | current |
| | authentication | | | | | authentication | | |
+------------+---------------------------+---------------+---------+ +------------+------------------------+-----------------+---------+
| content | Held for message | [this memo] | current | | content | Held for message | [this document] | current |
| | content analysis | | | | | content analysis | | |
+------------+---------------------------+---------------+---------+ +------------+------------------------+-----------------+---------+
| convert | Held for message | [this memo] | current | | convert | Held for message | [this document] | current |
| | content conversion | | | | | content conversion | | |
+------------+---------------------------+---------------+---------+ +------------+------------------------+-----------------+---------+
| moderation | Held for list moderation | [this memo] | current | | moderation | Held for list | [this document] | current |
+------------+---------------------------+---------------+---------+ | | moderation | | |
| normal | Message is not being held | [this memo] | current | +------------+------------------------+-----------------+---------+
| | other than to accommodate | | | | normal | Message is not being | [this document] | current |
| | typical relaying delays | | | | | held other than to | | |
+------------+---------------------------+---------------+---------+ | | accommodate typical | | |
| other | Held for causes not | [this memo] | current | | | relaying handling | | |
| | covered by other | | | +------------+------------------------+-----------------+---------+
| | registered state keywords | | | | other | Held for causes not | [this document] | current |
+------------+---------------------------+---------------+---------+ | | covered by other | | |
| outbound | Message placed in | [this memo] | current | | | registered state | | |
| | outbound queue | | | | | keywords | | |
+------------+---------------------------+---------------+---------+ +------------+------------------------+-----------------+---------+
| quarantine | Held for operator action | [this memo] | current | | outbound | Message placed in | [this document] | current |
| | due to content analysis | | | | | outbound queue | | |
| | or local policy | | | +------------+------------------------+-----------------+---------+
+------------+---------------------------+---------------+---------+ | quarantine | Held for operator | [this document] | current |
| timed | Held to accommodate a | [this memo] | current | | | action due to content | | |
| | specific requested | | | | | analysis or local | | |
| | delivery window | | | | | policy | | |
+------------+---------------------------+---------------+---------+ +------------+------------------------+-----------------+---------+
| timed | Held to accommodate a | [this document] | current |
| | specific requested | | |
| | 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 Further discussion about trace field security can be found in Section
7.6 of [SMTP]. 7.6 of [SMTP].
8. References 8. References
skipping to change at page 9, line 28 skipping to change at page 11, line 5
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
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 Extra Handling
Typical message delivery Typical message delivery
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 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 extra
delays; only Received header fields shown handling; 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>;
 End of changes. 27 change blocks. 
101 lines changed or deleted 150 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/