Indicating Supported Media Features Using Extensions to DSN and MDN
Extracted elements (8)
The extensions are defined for both DSN and MDN to cover different deployment scenarios: DSNs may not be universally available, while MDNs expose disposition timing. Supporting both mechanisms allows senders to obtain media feature capability information regardless of which notification type the recipient supports.
DSNs are not available between all senders and receivers; MDNs require the receiver to disclose message disposition information (or, if using the 'denied' disposition-type, the time the notification was generated). Implementations must choose the appropriate mechanism given these drawbacks.
If the recipient's MTA determines that a message cannot be processed, it is strongly encouraged to reject the message with enhanced status code 5.6.1 (RFC 1893), either in response to the end-of-mail-data indicator (if RFC 2034 enhanced error codes are supported) or by generating a delivery failure DSN.
The media feature tag schema MUST be registered following the registration requirements of RFC 2506 ('Media Feature Tag Registration Procedure').
The media-feature-tags schema documents MUST utilize the language described in [SYNTAX] (RFC 2533, 'A Syntax for Describing Media Feature Sets').
The 'Media-Accept-Features' extension field is defined for use in both DSN (per-recipient fields per RFC 1894 section 2.3) and MDN (extension fields per RFC 2298 section 3.1) messages. Its value is a media-feature-tags expression using the ABNF: media-features = "Media-Accept-Features" ":" media-feature-tags.
Inaccurate media feature information—whether from a malicious spoofed DSN or MDN, or from misconfiguration—could cause a denial of service by causing subsequent messages to be sent that the recipient is unable to process.
The extension-field grammar is defined as: extension-field = media-features CRLF, where media-feature-tags is *text with LWSP wrapping, using ABNF notation from RFC 2234.