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.