Outgoing signed MDN is missing MIME body part with signature

Question

Outgoing signed MDN is missing MIME body part with signature

Closed this issue 2 years ago · 2 comments

When Holodeck replies to an incoming message with a signed MDN required, the whole body part with the signature seems to be missing, which results in a failure within the third party AS2 software receiving this MDN.

Here's the incoming HTTP traffic on recipients side (http wire log):

http-outgoing-4 << "HTTP/1.1 200 OK[\r][\n]"
http-outgoing-4 << "date: Thu, 13 Jan 2022 17:32:48 +0100 (CET)[\r][\n]"
http-outgoing-4 << "message-id: <ff4a410f-ac1b-42ec-ae62-0314b129f5d0@h-3fd9f07440a52c22.3fd9e12bf13ce588>[\r][\n]"
http-outgoing-4 << "as2-to: party1[\r][\n]"
http-outgoing-4 << "as2-from: party2[\r][\n]"
http-outgoing-4 << "subject: MDN for message: party1_5_1642091564456@party2[\r][\n]"
http-outgoing-4 << "original-message-id: party1_5_1642091564456@party2[\r][\n]"
http-outgoing-4 << "Transfer-Encoding: chunked[\r][\n]"
http-outgoing-4 << "Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; [\r][\n]"
http-outgoing-4 << "[0x9]boundary="----=_Part_31_1636597266.1642091575797"[\r][\n]"
http-outgoing-4 << "Connection: Keep-Alive[\r][\n]"
http-outgoing-4 << "[\r][\n]"
http-outgoing-4 << "245[\r][\n]"
http-outgoing-4 << "------=_Part_31_1636597266.1642091575797[\r][\n]"
http-outgoing-4 << "Content-Type: multipart/report; report-type=disposition-notification; [\r][\n]"
http-outgoing-4 << "[0x9]boundary="----=_Part_30_1249395444.1642091568534"[\r][\n]"
http-outgoing-4 << "[\r][\n]"
http-outgoing-4 << "------=_Part_30_1249395444.1642091568534[\r][\n]"
http-outgoing-4 << "Content-Type: text/plain[\r][\n]"
http-outgoing-4 << "Content-Transfer-Encoding: 7bit[\r][\n]"
http-outgoing-4 << "[\r][\n]"
http-outgoing-4 << "This is an automatically generated MDN for the AS2 message[message-id:<party1_5_1642091564456@party2>] received from party1.[\r][\n]"
http-outgoing-4 << "[\r][\n]"
http-outgoing-4 << "The message was processed successfully.[\r][\n]"
http-outgoing-4 << "[\r][\n]"
http-outgoing-4 << "------=_Part_30_1249395444.1642091568534[\r][\n]"
http-outgoing-4 << "Content-Type: message/disposition-notification[\r][\n]"
http-outgoing-4 << "Content-Transfer-Encoding: 7bit[\r][\n]"
http-outgoing-4 << "[\r][\n]"
http-outgoing-4 << "[\r][\n]"
http-outgoing-4 << "0[\r][\n]"
http-outgoing-4 << "[\r][\n]"

Note at the bottom, that there is no content within the message/disposition-notification part.

This seems to be caused within MDNInfo:334:

reportPart.setContent(reportPartContent.toString(), Constants.MDN_DISPOSITION_MIME_TYPE);

Out of curiosity, I changed the type to MIME_PLAIN_TEXT. I'm not familiar with the MIME API though and not sure, if this is the correct fix to apply:

reportPart.setContent(reportPartContent.toString(), MIME_PLAIN_TEXT);

This fixes the missing MIME body, the resulting HTTP now looks like this and can be processed by the third party software:

http-outgoing-5 << "HTTP/1.1 200 OK[\r][\n]"
http-outgoing-5 << "date: Thu, 13 Jan 2022 17:38:01 +0100 (CET)[\r][\n]"
http-outgoing-5 << "message-id: <575a3e72-23c4-44da-8303-b1655403b61c@h-3fe6f1877f99f381.3fcb43698190a908>[\r][\n
http-outgoing-5 << "as2-to: party1[\r][\n]"
http-outgoing-5 << "as2-from: party2[\r][\n]"
http-outgoing-5 << "subject: MDN for message: party1_6_1642091880580@party2[\r][\n]"
http-outgoing-5 << "original-message-id: party1_6_1642091880580@party2[\r][\n]"
http-outgoing-5 << "Transfer-Encoding: chunked[\r][\n]"
http-outgoing-5 << "Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; [\r][
http-outgoing-5 << "[0x9]boundary="----=_Part_1_944891477.1642091881210"[\r][\n]"
http-outgoing-5 << "Connection: Keep-Alive[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "82b[\r][\n]"
http-outgoing-5 << "------=_Part_1_944891477.1642091881210[\r][\n]"
http-outgoing-5 << "Content-Type: multipart/report; report-type=disposition-notification; [\r][\n]"
http-outgoing-5 << "[0x9]boundary="----=_Part_0_914351271.1642091881190"[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "------=_Part_0_914351271.1642091881190[\r][\n]"
http-outgoing-5 << "Content-Type: text/plain[\r][\n]"
http-outgoing-5 << "Content-Transfer-Encoding: 7bit[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "This is an automatically generated MDN for the AS2 message[message-id:<party1_6_16420918805
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "The message was processed successfully.[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "------=_Part_0_914351271.1642091881190[\r][\n]"
http-outgoing-5 << "Content-Type: message/disposition-notification[\r][\n]"
http-outgoing-5 << "Content-Transfer-Encoding: 7bit[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "Reporting-UA:host.docker.internal;HolodeckB2B 5.3.1[\r][\n]"
http-outgoing-5 << "Final-Recipient:as2;party1[\r][\n]"
http-outgoing-5 << "Original-Message-ID:<party1_6_1642091880580@party2>[\r][\n]"
http-outgoing-5 << "Disposition:automatic-action/MDN-sent-automatically;processed[\r][\n]"
http-outgoing-5 << "Received-Content-MIC:+jZd8+RmIfRh3JkOuU4aD67Mi70G17N8a9TKrkxOFww=,sha-256[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "------=_Part_0_914351271.1642091881190--[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "------=_Part_1_944891477.1642091881210[\r][\n]"
http-outgoing-5 << "Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data[\r][\n]"
http-outgoing-5 << "Content-Transfer-Encoding: base64[\r][\n]"
http-outgoing-5 << "Content-Disposition: attachment; filename="smime.p7s"[\r][\n]"
http-outgoing-5 << "Content-Description: S/MIME Cryptographic Signature[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAADGCAj8w[\r][\n]"
http-outgoing-5 << "ggI7AgEBMFkwTDEMMAoGA1UECBMDTlJXMQswCQYDVQQGEwJERTESMBAGA1UEChMJU09QVElNIEFH[\r][\n]"
http-outgoing-5 << "MRswGQYDVQQDExJuYjAxMjIyLnNvcHRpbS5uZXQCCQCpUX933TKnmTANBglghkgBZQMEAgMFAKCB[\r][\n]"
http-outgoing-5 << "uDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMjAxMTMxNjM4MDFa[\r][\n]"
http-outgoing-5 << "MC0GCSqGSIb3DQEJNDEgMB4wDQYJYIZIAWUDBAIDBQChDQYJKoZIhvcNAQENBQAwTwYJKoZIhvcN[\r][\n]"
http-outgoing-5 << "AQkEMUIEQH+I3FRITDjK/5/FlKDvnVbicEVA4OFoRyB+ouIiZIiL8HJXvQn03lSWzTDUj28K+dw/[\r][\n]"
http-outgoing-5 << "eaJREv/jmDSEyWJDvPwwDQYJKoZIhvcNAQENBQAEggEArfpSskDUp8T+YqfmTB8EsBPLUotDoh0L[\r][\n]"
http-outgoing-5 << "TqtgN1hZpAicZSL3Ye6o26Y0bvwS9PPZleumfyaAANi/ivO6QdPtQEIp/tCJ6jXB96EV+A9svjpZ[\r][\n]"
http-outgoing-5 << "IpmL8KkwEtDzaYcIgu2rrmeXuFk7iMfgiSExcRIZVP9WmzEcCYtJNQm7HwuT5fuwnBpwojx6KKs5[\r][\n]"
http-outgoing-5 << "lQpPxmVqOCTliLSi6TbcW9CQUg/4JlSu9DOut7T3qBgdM1R5QVbv8lXPBMO/7daOhRK584a3tNnE[\r][\n]"
http-outgoing-5 << "V4kuefczKh0P7Le8LWGNdqX8kZvGiFh68VtIu7ade5Zmlwb//jNx2avqgOTr1f5sUpbVu8Rjv7nM[\r][\n]"
http-outgoing-5 << "0pJUDwAAAAAAAA==[\r][\n]"
http-outgoing-5 << "------=_Part_1_944891477.1642091881210--[\r][\n]"
http-outgoing-5 << "[\r][\n]"
http-outgoing-5 << "0[\r][\n]"
http-outgoing-5 << "[\r][\n]"

Answer 1 · 2022-01-14T10:48:48.000Z

This bug seems to be caused by a change in the Java runtime versions as it works correct when running the HB2B instance on Java 8. On Java 11 however the message is preliminarily terminated.
Probably the default processing of Mime parts has changed and a DataContentHandler for the MDN Mime type needs to registered explicitly in JAF. Setting the Mime type to plain text therefore indeed works as work around. Although processing of a received MDN seems not affected it probably is better to register a DataContextHandler for the MDN Mime type.

Answer 2 · 2022-03-09T10:21:36.000Z

Will there be a new release with the four fixes soon?