Hi Jonas-- Thanks for the followup! i got the backtrace.
On Sat 2021-01-02 10:47:44 +0100, Jonas Bernoulli wrote: >> notmuch-show--register-cids: Wrong type argument: >> char-or-string-p, nil > > With only that information my guess is that > (plist-get part :content-type) > returns nil, which "downcase" understandably isn't happy with. According to the backtrace, this is exactly right. the error is in (downcase nil). > The "part" plist comes from "notmuch show ..." in > "notmuch-query-get-threads", so one problem seems to be that that > can return nil as the type (as opposed to e.g. "unknown/unknown") > while this elisp function (and maybe others) expect a string. > >> 0 dkg@alice:~$ notmuch show --decrypt=false --format=raw id:$messageid | >> email-print-mime-structure --use-gpg-agent >> └┬╴multipart/encrypted 27703 bytes >> ├─╴application/pgp-encrypted 11 bytes >> └─╴application/octet-stream inline [encrypted.asc] 23828 bytes >> ↧ (decrypts to) >> └┬╴multipart/mixed 26085 bytes >> ├─╴text/plain 1028 bytes >> └┬╴message/rfc822 attachment [attachment.eml] 24707 bytes >> └─╴text/plain 24510 bytes hm, this is interesting, upon further digging, the internal message/rfc822 part is base64-encoded. It has a "Content-Transfer-Encoding: base64" header, despite https://tools.ietf.org/html/rfc2046#section-5.2.1, which says: No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. So perhaps this message is malformed within the encryption envelope. Indeed, base64-decoding body of the attached message reveals that it has significantly more structure than the "text/plain" claim made by email-print-mime-structure above. So i've generated a simple message with a base64-encoded message/rfc822 part (but without the cryptographic wrapper), which is attached in a zip file below (i didn't want to attach it directly because it might break rendering). If you unzip it, and then: notmuch-insert < attached-message-b64-encoded.eml then in emacs: M-x notmuch-search id:email@example.com you should be able to replicate the failure. I admit i don't really understand why RFC 2046 *doesn't* accept that a message/rfc822 part might be base64-encoded, so i don't know whether the right answer is for notmuch to try b64-decode the message subpart itself, or to go ahead and ignore that "unpermitted" Content-Transfer-Encoding value. At any rate, whether this ends up being rendered as the sender intended to or not, notmuch-show shouldn't choke when processing it. Note that this has come up for a few other MUAs, including recently: thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=333880 evolution: https://bugzilla.gnome.org/show_bug.cgi?id=651197 gmime: https://gitlab.gnome.org/GNOME/gmime/-/issues/1#note_373164 Makes me think that some library or tool recently started mis-generating this stuff, ugh. --dkg
Description: PGP signature
_______________________________________________ notmuch mailing list -- firstname.lastname@example.org To unsubscribe send an email to notmuch-le...@notmuchmail.org