Comments:
1. Rather than define a MIME bodypart just for acks, I would like to see a
bodypart for delivery status reports in general. It could then be used for
nondelivery reports as well as for delivery acks (in the same message).
It needs to be able to hold multiple status messages (positive, partial, and
negative), human readable text, and also a returned-message. Something
like:
----------
content-type: multipart/delivery-report; boundary=foo;
message-id="<AA012345(_at_)wilma(_dot_)cs(_dot_)utk(_dot_)edu>"
--foo
content-type: application/delivery-status;
rcpt="moore(_at_)cs(_dot_)utk(_dot_)edu";
rcpt="nsb(_at_)thumper(_dot_)bellcore(_dot_)com"; status=successful
--foo
content-type: application/delivery-status;
rcpt="joe(_dot_)user(_at_)nowhere(_dot_)com";
status=failed
Message from postman.nowhere.com (MX for nowhere.com):
RCPT TO: <joe(_dot_)user(_at_)nowhere(_dot_)com>
550 <joe(_dot_)user(_at_)nowhere(_dot_)com>... Recipient unknown
--foo
content-type: message/rfc822
to: joe(_dot_)user(_at_)nowhere(_dot_)com,
nsb(_at_)thumper(_dot_)bellcore(_dot_)com
cc: moore(_at_)cs(_dot_)utk(_dot_)edu
from: moore(_at_)cs(_dot_)utk(_dot_)edu
subject: foo bar
message-id: <AA012345(_at_)wilma(_dot_)cs(_dot_)utk(_dot_)edu>
foo bar
--foo--
----------
2. I strongly prefer that any ack requests be implemented in the SMTP (or
other) envelope. Putting this stuff in the header is a opening a BIG can of
worms. In particular:
* When messages are auto-forwarded around from place to place, the envelope
addresses change while the header addresses (and especially the contents of
MIME body parts) do not change. The ack requests then become useless.
* It is necessary to mark such headers somehow once they are processed to
make sure that a message doesn't generate multiple acks as it is "delivered"
to lists and gateways. This violates a widely-held assumption that message
headers can be ignored by message transport. Acks-in-headers *requires* any
MTA that supports mailing lists to deal with an ack-request bodypart, either
because it wants to issue the ack when the message is expanded (almost
always the right thing to do). It can't simply forward the ack request to
the list members, because the membership of a list may be confidential.
* Finally, if ack-requests are implemented in the headers or in MIME, there
is no assurance that an ack will be generated, since many MTAs and UAs will
continue to ignore MIME. However, if acks are implemented in SMTP, the SMTP
negotiation for the ack can be used to determine whether the receiver SMTP
supports delivery acks. If not, an "partial" ack can be generated, which is
still more useful than no ack at all. With ack requests in SMTP, you have a
high probability of getting *some* useful answer to every ack request, that
can be processed mechanically.
Putting acks in SMTP also allows a mailing list exploder to "probe" a list
to determine whether list recipients are valid.
The SMTP extensions draft (soon at your local IESG) provides a means of
cleanly extending SMTP to support such a feature.
-Keith