Internet Mail has had the latter since day one, often including the return of the offending message. Unfortunately, there was no standard format of these notifications, leading to a mess of incompatible and incomprehensible error messages, usually in English, floating around. (Anyone who has worked as a postmaster will recognize the style of a letter that starts "Dear postmaster; I don't understand any of this.....")
The X.400 notifications, on the other hand, are a terse binary structure containing a very well-defined format, or to quote one of the more misguided (but amusing!) attempts to map these messages onto Internet Mail:
Your message was relayed through an X.400 network, which issued a "delivery report". The syntax of these reports was devised to fit the needs of X.400 user software; it is a terse binary structure. Our gateway is making its best effort to present this information in an understandable manner; we apologize for its esoteric structure.(I won't attribute the quote without permission from the software writer or vendor....)
The error codes defined by X.400 are numbers, and there is a little room for carrying further information; no "session traces" here. The error codes capture some, but not all, the possible error situations that may lead to the non-delivery of a message.
Starting with X.400/88, there are also extension fields where it is possible to add information not defined in the standard itself.
How much of this information it makes sense to show to the user is up to the UA vendor; there is no equivalent to the "view the non-delivery report" that is the only option in Internet mail.
Internet mail was defined rather loosely in this respect; there are so many implementations that have the same program running on "both sides of the boundary" that things tend to be a little bit fuzzy. (Are aliases expanded by the MTA or the UA? Is the .forward file of Sendmail part of the UA or the MTA? Is mailing list expansion "delivery" or not?)
Once X.400 met the real world, these things tended to occur there too (the early EAN system actually issued delivery notifications when the user accepted the message, not when it was put into the user's queue), but generally, X.400 seems to have reached a consensus on where "delivery" occurs that works reasonably well.
Once the X.400 system gateways into a non-standard mail system, all bets are off, of course; many gateways will tend to declare the message delivered once it passes the gateway, whether that is strictly true or not, and some implementations of fax gateways will actually send you two delivery notifications; one when the message is delivered to the gateway, and another when the fax is transferred (or not). (This may be part of the AU spec, or it might be untrue. Anyone care to comment?)
Anyway, the NOTARY group was chartered (in 1994; anyone remember when?) to define formats and procedures for Internet mail functions that allowed both a standard error reporting format and a mechanism for requesting positive delivery reports. The results are (August 1995) handed to the IESG for approval and publication as RFCs; there are multiple implementations being worked on.
It will, however, be a long time before all Internet systems support this function (if ever), even though the ubiquitous Sendmail is one of the early implementations.
For further details of the NOTARY efforts, see the NOTARY status page.
The IETF MIXER working group that is rewriting and updating the X.400/Internet mapping specifications is taking careful notice of NOTARY, so that it will try to achieve a world in which positive and negative delivery reports can flow between the two E-mail protocols.