Hi Bob, -- And the rest of IETF-822.
I will agree that Acknowledgment, Return-Receipt, Delivery
Notification and Receipt Notification are important topics, if for no
other reason than that many people believe in them very strongly
(though often wrongly and with agreement on what they mean). Also,
X.400 offers related notification service controls on a per recipient
basis, so we need to deal with RFC-1148 gateway mapping. We also need
to deal with the fact that other mail systems attached to the internet
have similar services.
I endorse the X.400 Delivery and Receipt Notification semantics and
terminology. I recommend that we adopt them for our discussion
purposes. I also refer you back to my prior messages on the semantics
of these kinds acknowledgements. If you want fresh copies, I will be
pleased to forward them to individuals.
Now then, I believe that these issues have no place in the SMTP (P1)
Level of mail transport, unless you are trying to convert MAIL from
being a DATAGRAM service into some kind of CIRCUIT service. Circuit
services guarantee end to end delivery, but datagram services do not
offer end to end guarantees within the service definition.
There is a school of thought that is residual from the TELEX era,
where the service started out as a circuit service, and the
introduction of store-and-forward switches threatened to turn TELEX
into a datagram service, so great effort was put into making TELEX
store-and-forward retain its appearances of being a circuit service,
by means of having each "MTA" (store and forward switch) hold a copy
of the original until it got back confirmation from the next switch
that it had been delivered to the end point. This of course cascades
if a message is store-and-forward-switched more than once! It all
gets very complicated in the implementation of switches, with the
required correlation of all the pending actions and notices that
depend on forward switches.
X.400 does not (and SMTP CERTAINLY DOES NOT) have any CIRCUIT service
ancestry, and I certainly hope that we are not now going to try to
convert either of them from DATAGRAM to CIRCUIT service.
It is left to other higher level services to provide error detection
and correction service elements. (e.g., If you want me to acknowledge
receipt, just ask me to do so by reply mail!) The NonDelivery
Notification is the only exception, and it is easily provided at the
MTA level by returning to sender, without more protocol information
than the address of the sender.
I believe that X.400 recognizes this (even though many PTT ADMD folk
{e.g., IAOG with its TELEX memory} do not), and thus X.400 only has
Notification indicators in Recipient OR Addresses related to P2 level
actions.
That is, the notification request indications are "per recipient" and
are only carried in the P1-recipient-address service element so it
will be easy for the delivering MTA to deal with the required actions
when they take place upon delivery to the receiving UA, at the
boundary between the delivering MTA and the receiving UA, or upon
failure to deliver at a point short of the delivery point. I claim
that the only reason for any MTA to care about it, short of the
delivery point is if the Recipient OR Address contains a "Do not issue
a Non-Delivery Notice upon failure", or "Do not return Contents upon
failure". Otherwise, as with SMTP, a NonDelivery notice would be
mandatory, with full content return, without need of any per-recipient
indications attached to any addresses.
Indeed, in X.400, the Receipt Notification is an OPTIONAL UA service
element, and is to be generated only by the UA, since the MTA cannot
have any way to know whether a recipient has seen any given message or
not, and it is (implicitly) recognized in the standard that the
recipient may demand to be allowed to control the (authorized) sending
of a "Receipt Notification".
Beyond delivery failure notifications, no MTA actions are assumed or
required between submission and delivery actions, and intermediate
MTAs have no responsibility beyond the requirement to pass all
addresses forward without any address rewriting. This means that the
per recipient information remains with each P1 recipient address to
the end.
So, casting this into an RFC-1148 framework, our problem is to find
some way to carry the same X.400 semantic meaning in the RFC822
recipient address headers, on a per recipient basis.
I do not easily see how to do this on a per recipient basis, since
there is no provision in the RFC-822 recipient address headers for
such information. Upgrading to carry it is going to be tough to do.
Also, there is no provision for carriage of any non-address
information in the SMTP envelope's recipient addresses, but this is
secondary as long as there is no way to lodge this information in the
RFC-822 headers.
Are you suggesting that we extend the RFC-822 address to look more
like the X.400 OR-Address structure which has the means to carry
per-recipient indicator information? And then find a way to carry it
in the SMTP envelope address of each recipient?
Or, are we talking about ways to add a new RFC-822 header with a list
of recipients for whom Delivery and Receipt Notification Request
Indications are carried? If this latter, how do you propose to keep
this list in synch with the SMTP proclivity for rewriting recipient
addresses? Would you also ask that they also rewrite the Notification
Request Indication addresses in some synchronous way? I see this as a
real nightmare. SENDMAIL config.cf Rides Again!
However, given this layout of the problem, I am inviting comments on
how we might address these issues in an RFC-22 extension. I don't
know if this belongs in RFC-XXXX or in another related RFC.
I do not want to delay RFC-XXXX if it can be avoided. Best...\Stef