An Extensible Message Format for Message Tracking Responses
updates
- rfc-3463 — Enhanced Mail System Status Codes
Extracted elements (24)
Message tracking is intended as a 'last resort' mechanism. DSNs and MDNs provide primary delivery status; only if no response is received from either would Message Tracking be used, keeping tracking requests rare and reducing privacy exposure.
The distinction between 'expanded' and 'delivered' action values exists because some deliveries cause list expansion without the MTA's knowledge (e.g., delivery to a program that causes expansion). If the MTA cannot ensure list expansion will occur, it should use 'delivered'.
This document is based on RFC 3464 (DSN format) and incorporates by reference sections on general conventions, *-type subfields, and lexical tokens. Fields such as Original-Envelope-Id, Reporting-MTA, Arrival-Date, Original-Recipient, Final-Recipient, Action, Status, Remote-MTA, Last-Attempt-Date, and Will-Retry-Until are defined as in RFC 3464.
An LDA speaking LMTP that supports the MTRK extension SHOULD pass the tracking request to the LDA; in this case the MTA->LDA exchange will issue a 'transferred' tracking status.
The Action field MUST be present for each recipient named in the MTSN. Valid values are: failed, delayed, delivered, expanded, relayed, transferred, opaque.
The Arrival-Date field (as defined in RFC 3464 section 2.2.5) is REQUIRED in the per-message fields of every MTSN.
The Last-Attempt-Date field is REQUIRED if any delivery attempt has been made and the Action field does not have value 'opaque'. It MUST NOT be included if no delivery attempts have been made.
The Original-Envelope-Id field (as defined in RFC 3464 section 2.2.1) is REQUIRED in the per-message fields of every MTSN.
The Remote-MTA field MUST NOT be included if no delivery attempts have been made or if the Action field has value 'opaque'.
The Reporting-MTA field (as defined in RFC 3464 section 2.2.2) is REQUIRED in the per-message fields of every MTSN.
The Status field is REQUIRED for each per-recipient group. The new code X.1.9 must be used exclusively with a 'relayed' Action field.
The Will-Retry-Until field MUST NOT be included if the message is not in the local queue or if the Action field has value 'opaque'; otherwise, this field SHOULD be included.
Tracking algorithms MUST NOT allow tracking through list expansions. When a message is delivered to a list, a tracking request MUST respond with an 'expanded' status and MUST NOT display the contents of the list.
When the Action field value is 'delivered', 'expanded', or 'relayed', the tracking agent SHOULD NOT attempt further downstream tracking requests.
When the Action field value is 'transferred', the tracking agent SHOULD attempt further downstream tracking requests unless that information is already given in a chaining response.
Message recipients who autoforward messages may not wish to divulge the forwarding address. MTA authors are encouraged to provide confidentiality mechanisms, such as responding with 'relayed' status or declaring delivery and re-sending to a confidential address without revealing it.
A Message Tracking Status Notification (MTSN) body MUST be a multipart/related with type parameter of 'message/tracking-status'; each subpart MUST be of type 'message/tracking-status'. Multiple parts may be included when an MTQP server chains requests to the next server.
A new enhanced status code X.1.9 ('Message relayed to non-compliant mailer') is added to RFC 3463. A 2.1.9 Status field MUST be used exclusively with a 'relayed' Action field.
Per-recipient fields include: Original-Recipient (REQUIRED), Final-Recipient (REQUIRED), Action (REQUIRED), Status (REQUIRED), and optional Remote-MTA, Last-Attempt-Date, and Will-Retry-Until fields, plus extension fields.
The Action field defines seven possible states: 'failed' (delivery failed), 'delayed' (in queue awaiting delivery), 'delivered' (successfully delivered to final recipient), 'expanded' (forwarded to multiple addresses), 'relayed' (delivered to non-tracking environment), 'transferred' (transferred to another MTRK-compliant MTA), 'opaque' (unknown status).
The message/tracking-status MIME content-type uses '7bit' encoding, which MUST be used to maintain readability when viewed by non-MIME mail readers. It has no optional parameters.
IANA has registered the SMTP extension defined in this document (message/tracking-status MIME type and associated MTSN format) as described in section 5.
Malicious servers may attempt to subvert message tracking and return false information, resulting in misdirection or misinterpretation of results.
The message/tracking-status body consists of per-message fields followed by a blank line, then one or more groups of per-recipient fields each preceded by a blank line. Formally: tracking-status-content = per-message-fields 1*( CRLF per-recipient-fields ).