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:attached-message-b64-encoded@mailscripts.example

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