AS2 MDN Validator
Validate an AS2 Message Disposition Notification (RFC 4130) part by part, 100 % client-side. Multipart/report, disposition, MIC, S/MIME signature.
Paste an AS2 MDN (with Content-Type: multipart/report header) to validate it.
How it works
AS2 (Applicability Statement 2, defined by RFC 4130) carries EDI messages (EDIFACT, X12, XML, JSON…) over HTTPS between B2B partners. When a message is received, the recipient returns a Message Disposition Notification (MDN) — synchronous or asynchronous — that structurally attests reception and reports the outcome of application-level processing.
An AS2 MDN is a MIME envelope:
multipart/report; report-type=disposition-notification
containing two or three parts — a human-readable text body, a structured
disposition section (message/disposition-notification), and
optionally a detached S/MIME signature (application/pkcs7-signature).
The tool parses the whole envelope, extracts the disposition headers,
and checks the Received-Content-MIC for shape consistency.
AS2 MDN structure
Content-Type: multipart/report; report-type=disposition-notification;
boundary="--MDN-Boundary"
----MDN-Boundary
Content-Type: text/plain
The AS2 message <msg-123@sender> was successfully received and processed.
----MDN-Boundary
Content-Type: message/disposition-notification
Reporting-UA: ediverse AS2 / 2.4.0
Original-Recipient: rfc822; ReceiverAS2ID
Final-Recipient: rfc822; ReceiverAS2ID
Original-Message-ID: <msg-123@sender>
Disposition: automatic-action/MDN-sent-automatically; processed
Received-Content-MIC: 5lEovTjVA6VqDIWLDQz97/g6yxc=, sha256
----MDN-Boundary--
The validator reads each part independently, allowing rapid diagnosis
of truncated or mis-encoded MDNs: missing boundary, missing disposition
part, forgotten Final-Recipient header. Diagnostics are emitted with
stable codes (E_NO_BOUNDARY, E_MISSING_FINAL_RECIPIENT,
E_BAD_MIC_FORMAT…).
Disposition codes
The Disposition field (RFC 3798 §3.2.6) reports the processing outcome:
Disposition: <action-mode>/<sending-mode>; <type>[/<modifier>]
Examples:
automatic-action/MDN-sent-automatically; processed
automatic-action/MDN-sent-automatically; processed/warning
automatic-action/MDN-sent-automatically; failed/error
manual-action/MDN-sent-manually; denied- processed — success. The message was received and processed; a
warningmodifier signals a non-blocking issue. - failed — failure, typically with the
errormodifier plusError:/Failure:extension headers. - denied — refused without processing (filter, policy, unknown partner).
MIC and algorithms
The Received-Content-MIC is the cryptographic digest of
the original payload computed by the recipient. Format:
<base64 digest>, <algorithm>. The sender
compares it against the MIC it initially computed to guarantee
transport integrity.
AS2-recognised algorithms (RFC 5751):
- sha256, sha384, sha512 — recommended.
- sha1, md5 — legacy, cryptographically weak. The tool emits a
W_WEAK_MIC_ALGwarning.
Limits
- The validator does not recompute the MIC against the original payload (which is not part of the MDN). Only shape and algorithm are checked.
- The detached S/MIME signature is detected but not verified: no certificate chain is resolved, no trust anchor is consulted.
- HTTP transport headers (AS2-To, AS2-From, Disposition-Notification-Options…) are not required — the validator handles the MDN body alone, as it would have been POSTed back synchronously or sent asynchronously.
Privacy
Related documentation
- RFC 4130 — MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2); rfc-editor.org — RFC 4130.
- RFC 3798 — Message Disposition Notification; rfc-editor.org — RFC 3798.
- RFC 5751 — S/MIME Version 3.2 Message Specification (signing and encryption); rfc-editor.org — RFC 5751.