An Extensible Message Format for Message Tracking Responses
Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format for Delivery Status Notifications". It i
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 10 must, 4 should, 1 may.
3 Format of a Message Tracking Status Notification
- MUSTThe actual body MUST be a multipart/related [RFC-RELATED] with type parameter of "message/tracking-status"; each subpart MUST be of type "message/tracking-status" as described herein.
3.1 The message/tracking-status content-type
- MUSTMIME type name: message MIME subtype name: tracking-status Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers.
3.3.3 Action field
- MUSTThis field MUST be present for each recipient named in the MTSN.
- SHOULD NOTNo further information is available; in particular, the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
- SHOULD NOTHowever, these additional addresses are not trackable, and the tracking agent SHOULD NOT attempt further "downstream" tracking requests.
- SHOULDThe tracking agent SHOULD attempt further "downstream" tracking requests unless that information is already given in a chaining response.
3.3.4 Status field
- MUSTA 2.1.9 Status field MUST be used exclusively with a "relayed" Action field.
3.3.5 Remote-MTA field
- MUST NOTThis field MUST NOT be included if no delivery attempts have been made or if the Action field has value "opaque".
- MAYIf delivery to some agent other than an MTA (for example, a Local Delivery Agent) then this field MAY be included, giving the name of the host on which that agent was contacted.
3.3.6 Last-Attempt-Date field
- REQUIREDThis field is REQUIRED if any delivery attempt has been made and the Action field does not have value "opaque", in which case it will specify when it last attempted to deliver this message to another MTA or other Delivery Agent.
- MUST NOTThis field MUST NOT be included if no delivery attempts have been made.
3.3.7 Will-Retry-Until field
- MUST NOTIf the message is not in the local queue or the Action field has the value "opaque" the Will-Retry-Until field MUST NOT be included; otherwise, this field SHOULD be included.
3.5 Interaction Between MTAs and LDAs
- SHOULDA message that has been delivered to a Local Delivery Agent (LDA) that understands message tracking (in particular, an LDA speaking LMTP [RFC-LMTP] that supports the MTRK extension) SHOULD pass the tracking request to the LDA.
4.2 Confidentiality
- MUST NOTThe tracking algorithms MUST NOT allow tracking through list expansions.
- MUSTWhen a message is delivered to a list, a tracking request MUST respond with an "expanded" tracking status and MUST NOT display the contents of the list.