First a definition.
An Acknowledgement is an rfc-822++ message giving some information
about the status of some previously sent message.
We don't have to do anything new to have Acknowledgements in the
Internet. Negative Acknowledgements (bounces) are common. Some
software also generates delay Acknowledgements ("Your message has been
delayed for 1 day, will keep trying for 2 more days"). It is also
quite possible for positive acknowledgements to enter the Internet.
For example I might send an X.400 message from an X.400 UA containing
a request for delivery notification. When the delivery notification
comes back it might be auto-forwarded to an smtp address.
Of course Acknowledgements don't have to be in a well-defined
software-interpretable format. However existing messages in random
format are going to have to continue to be interpreted by the
human recipient. We must define and move to a format which will
allow the user's mail user interface to automatically associate
Acknowledgements with the copy of the original so the user can
easily see the status of messages that he has sent.
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.
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.
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).
This doesn't really define it, but it sets it equal to another
undefined quantity which we all have an intuitive feel for. The point
is this: in a very simple tcp/ip environment (with no MXes except
pointing to the ultimate destination) you know the message has got to
the recipients machine when it has left your queue. What we want from
Delivery Acknowledgements is for them to have exactly the same
level of certainty about delivery that you get from the message
being delivered by SMTP in the simple environment. I feel that
putting it this way should make Delivery Acknowledgements intrinsically
uncontroversial. I hope so. Note that this has a clear implication
in regard to the handling of forwarding and list explosion.
Finally I would like to strongly support Keith Moore's view that
Delivery Acknowledgement cannot be done in the Internet context without
modifications to transport using the SMTP extension system. One of
the last things I sent to the ietf-ack group was a challenge to those
who only want UA-level changes, and I repeat it here and encourage
you to respond to the challenge or accept the fact that Delivery
Acknowledgements require SMTP change of some sort:
I ask the people who don't want even an optional
extension to SMTP to answer the following:
1. Do you believe that SMTP involvement is NOT necessary to ensure that the
the originator [who has requested a Delivery Ack] gets some sort of
positive or negative Delivery Ack?
2. If instead you believe that we shouldn't guarantee any sort of Ack when
the user requests a Delivery Ack then
a. Do you agree that this is less functionality than you get in Ack
systems in other mail systems such as X.400?
b. Do you agree that this optional style of Delivery Ack could not be
used by an X.400 gateway to implement the X.400 Delivery Notification
request?
One of the key requirments of an Internet Mail Acknowledgements system
is that it be compatible with X.400. Not only should X.400 (N)DNs
be convertible to/from rfc-822 Acknowledgements without significant
loss of infomation, but messages containing request for delivery
Acknowledgement should be able to pass through gateways, instead of
the current system where the X.400-smtp gateway has to throw up its
hands and return a message to the X.400 originator saying "You asked
for a Delivery Notification but I have had to send your message to
the SMTP world where such things are not handled". I hope some of the
X.400 gurus like Ned Freed, Steve Kille or Marshall Rose can shed
some light on the practicality of this requirement.
Bob Smart