From: Bob Smart <smart(_at_)mel(_dot_)dit(_dot_)csiro(_dot_)au>
I am slightly concerned about proposals to split the Acknowledgement
work because I think it is important that there be a single uniform
format for Acknowledgements which is independent of whether they are
generated by MTAs or UAs or Gateways, and whether they are positive
or negative. Some optional features will be more likely to appear
in one sort rather than the other: for example negative Acks are
more likely to include the returned message in a message bodypart
of the Ack.
I agree with you on the need for a uniform format for Acknowledgements. The
822ext working group is probably a good place to discuss such things, since
its members are already familiar with MIME. Such discussion will provide a
good test of how well the MIME format adapts to extensions.
It is clearly a case of defining keywords for the obvious
Acknowledgements, and defining an IANA registration procedure for new
ones. Acknowledgements I would like to see defined initially include:
failure, delay, read, delivery, delay, conversion, plus a few more
subtle ones like unknown-delivery [meaning your message has been sent
to MTA/gateway which will not respect your request for Delivery Ack].
This doesn't mean we have to define any mechanisms for generating
these in the Internet context: they may be generated at gateways from
Acknowledgements coming back via some other mechanism in a non-smtp
mail environment.
Let's see...an ack should consist of
ack-type = one of (delivery, receipt, conversion, delay, ...)
ack-status = one of (success, failure, unknown)
ack-recipient = recipient address for which this ack is being generated
(optional) ack-reason = keyword (list TBD)
(optional) ack-msg-txt = human-readable text
An ack-message would contain one or more acks, plus the message-id from
the message being acked, plus an optional returned message.
I'd prefer that an ack-message contain acks for exactly one subject message,
rather than bundling several acks from different messages into one
ack-message.
The returned message should probably be of type message/rfc822, but this
causes some problems when it is necessary to return a 8-bit message (that
may contain encoded body parts) over an 7-bit path. I don't like requiring
whoever returns a message to take apart and re-encode a message, especially
since this might mask the reason why the message had to be returned in the
first place. (if it were being returned because of incorrect format). So
application/octet-string (!?) might be a better choice.
As Nathaniel says, delivery has no well defined meaning. However many
of us would find it useful, particularly for messages we know
have to go through things which are currently rather unstable like
X.400 gateways. I would like to add another definition:
A Delivery Acknowledgement gives exactly the same level of
certainty as the "250" response to the end of DATA when the
message is accepted by the final MTA (i.e. the MTA which talks
to the recipients UA).
That's one way of defining it. I would prefer that a Delivery
Acknowledgement be generated when any of the following occurs:
a) the message is delivered to a recipient's mailbox, ready to be
read by his/her UA.
b) the message is auto-forwarded; that is, an originally named
recipient is removed from the message envelope and replaced
by one or more new recipient addresses. (the ack should optionally
include the forwarding addresses)
c) the message is sent to a distribution list. This is similar to
auto-forwarding but may involve additional message processing to
see that errors get reported to the list maintainer, batch up
several messages into a digest, etc.
d) delivery fails for any reason
e) the message gets gatewayed, relayed, or forwarded into an environment for
which delivery reporting back to the origniator cannot be arranged.
f) the message is processed in any manner that removes the capability
to generate a Delivery Acknowledgement to the sender.
Once a delivery acknowledgement occurs, the message envelope is changed
somehow so that another acknowledgement is not generated for the same
recipient.
Keith