ediverse

Type to search across standards, messages, tools and glossary.

ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

— 01

Foundations

— 02

Standards

— 03

Flagship messages

— 04

Tools

Return Address

When a message expects a reply, where should that reply go? Rather than letting the receiver guess or consult a directory, the message carries the explicit address — the very signature of every EDI receipt scheme.

Problem

The sender of an EDI message typically expects a reply: an AS2 MDN, an EDIFACT CONTRL, an X12 997, an AS4 Receipt. The receiver must route that reply somewhere, but where does the information come from? Three bad options: (1) derive it from the sender id via a directory, which assumes a centralised, up-to-date directory; (2) hard-code it in the bilateral relationship config, multiplying maintenance points; (3) reply on the same channel, which works for synchronous flows but not for async ones with hours- or days-delayed replies.

Forces

  • The reply channel is not always the send channel. In async EDI, the MDN can come back over a fresh AS2 outbound connection, not in the HTTP response.
  • The sender wants to change its address without rewiring partners. A hub migrating from edi.acme.com to edi-eu.acme.com does not want every partner to update its directory.
  • The receiver should not couple onto the sender's topology. It does not know — and does not want to know — whether the sender has a load balancer, a dedicated subdomain or an internal queue.
  • The return address must survive intermediate routing. A message can traverse a VAN, a PEPPOL Access Point, a cloud broker — the Return Address must not be rewritten by intermediate hops.

Solution

EIP §159 (Hohpe & Woolf, 2003) prescribes: every message carries explicitly the address to which the reply should be sent. This is a dedicated header, distinct from the sender identifier, that designates an endpoint — URL, queue, AS2 URL, MessageId to use as a key. The receiver reads the address and routes the reply, without consulting a directory or local configuration.

EDI — AS2 and signed MDN

AS2 (RFC 4130) formalises the Return Address pattern via two headers: Disposition-Notification-To, the logical e-mail address of the MDN recipient, and the lesser-known Receipt-Delivery-Option that carries the HTTP URL where the async MDN should be posted. The URL is what matters technically, not the e-mail — the AS2 receiver uses Receipt-Delivery-Option as the HTTP-POST target of its MDN.

http as2-message-headers.http 
POST /as2/inbound HTTP/1.1
Host: partner-b.example.com
AS2-Version: 1.1
AS2-From: "PARTNER_A_ID"
AS2-To: "PARTNER_B_ID"
Message-ID: <msg-2026-05-14-0001@partner-a>
Subject: Invoice batch 0001
Disposition-Notification-To: edi-receipts@partner-a.example.com
Disposition-Notification-Options: signed-receipt-protocol=optional, pkcs7-signature;
  signed-receipt-micalg=optional, sha-256
Receipt-Delivery-Option: https://partner-a.example.com/as2/mdn

Reading: the Receipt-Delivery-Option header tells the AS2 receiver "post your MDN to this URL, not to the one derived from AS2-From". That allows posting the MDN to a dedicated endpoint (for example, an archival edi-receipts domain) without changing every partner's configuration.

EDIFACT — UNB Sender / Recipient

In EDIFACT (ISO 9735) the UNB segment carries the sender (S005) and recipient (S010) identifiers. The return address for the functional CONTRL is implicitly the sender of the original message, but bilateral agreement can pin the CONTRL to a different identifier — for example a central archival hub rather than the business sender. This is encoded in a secondary routing identifier in the EDIINT configuration, read on reception.

AS4 — eb:From and ReplyPattern

AS4 (OASIS ebMS3) systematises the pattern: the eb:Messaging block contains an eb:From identifying the logical sender, and an eb:ReplyPattern specifying whether the reply (Receipt, Error) should come back Response (in the same HTTP connection) or Callback (to a distinct URL carried by PMode.Receipt.ReplyPattern). In PEPPOL the typical value is Response for Receipts because Access Points are co-located, but Callback is needed for flows where the sender does not expose a synchronous listener.

Anti-patterns

  • Hard-coded return address in receiver config. The sender can no longer migrate its endpoint without coordinating with every partner — the exact opposite of the loose coupling the pattern brings.
  • No return address. Without an explicit header, the receiver must guess or consult a directory; if the directory is stale, the MDN goes into the void and the sender does not know whether transmission succeeded.
  • Return address rewritten by an intermediary. A VAN or hub that rewrites Receipt-Delivery-Option to its own URL breaks end-to-end observability: the sender receives an MDN but does not really know where it came from.
  • Confusion with the sender identifier. AS2-From identifies the logical sender; Receipt-Delivery-Option is the technical URL. Conflating them forces the sender to expose a dedicated AS2 endpoint on the same logical name.

Sources