Message Disposition Notifications
A message disposition notification (MDN) is a receipt document that contains the original message ID of a message and status information about the original message.
Electronic Data Interchange-Internet Integration (EDIINT) is a family of protocols developed by the Internet Engineering Task Force (IETF) for securely packaging and transporting messages containing business data over the Internet, using S/MIME.
- AS1, which uses SMTP, POP, and IMAP as the transport
- AS2, which uses HTTP as the transport
Within a business process in Sterling B2B Integrator, the EDIINT Message service builds and parses EDIINT AS1 and AS2 messages. The EDIINT Pipeline service on the other hand builds and parses only AS2 messages, including plain text, signed, and encrypted data.
MDNs that conform to the EDIINT specifications can contain a cryptographic hash calculated over the content of the message after EDIINT processing.
- Signed – Contains an encrypted digital signature of the receiver.
- Unsigned – Contains only the original message ID and not a digital signature.
Signed MDNs that conform to the EDIINT specifications can provide non-repudiation of receipt in addition to message status information. A valid digital signature over an EDIINT MDN shows that the MDN was sent by the trading partner possessing the relevant key pair. It also shows that the signed area of the MDN (which includes the cryptographic hash calculated over the received content) was not altered after signing. A message sender compares the hash in the MDN with the hash calculated when the message was generated. If the hashes match, the sender knows that the receiver received the content and has the MDN to demonstrate the status.
Whether signed or not, MDNs do not show that the received message content conforms to EDI or other business document formatting requirements.
- Synchronously – Returned immediately during the same communication session. As shown in the following diagram, A initiates the connection to B and delivers the data to B. A then leaves the connection open while waiting for an MDN from B during the same communication session. After A receives the MDN, A closes the connection.
- Asynchronously – Returned at a later time during a different communication session. As shown in the following diagram, A initiates the connection to B and drops the data for delivery to B. A closes the connection and does not wait for an MDN from B during the same communication session. In a later session, B initiates a connection to A, receives the data from A, and sends an MDN to A. When the MDN is delivered, B closes the connection.
