Non-MML forwarding strips Content-Transfer-Encoding

Non-MML forwarding strips Content-Transfer-Encoding

[Hrvoje Niksic]

[ Please Cc the responses to me as I'm not on the list. ]

A bug in the forwarding code has just bit me.

I set `message-forward-show-mml' to nil because I prefer to forward
mails as they are.  Recently something broke, though.  If you set
`message-forward-show-mml' to nil and try to forward a message encoded
as base64 (e.g. one that contains only a picture), the
Content-Transfer-Encoding header gets stripped from the embedded
message.  You end up with a buffer that looks like this:

[#part type=message/rfc822 raw=t bla bla ...]
X-From-Line: ...
<correct MIME headers sans Content-Transfer-Encoding>

<... base64 body ...>
[#/part]

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.

The one place where Content-Transfer-Encoding is removed is in
message-forward-make-body.  I tried the obvious fix of removing
Content-Transfer-Encoding from message-forward-ignored-headers and
having message-forward-make-body manually remove
Content-Transfer-Encoding when message-forward-show-mml is t:

    --- message.el.orig	Tue Jul 23 15:30:29 2002
    +++ message.el	Tue Jul 23 15:32:22 2002
    @@ -336,3 +336,3 @@

    -(defcustom message-forward-ignored-headers "^Content-Transfer-Encoding:\\|^X-Gnus"
    +(defcustom message-forward-ignored-headers "^X-Gnus"
       "*All headers that match this regexp will be deleted when forwarding a message."
    @@ -5045,3 +5045,5 @@
                                (or (search-forward "\n\n" nil t) (point)))
    -	  (message-remove-header message-forward-ignored-headers t)))))
    +	  (message-remove-header message-forward-ignored-headers t)
    +	  (when message-forward-show-mml
    +	    (message-remove-header "^Content-Transfer-Encoding"))))))
       (message-position-point))

But even with this fix, something is *still* removing the
Content-Transfer-Encoding header.  `message-encode-message-body' and
`message-send-mail-partially' both do it, but I'm not sure how or
whether they get called.

Can someone please help?

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

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

> [ Please Cc the responses to me as I'm not on the list. ]
>
> A bug in the forwarding code has just bit me.
>
> I set `message-forward-show-mml' to nil because I prefer to forward
> mails as they are.  Recently something broke, though.  If you set
> `message-forward-show-mml' to nil and try to forward a message encoded
> as base64 (e.g. one that contains only a picture), the
> Content-Transfer-Encoding header gets stripped from the embedded
> message.  You end up with a buffer that looks like this:
>
> [#part type=message/rfc822 raw=t bla bla ...]
> X-From-Line: ...
> <correct MIME headers sans Content-Transfer-Encoding>
>
> <... base64 body ...>
> [#/part]
>
> 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.  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)

> The one place where Content-Transfer-Encoding is removed is in
> message-forward-make-body.  I tried the obvious fix of removing
> Content-Transfer-Encoding from message-forward-ignored-headers and
> having message-forward-make-body manually remove
> Content-Transfer-Encoding when message-forward-show-mml is t:
...
> But even with this fix, something is *still* removing the
> Content-Transfer-Encoding header.  `message-encode-message-body' and
> `message-send-mail-partially' both do it, but I'm not sure how or
> whether they get called.
>
> Can someone please help?

The above is sufficient for me.  m-e-m-b only removes the header in
the new message, not in the forwarded one, it seems, so there
shouldn't be a need to modify it.

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.

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

[Hrvoje Niksic]

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.

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

[Simon Josefsson]

Hrvoje Niksic <hniksic@xemacs.org> writes:

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

Added now.