Summary

  • RFC 1865 proposed replacing the transmission path between established EDI systems with Internet mail and described direct SMTP delivery to a partner’s system as assured. It retained bilateral trading-partner agreements and did not equate arrival with commercial acceptance.
  • RFC 1767 preserved the syntax and semantics of EDI objects while adding MIME carriage. Later RFCs added signed MDNs, original-message correlation and a returned content MIC, but kept successful processing and transaction validity separate.
  • The honest receipt ladder is SMTP acceptance, mail-system delivery, cryptographic receipt, EDI processing, application acknowledgement and commercial decision. Each step needs its own evidence and authority.

An assured arrival with an unfinished transaction

Picture a supplier sending an electronic purchase order to a buyer in 1996. The envelope leaves the supplier’s EDI system, crosses an Internet mail path and reaches a server operated by the buyer. The sender can show a successful SMTP exchange. Has the buyer accepted the order?

The answer is still no. The delivered object may be malformed, duplicated, mapped to the wrong partner, rejected by an EDI translator, held for an application rule or declined under the commercial agreement. Even a technically perfect object can ask for a price, quantity or delivery date the buyer will not accept. Transport has completed one job. It has not acquired authority to perform the next.

RFC 1865, published as Informational in January 1996, was written as a FAQ for an EDI community that might not yet know the Internet. Its central move was pragmatic: keep the business applications and EDI translation systems, and replace the communications components with Internet modules. It described a dedicated SMTP connection as delivering directly to a trading partner’s system, with delivery assured, while noting that ordinary store-and-forward integrity depended on intermediary systems.

That claim belongs to a precise noun. The partner’s system received mail. The FAQ did not say that the business application processed the interchange or that the transaction became valid. Reading “assured” as commercial closure would make a mail server decide a question the document still assigned to partners.

EDI was narrower than electronic commerce

RFC 1865 defined Electronic Data Interchange as application-to-application communication of standardized business information. It distinguished that from the wider category of electronic commerce, which could also include human communication, money transfer and shared information resources.

The distinction prevents a modern shortcut. An EDI envelope can be a purchase order, invoice or shipping notice, but the fact that it is standardized does not cause payment, fulfilment or assent. The interchange is an input to a business process. The process has actors, policy and consequences beyond message transport.

The RFC also kept bilateral trading-partner agreements. Existing agreements could be adapted to use Internet addresses instead of proprietary mailbox names. EDI-consent content, as RFC 1767 made explicit, was available only when the parties had an express bilateral agreement.

This is the institutional boundary inside the technical story. Internet protocols could make carriage interoperable. They could not decide who was authorized to bind a company, what counted as a duplicate order, which acknowledgement was dispositive, how long evidence had to be retained, or which jurisdiction governed a dispute.

MIME replaced a transmission component, not commercial meaning

RFC 1767 specified MIME content types for EDI-X12, EDIFACT and bilaterally agreed EDI-consent objects. Its process diagram is more revealing than a broad claim that “EDI moved to email.” On the sending side, a business program produced data, an EDI translator created the interchange, a MIME processor enclosed it, and mail submission plus SMTP carried it. The receiving path removed the MIME wrapper, passed the EDI object to a translator and only then reached business processing.

The RFC said it changed neither the underlying EDI syntax nor its semantics. It also supplied no security mechanism by itself. MIME typing answered what kind of object the bytes purported to be and how it could travel through Internet mail. It did not prove that the X12 or EDIFACT content was valid, that the named partner sent it, that it survived unchanged, or that the receiving application accepted its business terms.

This is a recurring Internet pattern: a common envelope removes a connectivity barrier, and observers mistakenly promote the envelope into a verdict about its contents. RFC 1767 was careful not to do that. Only the transmission components were substituted.

SMTP’s receipt stopped at the mail boundary

SMTP contains several moments that can sound like delivery. A relay can accept responsibility for a message. A final server can accept a recipient and message data. A store can make the message available to a user agent. RFC 5321 treats successful completion as transfer of responsibility under the mail protocol; it does not define a buyer’s commercial response.

The failure cases show why vocabulary matters. A sender might receive a positive SMTP reply while the EDI user agent later reports a syntax failure. A message can arrive twice after a timeout and retry. A server can route by an address that identifies a mailbox but not the correct trading-partner profile. A cryptographic check can succeed while the certificate maps to an actor without purchase authority.

An operational record must therefore preserve which boundary emitted each receipt. “Sent,” “accepted” and “delivered” are incomplete without an actor: accepted by the sending relay, receiving mail transfer agent, EDI gateway, translator, business application or authorized commercial process.

Signed receipts constructed better evidence

By 2002, RFC 3335 described a fuller Internet EDI security model. The message could be signed for integrity and authenticity and encrypted for privacy. A Message Disposition Notification could return the original message identifier, a Message Integrity Check calculated over the received content and the receiving partner’s signature.

Those components answered distinct questions. The message identifier correlated a response with an earlier send. The returned MIC let the sender compare a digest of what the recipient said it received with the sender’s record. The recipient signature made the response attributable under the relevant key and certificate policy. Sender verification completed a cryptographic loop.

RFC 3335 located non-repudiation of receipt as a legal event only after the sender verified the signed receipt. Even this stronger wording did not make the protocol a universal law. A signature needs a valid path, an applicable policy and an authorized signer. Evidence can support a legal conclusion; it does not eliminate the institution that makes the conclusion.

A signed MDN could report failure

RFC 4130, the AS2 specification, made the separation impossible to ignore. When a signed receipt was required, the recipient was to return one even when content processing failed. The disposition field carried the failure.

That is a powerful design choice. If a receipt existed only for successful business processing, silence would mix together network loss, recipient outage, signature failure, syntax rejection and policy refusal. A signed negative disposition instead provides evidence that the recipient reached a particular failure state. The receipt is valuable precisely because it does not pretend the transaction succeeded.

RFC 4130 also said that when an agreed signed receipt was required but not returned, the trading partners had to resolve transaction validity; the transaction would probably not be considered valid. The protocol supported evidentiary requirements, but it did not define non-repudiation of receipt because that remained a business or legal requirement.

The result is not ambiguity by accident. It is a designed division of labour. AS2 can produce a signed, correlated statement about received content and its disposition. The partners decide what that statement means for retries, order status, liability and remedy.

Display was not understanding

The generic MDN specification in RFC 3798 adds another useful warning. A recipient may ignore a request for an MDN. And a displayed disposition does not guarantee that a person read or understood the content.

That limitation matters even in automated EDI. The temptation is to turn the most advanced available receipt into the final one: SMTP reply becomes delivery; MDN becomes processing; signature becomes authority; display becomes comprehension. Each promotion discards a remaining actor.

The safer model keeps six records:

  1. the sender submitted an exact interchange;
  2. the mail system accepted or delivered it;
  3. the recipient returned a correlated, possibly signed disposition and MIC;
  4. the recipient’s EDI machinery parsed and processed it;
  5. the business application issued its own functional acknowledgement or status;
  6. an authorized commercial process accepted, rejected or amended the transaction.

Not every arrangement uses all six artifacts, and names vary across standards. The invariant is that evidence from one layer cannot silently exercise authority at the next.

Distributed transport did not erase bilateral governance

RFC 1865 contrasted the Internet with value-added networks and described distributed directory service plus cooperative routing and address resolution. It also suggested redundant providers and mail servers for reliability. EDI activity itself did not require central Internet coordination, even though obtaining and operating Internet connectivity did.

This changed the shape of dependence. A proprietary mailbox operator no longer had to stand at the centre of every exchange. But decentralizing transport did not make trading relations permissionless. The address, content convention, security choices and consequences of a receipt were still arranged between counterparties.

That combination is historically important. Open carriage expanded substitutability at the transport layer while agreements continued to carry identity, authority and liability. The Internet did not solve commerce by acting as one global counterparty. It gave counterparties shared technical primitives with which to build auditable exchanges.

What the specifications can honestly prove

The official record supports a bounded conclusion. RFC 1865 documented an early case for Internet mail as EDI transport and described direct delivery to the partner’s system. RFC 1767 standardized MIME encapsulation without changing EDI meaning or adding security. RFC 3335 and RFC 4130 built stronger evidence around signatures, correlation and MICs while preserving the difference between receipt and business validity. RFC 3798 refused to equate even display with comprehension.

The sources do not show a named company deployment, a purchase order accepted, a payment made or a court enforcing a signed MDN. They do not establish that every AS2 implementation behaves correctly or that one legal interpretation applies everywhere.

The durable lesson is smaller and more useful. Internet EDI became trustworthy not by finding one receipt called “assured,” but by preserving a sequence of receipts whose issuers, scope and consequences could be examined independently. The transaction was complete only when the party with commercial authority said so under the governing arrangement.

Sources