ietf-822
[Top] [All Lists]

Transport involvement in Delivery Acknowledgements

1992-03-27 18:08:06
Since there has been a claim to cover Acknowledgements in the
ietf-822 framework, I think it would be very useful if we could 
decide in this wider forum whether Delivery Acks can ever be 
implemented in just rfc-822 extensions, or whether transport 
involvement is needed. Probably the details should be discussed
in a separate forum.

Private discussions with Tim Kehres have focussed my mind on 
this issue, and it is best seen in terms of a specific example.
I know I'm not the best writer in the world, but I hope people
interested in this issue will consider this specific example
and explain to me how they see this specific example being handled.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Suppose that a message with a Delivery Notification request has
to go the following route:

 U1 --> X1 --> XS --> S1 --> S2 --> U2

Where U1 is the sender's UA, U2 is the recipient's UA, X1 is an X.400
MTA, S1 and S2 are SMTP MTAs and XS is an X.400 to SMTP gateway.

Now in my scenario (and Keith's) what would happen is this

 1. XS would see the delivery notification request. 
 2. When it connects to S1 it will say "will you give a Delivery Ack".
 3. If S1 says yes then XS has completed its responsibilities.
 4. If S1 says no (or "Command Unrecognized") then XS will send back
    an Ack that says "Can't arrange Delivery Notification".
 5. S1 does the same when talking to S2: if S2 agrees to the DN request
    then S1 has done its duty; if S2 doesn't agree then S1 has to send
    back what I call a neutral (don't know) Delivery Ack.

You can see that at each stage the MTA or gateway won't pass the message
on without also passing on the responsibility for a Delivery Ack. So
the sender is guaranteed to get either a delivery or a non-delivery
notification. The only way he can get no response is a catastrophic
failure of the mail delivery process (e.g. disk crash of queue area).
That's what getting _NO_ response to an X.400 message with a Delivery
Notification Request MEANS.

Now suppose we try to do this without SMTP co-operation. In this
case XS simply adds an appropriate header before sending the message to
S1.

BIG QUESTION: How did XS know that U2 (or S2) was going to honour the request
for a Delivery Notification?

Because if XS doesn't know this it didn't perform its clear duty to ensure
that the sender gets some sort of delivery report.

If we could wave a magic wand and change everything at once then the 822
based approach would work. However we can't even _consider_ that as an
option. We need to affirm that existing systems are not broken. So we need 
to negotiate how far we can get. Hence the need for transport involvement.

To reiterate: every mail agent that accepts a message which comes with
a request for a Delivery Ack has to do one of 3 things: (a) pass on the 
responsibility for the DN-request; or (b) decide that it has done final 
delivery and return a DN; or (c) decide that it can't do final delivery 
and return an NDN. Doing any of those 3 completes the obligation. The key
problem is to avoid the situation where the sender gets nothing in a
repeatable fashion [getting nothing as a result of a one-off disaster
is ok].

Now you might say: we don't want _guaranteed_ Delivery Acks. It is 
important to realise that in that case you are proposing something
with an order of magnitude less functionality than exists in X.400
and other mail systems. In particular such optional Delivery Acks
would not be useful to someone writing an X.400-smtp gateway. It would
be nice if an expert like Ned Freed or Steve Kille would confirm my
feeling on this matter.

Bob Smart