* Non-MML forwarding strips Content-Transfer-Encoding
@ 2002-07-23 13:47 Hrvoje Niksic
2002-07-26 18:10 ` Simon Josefsson
0 siblings, 1 reply; 4+ messages in thread
From: Hrvoje Niksic @ 2002-07-23 13:47 UTC (permalink / raw)
[ 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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Non-MML forwarding strips Content-Transfer-Encoding
2002-07-23 13:47 Non-MML forwarding strips Content-Transfer-Encoding Hrvoje Niksic
@ 2002-07-26 18:10 ` Simon Josefsson
2002-07-27 16:35 ` Hrvoje Niksic
0 siblings, 1 reply; 4+ messages in thread
From: Simon Josefsson @ 2002-07-26 18:10 UTC (permalink / raw)
Cc: ding
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Non-MML forwarding strips Content-Transfer-Encoding
2002-07-26 18:10 ` Simon Josefsson
@ 2002-07-27 16:35 ` Hrvoje Niksic
2002-07-27 20:48 ` Simon Josefsson
0 siblings, 1 reply; 4+ messages in thread
From: Hrvoje Niksic @ 2002-07-27 16:35 UTC (permalink / raw)
Cc: hniksic
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Non-MML forwarding strips Content-Transfer-Encoding
2002-07-27 16:35 ` Hrvoje Niksic
@ 2002-07-27 20:48 ` Simon Josefsson
0 siblings, 0 replies; 4+ messages in thread
From: Simon Josefsson @ 2002-07-27 20:48 UTC (permalink / raw)
Cc: ding, hniksic
Hrvoje Niksic <hniksic@xemacs.org> writes:
> Thanks. It works for me now. I assume the patch has been applied to
> CVS?
Added now.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-07-27 20:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-23 13:47 Non-MML forwarding strips Content-Transfer-Encoding Hrvoje Niksic
2002-07-26 18:10 ` Simon Josefsson
2002-07-27 16:35 ` Hrvoje Niksic
2002-07-27 20:48 ` Simon Josefsson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).