HTTP/2 302 date: Mon, 14 Jul 2025 13:48:34 GMT content-type: text/html content-length: 143 location: https://get.ietf.org/implementation-report/report-rfc1891-1894.txt cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 expires: Thu, 01 Jan 1970 00:00:01 GMT vary: Accept-Encoding server: cloudflare cf-ray: 95f17a7bd82d7679-BLR alt-svc: h3=":443"; ma=86400 HTTP/2 200 date: Mon, 14 Jul 2025 13:48:35 GMT content-type: text/plain etag: W/"6d3bb071a6919fba9f2dacf69139a80a" vary: Accept-Encoding server: cloudflare cf-ray: 95f17a7c0dcadfa6-BLR content-encoding: gzip alt-svc: h3=":443"; ma=86400 Delivery Status Notification Implementation Report Greg White, Lucent Technologies The VPIM Working Group is requesting that the suite of RFC's defining the Delivery Status Notification functionality of internet mail be promoted to Draft Standard. The purpose of this report is to provide supporting information the IESG can use to make its decision. This suite of RFC's include the following: RFC 1891 - SMTP Service Extension for Delivery Status Notifications RFC 1892 - The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages RFC 1893 - Enhanced Mail System Status Codes RFC 1894 - An Extensible Message Format for Delivery Status Notifications A template was provided by Ned Freed outlining each feature in the suite. Greg Vaudreuil sent the template to several vendors, asking them to comment on which of their products support the features, and to report any anecdotal interoperability experience The responding vendors and products are the following: Sendmail.org - Sendmail Innosoft International - PMDF Sun Microsystems - iMS Lucent Technologies - MessagingLink (ML) The implementation report follows Ned's template: RFC 1891: SMTP server advertises DSN extension Yes: Sendmail [S1], PMDF, iMS, ML No: Accepts and acts upon ENVID parameter of MAIL command Yes: Sendmail, PMDF, iMS, ML No: Accepts and acts upon RET parameter of MAIL command Yes: Sendmail, PMDF, iMS, ML No: Accepts and acts upon NOTIFY parameter of RCPT command Yes: Sendmail, PMDF, iMS, ML [M1] No: Accepts and acts upon ORCPT parameter of RCPT command Yes: Sendmail, PMDF, iMS, ML No: SMTP client employs DSN extension when advertised by a server Yes: Sendmail, PMDF, iMS, ML No: Generates ENVID parameter for MAIL command Yes: Sendmail, PMDF, iMS, ML No: Generates RET parameter for MAIL command Yes: Sendmail, PMDF, iMS, ML No: Generates NOTIFY parameter for RCPT command Yes: Sendmail, PMDF, iMS, ML No: Generates ORCPT parameter for RCPT command Yes: Sendmail, PMDF, iMS, ML No: SMTP client generates relayed DSN's when appropriate Yes: Sendmail, PMDF, iMS No: ML MTA defaults handling of non-NOTIFY messages to NOTIFY=FAILURE Yes: Sendmail [S2], PMDF, iMS No: MTA handles NOTIFY interaction with forwarding, aliases and mailing lists correctly Yes: Sendmail, PMDF, iMS No: ML [M2] RFC's 1892 & 1894: MTA uses the "delivery-status" version of the Multipart/Report format for the DSN's it generates Yes: Sendmail, PMDF, iMS, ML No: RFC 1893: MTA uses these codes in the generated DSN's Yes: Sendmail, PMDF, iMS, ML No: Interoperability testing: Please describe any experience you have interoperating with other products. Sendmail interoperability experience: Eric Allman reports that he is not aware of any current interoperability problems. Sendmail has been shipping with DSN since version 8.7 (09/1995). There have been fixes for possible interoperability problems in the past. In reverse order by date: 8.11.2/8.11.2 2000/12/29 Don't issue DSNs for addresses which use the NOTIFY parameter (per RFC 1891) but don't have FAILURE as value. 8.10.0/8.10.0 2000/03/01 Don't announce DSN if PrivacyOptions=noreceipts is set. Problem noted by Dan Bernstein, fix from Robert Harker of Harker Systems. Avoid incorrect Final-Recipient, Action, and X-Actual-Recipient success DSN fields as well as duplicate entries for a single address due to S5 and UserDB processing. Problems noted by Kari Hurtta of the Finnish Meteorological Institute. 8.9.1/8.9.1 1998/07/02 If the SIZE= MAIL From: ESMTP parameter is too large, use the 5.3.4 DSN status code instead of 5.2.2. Similarly, for non-local deliveries, if the message is larger than the mailer maximum message size, use 5.3.4 instead of 5.2.3. Suggested by Antony Bowesman of Fujitsu/TeaWARE Mail/MIME System. 8.9.0/8.9.0 1998/05/19 Properly generate success DSN messages if requested for aliases which have owner- aliases. Problem noted by Kari Hurtta of the Finnish Meteorological Institute. 8.8.8/8.8.8 1997/10/24 Display the proper Final-Recipient on DSN messages for non-SMTP mailers. Problem noted by Kari E. Hurtta of the Finnish Meteorological Institute. 8.8.3/8.8.3 1996/11/17 If the F=l flag was set on an SMTP mailer to indicate that it is actually local delivery, and NOTIFY=SUCCESS is specified in the envelope, and the receiving SMTP server speaks DSN, then the DSN would be both generated locally and propagated to the other end. 8.8.0/8.8.0 1996/09/26 DSN NOTIFY parameters were not properly propagated across queue runs; this caused the NOTIFY info to sometimes be lost. Problem pointed out by Claus Assmann of the Christian-Albrechts-University of Kiel. The RET= envelope parameter (used for DSNs) wasn't properly written to the queue file. Fix from John Hughes of Atlantic Technologies, Inc. DSNs were inconsistent if a failure occurred during the DATA phase rather than the RCPT phase: the Action: would be correct, but the detailed status information would be wrong. Problem noted by Bob Snyder of General Electric Company. 8.7.2/8.7.2 1995/11/19 Don't advertise the ESMTP DSN extension if the SendMimeErrors option is not set, since this is required to get the actual DSNs created. Problem pointed out by John Gardiner Myers of CMU. PMDF & iMF interoperability experience: Ned Freed reports that DSN functionality in both products is known to interoperate with Sendmail, Microsoft Exchange, and many other MTA's. Furthermore, PMDF-X400 successfully processes DSN's from Sendmail, Microsoft Exchange, and PMDF. ML interoperability experience: Greg White reports that ML has participated in interoperability testing with products from Comverse, Glenayre and Nortel. It was proven at this time that ML DSN functionality was interoperable with these products. Greg Vaudreuil also provides the following commentary: The DSN protocol specifications in RFC's 1981 - 1984 have seen widespread implementation and use. The DSN format specified in RFC's 1982 & 1984 is widely generated by almost all deployed MTA's. All documented fields and attributes are implemented by at least two vendors. While not widely machine-interpreted, there are many implementations that interpret DSN's, including several mailing list maintenance scripts, most VPIM (Nortel & Lucent Technologies), IFax terminals and several gateway products to X.400 and legacy mail systems. The SMTP extension for DSN is implemented by the major MTA vendors and is deployed supporting both positive and negative DSN requests and full/partial/no message return options. The envelope ID parameter and original recipient parameter are implemented and deployed. At least PMDF, Intermail and Sendmail support the full SMTP DSN extension. The DSN standards have been incorporated in whole or in part in many other Internet standards efforts including iFax, VPIM and message tracking. The protocol is now an expected and essential part of Internet email. REFERENCES [S1] Sendmail can be configured to not advertise the DSN extension; this is for sites that feel NOTIFY=SUCCESS is a security issue. [S2] Sendmail interprets a non-NOTIFY message as NOTIFY=FAILED,DELAY as permitted in RFC 1891. [M1] ML accepts and acts on NOTIFY=FAILURE; ML accepts, but does not act upon NOTIFY=DELAY,SUCCESS and NOTIFY=NEVER. [M2] These items are not applicable to ML.