Instant Message Disposition Notification (IMDN)
Extracted elements (27)
A DateTime header field is included in IMs and echoed in IMDNs to allow human-level correlation on devices with limited state retention (e.g., mobile devices that lose power or purge sent items), since the spec does not mandate that the IM Sender keep state.
Display notification indicates the start of rendering (including audio/video) rather than confirmed user reading, because there is no positive acknowledgement from the user. Therefore, the protocol explicitly cannot be used as a certified proof of reading.
Routing information (IMDN-Route, IMDN-Record-Route) was placed in the IMDN application-layer payload rather than the transport layer to make the IMDN mechanism independent of the transport protocol. The acknowledged consequence is that this eliminates the possibility of end-to-end encryption.
An IM Sender matches an IMDN to an IM by correlating the Message-ID header field in the IM with the <message-id> element in the IMDN XML body. The Message-ID of the IMDN itself is distinct and unrelated to the IM's Message-ID.
MSRP already provides built-in positive and negative delivery reports but lacks display or processing notifications. IMDN is scoped to page-mode only; session-mode use via MSRP is left for future standardization.
An IM Recipient MUST NOT construct more than one IMDN per disposition type. It MUST NOT generate 'processing' notifications. A Disposition-Notification header field MUST NOT appear in an IMDN, and an IM Sender MUST NOT send an IMDN for an IMDN.
An intermediary MUST NOT add an Original-To header field if one already exists, and MUST NOT change this header field value if it is already present. If the intermediary changes the CPIM To header field value, it MUST insert an Original-To header field.
An intermediary MUST remove any information about final recipients of a list if list membership is not disclosed, by removing the <recipient-uri> and/or <original-recipient-uri> elements from the IMDN body before forwarding.
If IMDN-Record-Route header fields appear in the IM, the IM Recipient constructing the IMDN MUST copy the contents into IMDN-Route header fields and maintain their order. If there is no IMDN-Record-Route header field, the IM Recipient MUST send the IMDN to the URI in the From header field.
If the IM is encrypted, the IM Recipient or intermediary MUST encrypt the IMDN body. If the IM Recipient has a certificate, it MUST sign the IMDN. The same level of security applied to an IM MUST be applied to its IMDNs.
IM Recipients MUST insert a Content-Disposition header field set to the value 'notification' in constructed IMDNs, indicating to the IM Sender that the message is an IMDN.
SIP Proxies MUST NOT generate IMDNs but MUST forward them like any other SIP request.
The IM Sender MUST include the DateTime CPIM header field if it would like an IMDN, to allow human-level correlation between an IM and its IMDN when state cannot be retained.
The IM Sender MUST include the Disposition-Notification header field to indicate the desire to receive IMDNs from the IM Recipient for that specific IM.
The IM Sender MUST include the Message-ID header field in the IM for which he wishes to receive an IMDN. The Message-ID MUST be selected to minimize collision chance and be prohibitive for attackers to forge; it is RECOMMENDED to use a cryptographically secure PRNG with at least 64 bits of randomness.
The IMDN payload MUST be well-formed XML, MUST be based on XML 1.0, and MUST be encoded using UTF-8.
When transporting via SIP, the Content-type header field MUST be of MIME type 'message/cpim' for both IMs and IMDNs.
IMDNs provide a fine-grained view of IM Recipient activity. It is strongly RECOMMENDED that the IM Recipient obtain the user's consent before sending an IMDN. The IM Recipient may silently ignore IMDN requests or always send 'forbidden' status to protect user privacy.
Five new CPIM header fields are defined in the 'urn:ietf:params:imdn' namespace: Disposition-Notification, Message-ID, Original-To, IMDN-Record-Route, and IMDN-Route. All CPIM messages prepend these with a namespace prefix assigned via the NS header field.
The IMDN payload is an XML document of MIME type 'message/imdn+xml' with root element <imdn>, containing mandatory sub-elements <message-id> and <datetime>, optional <recipient-uri>, <original-recipient-uri>, <subject>, and exactly one of <delivery-notification>, <processing-notification>, or <display-notification>, each with a mandatory <status> child.
Three categories of disposition types are defined: 'delivery' (states: delivered, failed, forbidden, error), 'processing' (states: processed, stored, forbidden, error, generated only by intermediaries), and 'display' (states: displayed, forbidden, error).
RFC 5438 registers the MIME type 'message/imdn+xml' for IMDN payloads, the XML namespace 'urn:ietf:params:xml:ns:imdn', the URN sub-registry 'urn:ietf:params:imdn' for IMDN header parameters (initial entries: Disposition-Notification, Message-ID, Original-To, IMDN-Record-Route, IMDN-Route), and the Content-Disposition value 'notification'.
An attacker can use the IMDN system to mount denial-of-service attacks by sending IMs with IMDN requests to flood intermediaries (e.g., large URI-list expansion) or to 'bounce' IMDNs from unsuspecting endpoints. Logging all IMDN requests on the recipient user agent is suggested as a mitigation for tracking abuse.
IMDN cannot be relied upon as a certified delivery service: IMDNs may be lost in transit, the IM Recipient may bypass IMDN issuance through policy or user agent manipulation, and the IM Recipient can lie about or delay the timestamp without any protocol-level detection.
IMDNs may be forged to falsely indicate that an IM was delivered or displayed. Message-IDs MUST use at least 64 bits of cryptographic randomness to prevent off-path attackers from forging valid IMDNs. Endpoints wishing to make automatic use of IMDNs should take precautions against denial-of-service from forged or unsolicited IMDNs.
Aggregated IMDNs are encoded as multipart/mixed MIME, with each individual IMDN included as a 'message/imdn+xml' part. The outer CPIM message carries Content-Disposition: notification.
The Disposition-Notification header field carries comma-separated notify-req values ('negative-delivery', 'positive-delivery', 'processing', 'display', or Token), each optionally followed by semicolon-separated parameters. The Message-ID field carries a single Token value.