Message Disposition Notification: Second request for implementat ion status

"Vaudreuil, Greg M (Greg)" <gregv@lucent.com> Fri, 16 August 2002 12:06 UTC

Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7GC6UT09011 for ietf-822-bks; Fri, 16 Aug 2002 05:06:30 -0700 (PDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7GC2xw08750; Fri, 16 Aug 2002 05:02:59 -0700 (PDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g7GC2rL02419; Fri, 16 Aug 2002 08:02:54 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19) id <QKNAABY8>; Fri, 16 Aug 2002 07:02:53 -0500
Message-ID: <54E40201497DF142B06B27255953F79723F765@il0015exch007.ih.lucent.com>
From: "Vaudreuil, Greg M (Greg)" <gregv@lucent.com>
To: receipt@cs.utk.edu, ietf-822@imc.org, vpim@lists.neystadt.org, IETF fax WG <ietf-fax@imc.org>
Subject: Message Disposition Notification: Second request for implementat ion status
Date: Fri, 16 Aug 2002 07:02:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>

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.