Hmmm, the first part of your comment (delivery status reports) is moving
in a good direction, I think. A few comments:
1. I'm not sure a new subtype of multipart is necessary -- what's the
advantage over just using multipart/mixed in this context?
2. I'd prefer to keep the human-readable text OUT of the
application/delivery-status entity body. Why? Because if we leave it
there, it may never be seen by users whose MIME agents don't implement
that type. If we've got a multipart message anyway, why not put the
prose in a text/plain (or even text/richtext) entity? That might make
the results at least somewhat meaningful to a larger set of recipients.
As for the question of acks in SMTP versus acks in MIME bodies -- I
think this comes down to a question of what you want acks to mean, as I
alluded to before. Any SMTP-level ack is going to tell me nothing more
than "some piece of software thinks the mail was delivered". But one
MTA's notion of "final delivery" may be another's notion of "where I
pick it up from to pass it on." In the general case, alas, the only
certainty is the ack that says "the human user actually saw this and
indicated a willingness to send an ack". That's why I think that any
transport-level acks are fundamentally pretty useless -- they will often
convey a false sense of security for messages that may never really have
even been delivered. Think about return-receipts in the physical mail.
You don't want a piece of paper in which the post office says "we
dropped the mail in what we're pretty sure was the right mailbox." What
you want is a piece of paper signed by the recipient. I think we need a
similar goal for email acks. -- NB