MDN (Message Disposition Notification) Failures
The MDN serves as the definitive proof that an AS2 message was received and processed. Failures related to MDNs can be elusive, as they often occur after the payload has been successfully delivered.
MDN Pending and Reception Issues
Synchronous MDN Mode
If you choose to request an MDN, MFT Gateway defaults to requesting a synchronous MDN, which the partner returns within the same HTTP response. If the MDN is not available after the AS2 transfer completes, the transaction is considered a failure.
Since the MDN is expected to be returned over the already established connection, a missing MDN is most commonly due to:
- A misconfiguration of the MDN request mode at the MFT Gateway partner profile, such as not requesting an MDN or requesting an asynchronous MDN instead of a synchronous one.
- A misconfiguration of the MDN issuing mode at the partner. For example, not sending an MDN or sending an asynchronous MDN instead of a synchronous one, disregarding AS2 request headers.
Note that if your partner unable to return the MDN due to an interruption, it will be treated as a message transmission failure, since the MDN is the response to the original AS2 transmission.
Asynchronous MDN Mode
If you choose to request an asynchronous MDN, and partner indicated successful acceptance of the message (by returning an HTTP 200-range response), the transaction held as pending until the partner sends back the MDN indicating final message processing status. However, if the MDN does not reach to the MFT Gateway within an acceptable time frame (usually a few minutes, maybe an hour at most), it is possible that the async MDN delivery has somehow failed.
Symptoms and solutions are the same as those explained under connectivity issues and HTTP error responses, now being encountered by the partner (MDN sender) against the MFT Gateway MDN receiving endpoint, which is http://service.mftgateway.com/mdn-receiver by default.
Negative/error MDN Receipts
Even if the network transfer and HTTP response indicate success, the actual processing status of the AS2 message can only be determined by the MDN receipt that the receiver sends back to the sender.
Errors returned in the MDN, fall into the same categories described under inbound message failures.
Message Integrity Check (MIC) Discrepancies
A MIC mismatch occurs if the MIC calculated by MFT Gateway from the originally sent content does not match the MIC embedded in the received MDN.
Possible symptoms and error messages
MFT Gateway reports an unmatched MIC error upon receipt of such an MDN.
Note that in this case, the MDN itself is marked as successful as shown in the above image because it is the sender that does the final MIC comparison and finds the mismatch.
Steps to resolve
Common scenarios are shown in the below table.
| MIC Issue | Resolution |
|---|---|
| Algorithm Mismatch | MFT Gateway requests the specific MIC algorithm by including a Disposition-Notification-Options header in the AS2 transmission. However, partner may have ignored it and used a different/fixed algorithm to compute the returned MIC. |
| Format Mismatch | The MIC string is typically formatted as {MIC value}, {MIC algorithm name}, and variations in whitespace or the format/case of the algorithm name can cause issues across implementations. For example, if the MFT Gateway expects sha-256 (e.g., MIC foobar, sha-256) but the partner uses sha256 (foobar, sha256), the MIC may be marked as unmatched on the MFT Gateway side. |
| Payload Altered or Corrupted | If there have been successful (MIC-matched) exchanges previously, an isolated occurrence (or series of occurrences) could actually indicate a corruption in the payload, or a man-in-the-middle (MITM) exploitation. |
MDN Signature Verification Failure
The partner can optionally sign the returned MDN using its private key so the MFT Gateway can verify its authenticity upon receipt, similar to how MFT Gateway verifies the AS2 message signature. If this verification fails, MFT Gateway cannot guarantee that the MDN is authentic (that it originated from the claimed partner) or has not been altered during transfer.
Possible symptoms and error messages
MFT Gateway reports a signature verification failure for the received MDN. As in previous cases, the MDN itself could be marked as successful.
Steps to resolve
Ensure that the correct signature verification certificate is configured in the partner configuration.
