Indicating Email Handling States in Trace Fields
Brandenburg InternetWorking675 Spruce Dr.SunnyvaleUSA94086+1.408.246.8253dcrocker@bbiw.nethttp://bbiw.netCloudmark, Inc.128 King St., 2nd FloorSan FranciscoCA94107USsuperuser@gmail.com
Applications
Individual submissionQuarantineModeration This memo registers a trace field clause for use in
indicating transitions between handling queues or
processing states, including enacting inter- and
intra-host message transitions. This might
include message quarantining, mailing list moderation,
timed delivery, queueing for further analysis, content
conversion, or other similar causes, as well as
optionally identifying normal handling queues. defines the content of email
message trace fields, commonly the "Received" header field.
These are typically used to record an 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 the next. Section 3.7.2 of that memo
mentions that "the most important use of of Received:
lines is for debugging mail faults [...]". There are some cases where there may be large time gaps
between trace fields. Though this might be caused by
transient communication issues, they might also be caused
by policy decisions or special processing regarding the
content of the message, authorization of some
identity on the message, or transitions between major
software components. Common examples include message
quarantines (filters that delay relaying or delivery
of a message pending manual operator action), pending
content analysis, or mailing list servers that impose
moderation 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 fields to indicate that a message entered such
a special processing 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 was an imposed
delay rather than one caused by transient technical
difficulties. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in
. This memo creates a new trace field clause, called
"state", which can be used within Received header fields
(see Section 4.4 of )
to indicate the nature of a delay imposed on relaying of
a message toward its recipient(s). It is followed by a
single keyword that provides that detail. A Mail Transfer
Agent (MTA) or other handling agent that determines a
message has entered a state other than normal queueing of
messages for relaying or delivery MAY generate a trace
field including one of these clauses. That is, the
presence of this clause on a trace field is an indication
of the entry of the message 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-data with the message, such as
categorizing the message (e.g., the 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 may define other registered keywords (see
):
The message entered a
queue pending authentication of some
identifier in the message. The message entered a
queue pending content analysis, such as
scanning for spam or viruses. The message entered a
queue pending content conversion. The message entered a
hold pending mailing list moderator
action. The message is not in an
administrative hold and is queued for or
is being handed off to the next handling
agent (which may be local delivery). This is
the default interpretation when no "state"
clause is present. The message entered a
hold or queue for reasons not covered by other
keywords in this list, and not for
transient technology issues. The message entered a
queue for outbound relaying. This is
typically the last case added for a single
host, and the next Received header field is
expected to be added by some other host. The message entered a
hold in an isolation queue pending operator
action for local policy reasons. The message entered a
hold in order to meet a requested
delivery window, such as is defined in
. The ABNF for this clause:
"unstructured", "FWS" and "CFWS" are defined in
A transfer agent making use of this extension MAY also
include header field comments to provide additional
information. The "value" is available for providing additional labels as
explanation for the state transition. Examples could
include:
convert/unicode2ascii moderation/not-subscribed quarantine/spam Handling agents are not expected to implement or support
all of these. Indeed, recording trace information for
all of the states described above could make the
header of a message inordinately large. Rather, an agent
is encouraged to apply state annotations when a
message enters a handling queue where substantial delay
is possible, and especially when a handoff has occurred
between two different, independent agents. For example, an MTA receiving a message, doing message
authentication, scanning for viruses and spam, and then
putting it in an outbound queue could add four Received
header fields denoting each 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 unusual
(and extremely verbose). This method SHOULD NOT be
applied except when doing detailed analysis of a single
component to identify performance issues with those
steps. Rather, an agent that wishes to make a state annotation
SHOULD add only a single Received header field including
such annotation, thus 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 that message
relative to that agent. For example, an MTA
receiving a message that performs various checks on
the message before immediately handing it off to a Mailing
List Manager (MLM) would only record a "normal" state,
assuming it passes those checks. The MLM 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. The degree of granularity -- and therefore the degree of
verbosity -- recorded through the use of this additional
trace clause is likely to vary depending on circumstances.
It will typically be the case that use of this clause will
be limited to "unusual" transitions, such as when a message
requires additional scrutiny or other processing, or needs
to be quarantined. Somewhat greater granularity might also include
transitions of administrative responsibility, such as
between an Mail Transfer Agent (MTA) operator and a
Mailing List Manager (MLM) operator. This could be
further enhanced to note some transitions that are
interesting only when other transitions have occurred,
such as noting entry to the outbound queue only when the
message is originating from an "interesting" source, like
an MLM, since an MLM can introduce significant delay
and it could be useful to know when it completed its
processing, as distinct from the subsequent processing by
the originating MTA. In circumstances needing very
fine-grained trace information, fields might be created
to note all of these "significant" network architecture
transitions. One should note, however, when choosing higher levels
of granularity, 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 is in effect. A
message with an abundance of these might cause an incorrect
determination that the message is in a delivery loop,
causing it to be removed from the mail stream. See
Section 6.3 of for further
discussion. This memo adds to the "Additional-registered-clauses"
sub-registry of the "Mail Parameters" registry,
created by , the following entry:
state Indicates entry into
a special queue state
state <state-name> [this memo] The "Mail Parameters" registry at IANA is updated
by the creation of the "Registered-states"
sub-registry to contain valid state keywords for use
with this specification. Updates to this registry
are governed by the First Come First Served rules of
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 ). Registrations must include the following entries:
The name of the state keyword
being defined or updated, which conforms to
the ABNF shown in A brief description
of the keyword's meaning The specification
document that defines the queue state
being registered One of "current" (the
state keyword is in current use),
"deprecated" (the state keyword is in
use but not recommended for new
implementations), or "historic" (the
state keyword is no longer in substantial
current use). The initial registration set is as follows:
The use of this trace information can reveal hints as to
local policy that was in effect at the time of message
handling. Further discussion about trace field security can be found
in Section 7.6 of .
Guidelines for Writing an IANA
Considerations Section in RFCs
Key words for
use in RFCs to Indicate Requirement
LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword In many standards track documents
several words are used to signify
the requirements in the
specification. These words are
often capitalized. This document
defines these words as they
should be interpreted in IETF
documents. Authors who follow
these guidelines should
incorporate this phrase near the
beginning of their document:
The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this
document are to be interpreted
as described in RFC 2119.
Note that the force of these
words is modified by the
requirement level of the document
in which they are used. Internet Message Format
Qualcomm, Inc.
Simple Mail Transfer Protocol
SMTP Submission Service Extension for
Future Message Release
This section includes a sample of the new trace
field clause in use. The message passed from internal.example.com to
newyork.example.com intended for a mailing list
hosted at the latter. For list administrative
reasons, the message is held there for moderation.
It is finally released over an hour later and
passed to the next host. A comment after
the state expression indicates the actual cause
for the administrative hold. The authors wish to acknowledge the following for their
reviews and constructive criticisms of this proposal:
Tony Finch,
Ned Freed,
Carl S. Gutenkunst,
John Levine,
Bill McQuillan,
S. Moonesamy,
Alexey Melnikov,
Robert A. Rosenberg,
Hector Santos,
Rolf Sonneveld, and
Mykyta Yevstifeyev.