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 --]
next prev parent 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).