Closed postme closed 6 years ago
Hmmmm, that's interesting... thanks for reporting.
Can you tell me if the original email had the content type protocol parameter exactly the same as the example? What I've noticed is the Content-Type's protocol is set to application/x-pkcs7-signature but the actual content-type for the /original/ signature is application/pkcs7-signature (without the "x-" in it).
Normally I'm looking for the part with a content type equal to the protocol parameter of the email's content-type, but in this case it's failing to find it it seems.
Hi Zaahid, I verified with the original message prior to being processed and the Content-Type is:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=SHA1; boundary="----=_NextPart_000_0023_01D39C01.C03D75B0"
Sending MTA is Exchange 2016, sending MUA is Outlook.
Kind regards Meint
Released in 0.4.8. According to https://tools.ietf.org/html/rfc1847 the signature part has to be the second child of the multipart/signed message, doesn't specifically mention that its content-type header must match the 'protocol' parameter of the message's content-type.
Reopen/let me know if you have anymore issues :)
Hi Zaahid, hope you're well Ttitle says it all, if I get an email containing a s/mime pkcs7 signature the setAsMultipartSigned doesnt work in the sense that the body of the signature gets set yet the Content-Type header keeps pointing to the original signature. This causes the email not to open in Outlook, probably because it gets confused by seeing two pkcs7 signature bodies.
I have added a redacted example.
example.txt
Kind regards Meint