David Bremner <david@tethera.net> 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 -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org