From: Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com>
To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Subject: Re: MIME types for ack[-request]?
1. I'm not sure a new subtype of multipart is necessary -- what's the
advantage over just using multipart/mixed in this context?
I see it as useful to be able to mark a *message* as a delivery report
rathern than an IPM. Especially if you want to gateway delivery reports
into the X.400 world.
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.
Well, what I really want is for the human-readable text to be somehow
associated with the envelope address(es) that caused the error. Whether the
body part is text/* or application/* doesn't matter much to me.
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.
Or what you want the ack to be used for. If I want an acknowledgement
that a message was *read*, obviously that's a UA function and the request
goes in the header. If I want an ack that the message was *delivered*,
that's an MTA function. Personally, I think we need both kinds of
acks.
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.
Depends on what they are being used for. Transport-level acks are used to
check the health of the message transport. If I maintain a mailing list,
all I care about is that my messages get to the recipient's mailbox. If the
recipient never reads them it's no concern of mine.
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.
Well, in my experience, that's not what you get, at least with the US Postal
Service. What you get is a piece of paper signed by someone at that
address. It tells you that the Postal Service did its job, but doesn't
really certify that the named recipient got the message.
I think we need a similar goal for email acks. -- NB
I think we need both kinds of acks.
Keith