To: Bob Smart <smart(_at_)mel(_dot_)dit(_dot_)csiro(_dot_)au>
Subject: Re: Transport involvement in Delivery Acknowledgements
From: Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
Bob,
Well actually, historically, I have proposed a hybrid model which
does not have this restriction.
Hybrid seems the way to go. Encode an end-to-end request/reply in
RFC 822 headers, and upgrade SMTP to do per-hop checking of support
for the facility. (Given the possibility of intermediate non-support,
while still having recipient system support, we might want to
distinguish how to handle non-support by intermediate
systems: don't send onto next hop, notify originator but send to
next hop, send and don't notify.)
If you put the information in *both* headers and SMTP, which one is the boss?
If we take a hybrid approach, the information should go *either* in the SMTP
envelope or in the header, and never in both places at the same time. If you
forward to an SMTP that doesn't support the capability, you put the request
in the header, return a partial ack, and hope for the best.
This is similar to the Return-path header vs. SMTP MAIL FROM address. The
return-path header is supposed to be used whenever the message isn't in the
SMTP world. However, if a message passes in and out of the SMTP world, it
can get multiple Return-path headers which may conflict with one another.
(So you probably should strip out a Return-path header when putting a message
back into SMTP, but that isn't standardized behavior.)
I also tend to think that a hybrid approach is the most likely solution, but
it's likely to be pretty messy, involving lots of subtle changes to existing
MTAs. (I could justify this statement, but the margin is too small...)
The key problem is how do you do _guaranteed_ delivery Acks.
This is, unfortunately, a very simple question to answer: You don't.
We have 20 years of history in the operation of Internet email, where
one of its prime charcteristics is only minimal conformance.
I think that we can, should, and must do better, but the concept of
"guaranteed" levels of service, in a system with highly distributed
and independent administration, much of which is "casual" rather than
professional, suggests that we will not attain your goal anytime soon.
As Internet EMail moves towards more commercial styles of operation, much
as the underlying IP Internet has, then your goal may be attainable. My
own guess is that that is at least 5 years away, perhaps more. (And I'd
be delighted to be wrong.)
The question is whether non-guaranteed delivery acks are useful. I believe
that reliable delivery acks are useful, useful enough that we should upgrade
Internet mail to have this capability. This is going to require changes to
the message transport system, regardless of whether the information is
carried in STMP or 822. I also agree with you that it will, in all
liklihood, take several years for such facilities to be useful to users. In
the meantime, however, they may be somewhat useful to postmasters, and users
will benefit from better service (without realizing it).
For those who think that the end-to-end reliability mechanism of TCP is
not that big a deal, I'll mention that I witnessed a very serious
commercial impact, involving corruption of file data, near loss of a
major account, and consumption of several weeks of time among senior
technical staff at one company, specifically because of such an error.
The products did not use a protocol that had end-to-end reliability,
so the mis-behaving hardware interface couldn't be detected in any
trivial way, nor could the corrupted data.
Once again: Model email as a packet net and many technical decisions get
extremely easy.
The end-to-end argument is attractive. But in the case of TCP, you have a
protocol that defines particular responses to the receipt of certain types of
messages. This is not true for 822 -- neither the message transport, nor any
delivery agent, nor the recipient's mail reader is under any obligation to do
anything in response to any header field, and can treat the headers as part
of the message text if it wishes.
If we change that assumption, we are talking about a different protocol, no
matter how much it may look like 822. If we define a new message format we
can give it all the features we want. Then, any mail reader that claims to
understand the new message format can be expected to support the features of
that protocol. But a lot of the arguments for "do this in 822" seem to
assume that a lot of those email systems that currently use 822 headers will
be upgraded to support generating delivery acks. I am skeptical, because it
appears that much of the 822 support in the non-TCP-internet world amounts to
"we happen to put our messages in this format, but it's not used for
anything".
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.
Hmmm. Hadn't thought to specify the semantics as making the ack
request optional, merely to tolerate current operational realities,
in order to provide SOME utility. (Hidden agenda: If people start
supporting the function, then they are likely to provide, ahem..., errr...,
"feedback" to those who do not.)
Yes. I think there is general agreement, even on this list, that support
for delivery acks in receiving UAs/delivery agents must be optional.
...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.
Bob, this is flawed in two, fundamental ways: First, multi-hop
configuration (e.g., mail hubs) are *far* more prevalent and essential
that your statement implies. Also, I strongly suggest that we start
thinking of Internet email as something that reaches much farther than
SMTP/TCP/IP, since there are several other, major services that use
Internet email objects (rfc 822) but not Internet transport protocols.
This means at least one extra hop, to relay between the environments.
My experience is also that mail hubs are very prevalent. The most common
case appears to be a mail hub that provides email connectivity between the
IP-internet and a private network. I do think Bob's argument is relevant,
however, in that if you want delivery-ack services for any of your end-hosts
on your private network, then you will make sure that the mail hub/gateway
supports those services if such support is necessary to make delivery acks
work.
Second, the "it will support the service, too" argument goes back to
relying upon an independent series of link-level mechanisms, with no
upper-level, end-to-end "glue".
Yes, and this is indeed a thorn. An end-to-end service is definitely
preferable to a hop-at-a-time service if we can manage to provide it in a
reliable fashion.
But which is less reliable: a hop-at-a-time service in which each hop
receives assurances that the next hop supports the service before
transmitting responsibility for that support, or an end-to-end service in
which there is no assurance that the remote end supports the protocol at all?
Best regards,
Keith