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

> 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?

   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.

> 2) MDN Requesting user agent behaviors

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

   Yes, the Messenger Express client component has the ability to do this.
    
>   b) Client sends disposition-notifications-options header (Y/N)
>        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.

> 3) Final MTA behaviors

>   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.

> 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

   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:
> 	Manual action
> 	automatic action
>             MDN-sent-manually
> 	MDN-sent-automatically

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

> c) Which disposition types are generated
> 	displayed
> 	deleted

    Both displayed and deleted types are generated.

> d) Are any extension fields generated?

   Not at present.

> 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

   All of these fields can be displayed.

> 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.

   AFAIK no interoperability problems have been reported.

				Ned