iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
AS2 sends structured business data—such as an X12 or EDIFACT interchange—as a MIME message in an HTTP POST to a trading partner. Depending on the partners’ agreement, the message may be signed, encrypted, both, or neither. The receiver processes it and, if requested, returns an AS2 Message Disposition Notification (MDN), either in the original HTTP response or through a separate connection. An MDN is not proof that the business application accepted the transaction.
What AS2 does—and what it does not
AS2 is a standard for exchanging business data between trading partners. It defines how a message is packaged and transported, along with optional security and receipt mechanisms; it is not an EDI document format. The payload can be XML, ANSI X12, EDIFACT, or another structured data format. RFC 4130 describes the basic structure as “MIME format inside an HTTP message with a few additional specific AS2 headers.”
The wire-level exchange can be understood as a sequence: the sender prepares and packages data, posts it to the receiver, and the receiver processes the message and may return an MDN. The exact security settings and receipt behavior depend on the partners’ configuration. RFC 4130 is the published AS2 specification.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What happens when an AS2 message is sent
1. The sender packages the business data
The sender’s AS2 user agent takes the structured business data and packages it as a MIME message. The business document remains the payload; MIME supplies the message packaging needed for transport and, where configured, security processing.
#1 Best Overall
2. The sender makes an HTTP POST
The sender transmits the message to the recipient’s AS2 endpoint in an HTTP POST. AS2-specific headers identify the participating systems and can specify security-related information and a request for an MDN.
3. The sender applies the agreed security options
If the partners’ setup calls for it, the sender uses S/MIME to sign the message, encrypt it for the recipient, or do both. These functions address different concerns: a signature supports integrity checking and sender authentication, while encryption protects confidentiality. Neither feature is mandatory for every AS2 exchange; the partners must agree on the configuration and compatible behavior.
4. The receiver processes the message
The receiver’s AS2 user agent processes the MIME and any S/MIME layers. It decrypts an encrypted message and verifies a signature when those features are present. These checks concern the message received by the AS2 system. They do not show that a separate business application has accepted an order, approved an invoice, or completed any other business action.
5. The receiver may return an MDN
If the sender requested a receipt, the receiver can return an MDN. A synchronous MDN is carried in the HTTP response to the original POST. An asynchronous MDN is sent later in a separate HTTP POST to the requested return destination. The HTTP response and the MDN are related but distinct: the former responds to the transport request, while the latter is the AS2 receipt structure.
How to interpret security and receipts
AS2 partners should evaluate a configuration against the protections and operating constraints they actually need, rather than assume one combination is required by the protocol. Relevant dimensions include confidentiality, message integrity and sender authentication, receipt assurance, timing, and interoperability with both partners’ supported algorithms and MIME/MDN behavior.
| Decision | Possible configuration | What it means |
|---|---|---|
| Confidentiality | Encrypted or unencrypted payload | Encryption protects confidentiality in transit to the intended recipient; it is separate from signing. |
| Integrity and sender authentication | Signed or unsigned payload | A signature can be checked by the recipient; an unsigned message has no payload signature to verify. |
| Receipt assurance | No MDN, unsigned MDN, or signed MDN with MIC verification | A signed MDN with a matching MIC provides stronger receipt evidence than an unsigned receipt. |
| Receipt timing | Synchronous or asynchronous MDN | A synchronous MDN uses the original connection; an asynchronous one arrives through a separate connection. |
| Interoperability | Mutually supported algorithms and MIME/MDN behaviors | Both trading partners need compatible settings, including any legacy behavior they must support. |
A signed MDN can include a Message Integrity Check (MIC) for the received message. For the stronger receipt evidence described in RFC 4130, the sender verifies the MDN signature and checks its MIC against the digest recorded for the original message. That evidence is useful only if the sender retains the original message and the associated message ID, digest, and receipt records.
Rank #4
- Used Book in Good Condition
What an MDN proves—and what it does not
An MDN acknowledges disposition or receipt at the AS2 exchange layer. When it is signed and its MIC is verified against the sender’s recorded digest, it can provide evidence that the received content was acknowledged and integrity-checked. It does not, by itself, establish that the recipient’s business system accepted an order, shipped goods, approved an invoice, or made a payment. Those outcomes depend on separate application-level processing and business acknowledgments.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhat is current in the AS2 standard
RFC 4130, published in July 2005, remains the published AS2 specification. The IETF Datatracker lists draft-ietf-ediint-rfc4130bis-03, “AS2 Specification Modernization”, dated September 2026 and expiring on 22 March 2027. It is an Internet-Draft, not an adopted replacement standard. The draft discusses modernizing security and MDN interoperability while preserving compatibility with historic MDN forms. It also describes a secure transmission loop that includes compression; that draft language should not be treated as a universal feature of deployed AS2 exchanges.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
