When dealing with data, and all related terminology, you may feel like you’re trying to speak a foreign language. In the interest of keeping things clear and simple, we will introduce commonly-used terms in each newsletter that will help you navigate the data shorthand and learn the lingo. This week, we explain the message disposition notification in the EDI landscape.
In the world of EDI when two machines are communicating, it's best that the EDI information being conveyed is encrypted and safe. MDN, message disposition notification, is a form of acknowledgement code structure that is reliable.
MDN – Message Disposition Notification
The Message Disposition Notification (MDN) is the acknowledgment sent in response to an AS2 message. If an MDN is enabled, the AS2 transmission is not complete until the MDN has been received and verified. Most AS2 software will always attempt to return an MDN to indicate the status of message processing, even if an error occurred in processing the AS2 message.
The MDN provides verification of the following:
- That the original message was successfully received by the receiving party. The sender of the original message verifies this by comparing the MessageID of the original sent message with the original-message-id field that the receiver included in the MDN.
- That the integrity of the data exchanged was verified by the receiving partner. The sender of the original message verifies this by comparing the Message Integrity Check (MIC) that was calculated from the original sent message payload, with the MIC that the receiver calculated on the received message payload and included in the Received-content-MIC field of the MDN (if signed).
- That there is a non-repudiation of receipt. The sender does this by verifying the signed MDN with the receiving partner's public key, and by verifying that the returned MIC value in the MDN is the same as the MIC for the original message payload stored in the non-repudiation database.