Re: filtering headers from forwarded messages
* 2020-12-31 17:39:23-0500, Daniel Kahn Gillmor wrote: > On Wed 2020-12-30 12:46:02 +0200, Teemu Likonen wrote: >> What about forwarding a message as MIME part which is just "text/plain" >> (and not "message/rfc822")? > > This might be useful for some people, but doesn't really satisfy my > goals. When i want to forward a message, i want to forward the whole > message -- multipart, with attachments, etc. My goal when forwarding is > to *not* mangle the message, but rather to supply it to the new > recipient in a parseable way. I just don't think that most recipients > need to have access to (for example) the headers that are added by all > the mail transport agents along my receipt path. I want them filtered > for privacy, which i think isn't unreasonable. OK, that is reasonable. Somehow I thought that you wanted a pretty-printed message (old inline style) but still valid email form. But yes, it would be nice to filter headers like "Received", maybe "DKIM-Signature" and various unofficial headers starting with "X-". For a quick first step I would probably try running "C-u M-|" (shell-command-on-region) in Emacs and pipe the forwarded message through command like this: formail -I Received -I DKIM-Signature -I X-Whatever Probably after that I would integrate that shell command call in one Emacs command and then implement the functionality in Emacs Lisp. But so far I haven't cared enough. -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: failure in emacs notmuch-show: notmuch-show--register-cids: Wrong type argument: char-or-string-p, nil
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 <> signature.asc Description: PGP signature ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: failure in emacs notmuch-show: notmuch-show--register-cids: Wrong type argument: char-or-string-p, nil
Daniel Kahn Gillmor writes: > My elisp is too weak to know how to debug this well. suggestions > welcome! "M-x toggle-debug-on-error" and then trying to show the message should give you a backtrace. But before doing that also "M-x eval-buffer" in "notmuch-show.el" to make it more meaningful. > 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. 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 And another problem seems to be that notmuch cannot determine the type of some part even though "email-print-mime-structure" can. You should be able to figure out which part by adding a debug statement such as: (message "> %S" part) Cheers, Jonas ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org