unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Jonas Bernoulli <jonas@bernoul.li>,
	Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: failure in emacs notmuch-show: notmuch-show--register-cids: Wrong type argument: char-or-string-p, nil
Date: Sun, 03 Jan 2021 00:33:40 -0500	[thread overview]
Message-ID: <87wnwu8tzf.fsf@fifthhorseman.net> (raw)
In-Reply-To: <87ft3j8ybj.fsf@bernoul.li>


[-- Attachment #1.1.1: Type: text/plain, Size: 3106 bytes --]

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


[-- Attachment #1.1.2: attached-message-b64-encoded.zip --]
[-- Type: application/zip, Size: 926 bytes --]

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2021-01-03  5:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-31 23:44 failure in emacs notmuch-show: notmuch-show--register-cids: Wrong type argument: char-or-string-p, nil Daniel Kahn Gillmor
2021-01-02  9:47 ` Jonas Bernoulli
2021-01-03  5:33   ` Daniel Kahn Gillmor [this message]
2021-01-03 18:31     ` [PATCH] emacs/notmuch-show: Work around errors where a part lacks a content-type Daniel Kahn Gillmor
2021-01-03 20:06       ` Tomi Ollila
2021-01-04 21:07         ` Jonas Bernoulli
2021-01-05 22:00           ` Daniel Kahn Gillmor
2021-01-10 18:38             ` Jonas Bernoulli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wnwu8tzf.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman.net \
    --cc=jonas@bernoul.li \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).