Re: Non-MML forwarding strips Content-Transfer-Encoding

[Hrvoje Niksic <hniksic@xemacs.org>]

Simon Josefsson <jas@extundo.com> writes:

>> Obviously, stripping Content-Transfer-Encoding is wrong.  The
>> resulting message is corrupted because its body will be interpreted
>> to contain 7bit data.  It is also wrong in principle -- when
>> `message-forward-show-mml' is unset, I expect little or no
>> tinkering with the embedded message.  Gnus should just make sure it
>> is correctly embedded as a part, and the rest will follow from
>> that.
>
> Yup.  Removing it is Right when message-forward-show-mml is non-nil,
> the default, though.  So it is probably only a matter of not testing
> that combination.

That's what I assumed as well.

> This should fix that particular problem.
>
> --- message.el.~6.240.~	2002-06-29 16:38:03.000000000 +0200
> +++ message.el	2002-07-26 19:07:45.000000000 +0200
> @@ -5190,7 +5190,9 @@
>  			    (or (search-forward "\n\n" nil t) (point)))
>  	  (delete-region (point-min) (point-max)))
>        (when (and (not current-prefix-arg)
> -		 message-forward-ignored-headers)
> +		 message-forward-ignored-headers
> +		 ;; don't remove CTE, X-Gnus etc when doing "raw" forward:
> +		 message-forward-show-mml)
>  	(save-restriction
>  	  (narrow-to-region b e)
>  	  (goto-char b)

Thanks.  It works for me now.  I assume the patch has been applied to
CVS?

> If this isn't sufficient for you, I'm not sure what to do except
> debugging every step of sending the mail to track what is happening.

No, this is perfectly fine.  The only testing you need is to set
message-forward-show-mml to nil, press `S o m', and take a look at
whether the included attachment still includes
`Content-Transfer-Encoding'.

Thanks for helping with this.