David Bremner <[email protected]> writes:
> [...]
> I guess you should start with "notmuch show --verify --format=json
> $msg | jq" on the command line. If the information is not there,
> nothing in the elisp will create it. You can use sexp output if you
> prefer, but it is easier to pretty-print the json.
Thanks for the pointer, David! Your hint seems bang on.
First of all, it spits an error on stderr:
---------------------------- Begin Quote -----------------------------
Failed to verify signed part: Cannot verify multipart/signed part:
signature content-type does not match protocol.
----------------------------- End Quote ------------------------------
The top-level multipart/signed has:
---------------------------- Begin Quote -----------------------------
Content-Type: multipart/signed;
protocol="application/x-pkcs7-signature";
micalg=SHA1;
boundary="----=_NextPart_000_0978_01D7F747.BB1F7A60"
----------------------------- End Quote ------------------------------
And the signature part starts:
---------------------------- Begin Quote -----------------------------
------=_NextPart_000_0978_01D7F747.BB1F7A60
Content-Type: application/pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
----------------------------- End Quote ------------------------------
So it seems it's "x-pkcs7-signature" not matching "pkcs7-signature" that
prevents the signature check from happening.
"x-pkcs7-signature" is a legacy media type, ans was deprecated with
RFC 2311 [1] back in March 1998 already.
A similar issue seems to have been discussed in Mozilla Bug 148232 [2]
back in 2002. Comment 7 on that bug [3] mentions RFC 2311, and it seems
the conclusion of the Mozilla devs at the time was to treat
"x-pkcs7-signature" as an alias for "pkcs7-signature" [4].
[1] https://datatracker.ietf.org/doc/html/rfc2311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=148232
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=148232#c7
[4] https://bugzilla.mozilla.org/attachment.cgi?id=93002&action=diff
Of course it is a pain in parts I am too polite to mention right now,
that 20 years on email tools still generate the deprecated, proprietary
"x-" media type.
Nonetheless, I would still dare to make a case for adding a
corresponding alias treatment in notmuch. Not only for the sake of
catering for messages sent by dumb, current, proprietary email
implementations (read: interoperability), but also to enable signature
verification on those really old messages in people's archives.
Ready to be shot down in flames... ;-))
Cheers,
--alexander
_______________________________________________
notmuch mailing list -- [email protected]
To unsubscribe send an email to [email protected]
