Re: Search for multipart/(signed|encrypted) in message-forward-make-body

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In <v93b8senm9.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib wrote:

> in `message-forward-make-body' we have:

>   (if digest
>       (message-forward-make-body-digest forward-buffer)
>     (if message-forward-as-mime
> 	(if (and message-forward-show-mml
> 		 (not (and (eq message-forward-show-mml 'best)
> 			   (with-current-buffer forward-buffer
> 			     (goto-char (point-min))
> 			     (re-search-forward
> 			      "Content-Type: *multipart/\\(signed\\|encrypted\\)"
> 			      nil t)))))
> 	    (message-forward-make-body-mml forward-buffer)
> 	  (message-forward-make-body-mime forward-buffer))
>       (message-forward-make-body-plain forward-buffer)))

> Shouldn't the search for multipart/(signed|encrypted) be restricted to
> the headers?

I don't think so.  I tested your patch by forwarding again a
forwarded message in which the forwarded part contains non-ASCII
text and a gpg signature.  Note that the gpg signature was made
with encoded text.  Where the word *encoded* means charset
encoding and CTE (i.e., 7bit, B, or Q) encoding.

When I type `C-c C-f' in the summary buffer, I get a message
buffer with human-readable text in the body.  That's good.
However, Gnus will not necessarily use the same CTE as the one
used when the original message was sent.  Because there is no
`encoding=' tag which inherits the original CTE.  Even if they
are the same, Q encoding does not always output the same result.
So, it may destroy the consistency of the text and the signature.

Regards,