Indicating Email Handling States in Trace Fields
Extracted elements (22)
Granularity of state annotations is expected to vary by circumstance. Typical use is limited to 'unusual' transitions; finer granularity may be used for transitions of administrative responsibility (e.g., MTA to MLM handoff), but excessive fields risk triggering false loop detection.
The presence of a state clause on a trace field indicates entry of the message into that state; a later trace field added by the same or next agent implies departure from that state. This entry/exit signaling is implicit rather than requiring an explicit 'exit' annotation.
The sole purpose of the state clause is to allow determination of the point(s) in the chain of custody where a message was subjected to handling outside normal routing and queuing. It is explicitly not intended for associating metadata such as spam classification or content categorization, since there is no guarantee all agents in the chain made such annotations.
Received header fields may be counted by MTAs when determining whether a message routing loop is in effect (per RFC 5321 Section 6.3). A message with an abundance of state-annotated Received fields might cause an incorrect loop determination, causing it to be removed from the mail stream.
An agent wishing to make a state annotation SHOULD add only a single Received header field including such annotation, indicating both the time of completion and the final disposition relative to that agent.
An MTA implementing this specification SHOULD add a Received field whenever it determines a special handling condition will occur and places the message into that condition, or when it determines no special handling is required and prepares it for relay to the next handling agent.
The additional-state-keyword (any token beyond the registered set) MUST be registered; unregistered keywords may appear as unreg-state-keyword but the expectation is registration. New state keywords require registration in the IANA Registered-states sub-registry.
Verbose per-step state annotation (e.g., adding four Received fields for auth, virus scan, spam scan, and outbound queuing within a single system pass) SHOULD NOT be applied except when doing detailed analysis of a single component to identify performance issues.
State keyword 'auth': the message entered a queue pending authentication of some identifier in the message.
State keyword 'content': the message entered a queue pending content analysis, such as scanning for spam or viruses.
State keyword 'convert': the message entered a queue pending content conversion (e.g., unicode2ascii).
State keyword 'moderation': the message entered a hold pending mailing list moderator action.
State keyword 'normal': the message is not in an administrative hold and is queued for or being handed off to the next handling agent. This is the default interpretation when no 'state' clause is present.
State keyword 'other': the message entered a hold or queue for reasons not covered by other keywords and not for transient technology issues.
State keyword 'outbound': the message entered a queue for outbound relaying. This is typically the last state added for a single host; the next Received field is expected from another host.
State keyword 'quarantine': the message entered an isolation queue hold pending operator action for local policy reasons.
State keyword 'timed': the message entered a hold to meet a requested delivery window, such as defined in the SMTP Future Message Release extension (RFC 4865).
The 'state' clause is a new optional extension to the Received header field (defined in SMTP RFC 5321 Section 4.4) that indicates the nature of additional handling imposed on a message. It is followed by a single keyword identifying the queue or processing state entered.
A new 'Registered-states' sub-registry is created under the MAIL Parameters registry at IANA. Governed by First Come First Served rules; entries require Name, Description, Specification, and Use (current/deprecated/historic). Only queue state keywords may be registered; not secondary 'value' tokens. Initial registrations: auth, content, convert, moderation, normal, other, outbound, quarantine, timed — all 'current'.
The 'state' clause is registered in the MAIL Parameters Additional-registered-clauses sub-registry (created by RFC 5321). Entry: Clause name 'state', description 'Indicates entry into a special queue state', syntax 'state <state-name>', reference RFC 6729.
Use of state trace information can reveal hints about local policy that was in effect at the time of message handling, potentially exposing administrative or filtering policies to external observers. Further discussion is referenced in Section 7.6 of RFC 5321.
The ABNF for the state clause is: State = CFWS 'state' FWS queue-state-keyword [ '/' value ], where queue-state-keyword is either a registered or unregistered state keyword token, and the optional value token provides additional label detail. FWS and CFWS are from RFC 5322; token is from RFC 2045.