Bob,
I think some confusion about the transport model persists:
We don't have to do anything new to have Acknowledgements in the
Internet. Negative Acknowledgements (bounces) are common.
EMail Delivery Failure (or Delay) notices on the Internet are entirely
at the whim of individual MTAs. There is no spec or requirement
for the behavior. Therefore, there is no way for the originating
UA or MTA to detect one of these returning error notices and do anything
with them.
I think that we can look at the existing systems' behavior, to see if
any behave the way we want (or don't want) and design the standard
mechanism accordingly.
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
To the extent that we can succeed at your goal, I think it would be
VERY good. Nonetheless, I think there should be enough parametric
distinction (e.g., the sub-type name differences I mentioned yesterday)
to keep the domains of the different acks separate. I.e., same format
but different "address space".
Acknowledgements I would like to see defined initially include:
failure, delay, read, delivery, delay, conversion, plus a few more
Good start. Let me encourage you to divide the list into sub-components,
according to the part of the system that is generating it.
As Nathaniel says, delivery has no well defined meaning.
One of our tasks is to provide precise definitions. This would be
a service to the community, I believe.
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).
In fact, it is probable that a Delivery Acknowledgement can/should provide
quite a bit more information. Many (most?) SMTP servers stuff the incoming
message into a local queue, before effecting final delivery to the local
user. Hence, there is an additional "hop" for a message, even when the
SMTP transfer is to the final, destination machine.
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.
My suggestion is that an MHS Delivery Notice be end-to-end (at least
within the RFC 822 world) rather than meaningful only for one SMTP hop.
It is not unreasonable to view SMTP as being like a link-level transfer
protocol and RFC 822 as being an end-to-end "protocol" like TCP. Note
that it is common for link protocols to have ack/retransmission schemes,
but we still need to have an end-to-end mechanism, in TCP, to cover the
cracks that exist in between link protocols.
Delivery Acknowledgement cannot be done in the Internet context without
modifications to transport using the SMTP extension system.
That provides one-hop acks, whereas 822-, or MIME-, based acks will
have a much broader reach.
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
Assuming that we, as a group, do not surface major objections to the
X.400 model, I agree with you. (I don't expect we will -- and I think
we should make every effort to be consistent with X.400 -- but the Internet
always reserves the right to deviate...)
Dave