Further, your model requires complete support, along an entire
path, when it may be just as likely that an intermediate node does
not support acks, but the final node does.
Well actually, historically, I have proposed a hybrid model which
does not have this restriction. Keith Moore supports doing it
only in transport. He has some good arguments, but I believe
they can be overcome.
So basically I agree with everything in your message as far as it goes.
The key problem is how do you do _guaranteed_ delivery Acks. What
does this mean? It means that if you ask your UA for a Delivery Ack
then you will definitely [barring catastrophic disaster in the
mail system like a disk crash] get one of: (a) a Delivery Ack; or
(b) a Non-delivery Ack (a bounce); or (c) A message saying "The
message is going beyond the realm where I can guarantee a Delivery
Ack, though you may still get one".
If you ask for a Delivery Ack and you get _nothing_ back then it
should mean something. Perhaps there was a one-off disaster. You
try again. If you still get nothing then something along the route
is badly broken and you get the net-gurus to look into it.
A system of optional Delivery Acks where getting back nothing has
no special meaning is much less useful. And it fact it is so
different to Delivery Acks in other systems, like X.400, that you
could not use such an optional Delivery Ack to gateway a mail
message with a Delivery ack request from X.400 to the Internet.
It is fine for intermediate transfer agents to notice
the request, on the envelope, and try to improve the reliability of
the response mechanism, by asking the next hop if it supports the
function, but a negative response does *not* necessarily mean that
the final MTA won't support it.
And what I am saying is that we need to formalize the way one intermediate
transport agent asks the next one for support of the Delivery Ack
request. If the next hop won't support it the user needs to know that
that is as far as the message could get with the guarantee attached
to the Delivery Ack.
To go back to your phrase "along an entire route". Long discussion
in the ietf-smtp group a while ago came to the conclusion that this
is not a real problem in the Internet. The reasons why a message takes
multiple hops in the Internet are few in real life [yes you can
source route but that is deprecated]. Sometimes hosts are configured
to send mail to a mail hub instead of following the MX. In this case
if the sending host supports Delivery Acks you can be sure that the
mail hub it uses will also. At the other end the receiving host may
have an alternative MX, usually the local mail hub at that end. You
can be sure that if the receiving end supports Delivery Acks then it
will choose its alternate MXes to also support them. So I don't believe
there is a serious problem in fact. There will be supporting and
non-supporting systems but there will not be problems from mail
going into the non-supporting realm then coming back.
Bob Smart