Subject: Message Disposition Notification: Second request for implementat ion status

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Fri, 16 Aug 2002 07:02:53 -0500

The IESG has requested a more detailed implementation report for the advancement of the message disposition notification protocol to Draft Standard.  The current documentation of this protocol is <draft-vaudreuil-mdnbis-03.txt>, which is intended to replace proposed standard RFC 2298.  The current version of the protocol and the submitted interoperability report is based on a call for implementation information solicited and compiled after the London IETF meeting last year.   I appreciate the responses to the previous query for information on this protocol late last year.  Unfortunately, the bar has been raised on implementation reports and I need more detailed information than was previously collected.

If you can authoritatively respond on the capabilities of a contemporary implementation of this protocol, please reply to the questions below.  I will compile the responses into documentation sufficient to advance this seemingly mature protocol to draft standard.

Information is requested from three classes of systems based on their role in the protocol chain:  MDN requesting UA's (including gateways), MDN Generating UA's (including gateways), MDN receiving UA's (Including gateways), and final-delivery MTA's.

Thank you.  All responses will be appreciated.

Greg Vaudreuil

P.S., My appologies for cross-posting this message to multiple lists.  I want to ensure that we get a responses from the many communities that have made use of this protocol.

----------------------------

Please identify the following line-items in such a reply.

1) Name of software, vendor, and version upon which this response is based
   a) Approximately when was this feature introduced into a public release?

2) MDN Requesting user agent behaviors

  a) Client sends disposition-notification-to header:  (Y/N)

  b) Client sends disposition-notifications-options header (Y/N)
       b1) Client sends request for proprietay options (describe)

  c) Message disposition header is placed in inner message when used with message partial (Y/N/NA)
	Please indicate N/A if the UA or gateway does not generate message partial constructs

3) Final MTA behaviors

  a) Final MTA (Delivery process) copies ORCPT parameter from RCPT-TO command into Original-Recipient
          header of message upon deposit

4) MDN Generating UA

  a) MDN report is generated upon request (Y/N). If yes, which fields are populated:
         Reporting-UA 
	   mdn-gateway-field
	   original-recipient-field
	   final-recipient-field
	   original-message-id-field
	   disposition-field
	   failure-field
	   error-field
	   warning-field
	         extension-field

b) Which disposition modes are supported / generated:
	Manual action
	automatic action
            MDN-sent-manually
	MDN-sent-automatically   

c) Which disposition types are generated
	displayed
	deleted

d) Are any extension fields generated?

5) MDN Receiving user agent behavior

   a) Which of the following fields are presented to the user or converted into a foreign format via gateway

         Reporting-UA 
	   mdn-gateway-field
	   original-recipient-field
	   final-recipient-field
	   original-message-id-field
	   disposition-field
	   failure-field
	   error-field
	   warning-field
	         extension-field

6) Interoperability Experience

Please list those implementations that are known to interoperate with this implementation.  Please describe what if any known interoperability problems are know with the MDN protocol and this implementation.

---

From: [email-masked]
Date: Fri, 16 Aug 2002 11:35:24 -0700 (PDT)

>    a) Approximately when was this feature introduced into a public release?

   SunOne Messaging Server, Sun Microsystems, upcoming release. (Much of this
   probably applies to earlier releases as well, but I tested things against
   the current code base for this report.)

   Integration of MDN support was done incrementally over a number of years
   so assigning even an approximate date is impossible.

>   a) Client sends disposition-notification-to header:  (Y/N)

   Yes, the Messenger Express client component has the ability to do this.
    
>        b1) Client sends request for proprietay options (describe)

   No, there is presently no way to request specific disposition options.

>   c) Message disposition header is placed in inner message when used with
>       message partial (Y/N/NA) Please indicate N/A if the UA or gateway does
>       not generate message partial constructs

   Yes, this this done when messages are fragmented. The opposite is also
   true: These fields are copied from the inner message to the new message
   while defragmenting.

>   a) Final MTA (Delivery process) copies ORCPT parameter from RCPT-TO
>      command into Original-Recipient header of message upon deposit

   This is done as long as the number and nature of the recipients
   permit it.

> 	   original-message-id-field

   Facilities for generating MDNs with all of these fields are built in to
   the product. However, at present the two primary uses are:

   (1) Displayed MDNs are generated by Messenger Express, which only produces
       final-recipient-field, original-message-id-field, and disposition-field.
 
   (2) Deleted MDNs are generated by the reject sieve action, which only
       produces original-recipient-field, final-recipient-field,
       original-message-id-field, and disposition-field.

> b) Which disposition modes are supported / generated:

   All of these can be generated and will be produced in practice.

> c) Which disposition types are generated

    Both displayed and deleted types are generated.

> d) Are any extension fields generated?

   Not at present.

> 	   original-message-id-field

   All of these fields can be displayed.

> Please list those implementations that are known to interoperate with this
> implementation.  Please describe what if any known interoperability problems
> are know with the MDN protocol and this implementation.

   AFAIK no interoperability problems have been reported.

				Ned