Bob,
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).
I'm not really comfortable with this. This is probably not the best wording,
but how about defining delivery as the act of sucessfully transfering a
message to an agent specified by the recipient address? Not terribly
precise, but should be pretty close to the mark. I would then use this
as the basis of defining a delivery acknowledgement in a protocol independent
fashion. The X.400 definition (from X.400/Annex B) provides a pretty
reasonable starting point here I believe:
Delivery Notification
This element of service enables an originating UA to request that
the originating UA be explicitly notified when a submitted message
has been successfully delivered to a recipient UA or Access Unit.
The notification is related to the submitted message by means of
the message identifier and includes the date and time of delivery.
In the case of a multi-destination message, the originating UA can
request this element of service on a per-recipient basis.
When a message is delivered after distribution list expansion, then,
depending on the policy of the distribution list, the notification
can be sent to either the list owner, the message originator, or both.
Delivery notification carries no implication that any UA or user
action, such as examination of the message's content, has taken
place.
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.
This is true, but all you know about the remote end is that it is somewhere
on the remote side - possibly queued for delivery. You cannot infer that
delivery has actually taken place from this.
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?
Not only do I believe that it is not necessary, but believe that in any
environment which uses a mail relay or gateway, that it will not provide the
desired functionality.
2. If instead you believe that we shouldn't guarantee any sort of Ack when
the user requests a Delivery Ack then
Guarantees on ack's are a different set of issues as opposed to what
mechanisms can be utilized to provide the final delivery notification back
to the originator. While I believe that it is possible to provide a good
delivery notification mechanism (but not using SMTP extensions), it may be
difficult to guarantee conformance to the new mechanism 100% of the time.
I see the goal of making delivery notifications work across multiple types
of transports to take a much higher priority over an implimentation that
works most of the time in a very restricted environment (direct originator
to recipient host SMTP).
a. Do you agree that this is less functionality than you get in Ack
systems in other mail systems such as X.400?
I see no reason why we cannot come to agreement on a set of mechanisms that
provide as much, if not more functionality as any mail system that operates
in a heterogenous environment, including 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?
I believe that 822 extensions could be used to accomplish this fine, and
should be a major goal of this group.
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.
I completely agree with this which is one of the main reasons that I keep
referencing the X.400 recommendations in this area. Unless there are good
reasons for doing otherwise, I believe we should look at how things are
done with X.400 as a starting point, keeping in mind what it would take to
make the kind of interworking you reference above possible with 1:1 mapping.
Regards,
Tim Kehres