Re: filtering headers from forwarded messages

2021-01-02 Thread Teemu Likonen
* 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

2021-01-02 Thread Daniel Kahn Gillmor
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

2021-01-02 Thread Jonas Bernoulli
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