The newly established (July 1995) RECEIPT IETF WG is trying to define such an object, but there just isn't anything there yet.
Still, it makes sense to examine some of the properties of these objects in a little more detail.
In X.400, receipt and non-receipt notifications may include notifications of something being automatically forwarded, messages deleted because a mailbox subscription was terminated, or that the message was delivered.
Positive receipt reports come in two flavors: Automatic and manual, with the "manual" corresponding roughly to "the user pressed a button indicating that he has read the message", and "automatic" corresponding to "the UA threw the message up on the user's screen; probably he read it".
There is no mechanism to request either an automatic or a manual receipt report, but there is a flag in the report saying what kind of report it is.
The receipt report is passed through the messaging system as a normal P2 message, meaning (among other things) that unless the service provider peeks inside the message, the recipient will pay for delivery of the notification as long as it crosses a network that charges per message, even though it was requested by the originator of the original message; some new fields in the X.400 (88/92) P1 envelope were intended to provide marking facilities avoiding this problem, but I don't know if they are in widespread use yet.
Support for receipt notification is not universal in X.400 systems,
and rather spotty in gateways to non-X.400 systems; the functionality
is not required in the standardized profiles of X.400.
(However, there exist mail systems that handle it, for example GMail's X.400 gateway; this proves that it's not impossible, if you design the mail system with such functionality in mind!)
There were several reasons for this, including: