From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/29739 Path: main.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus doesn't understand its own message/rfc forwarding Date: 12 Apr 2000 12:04:50 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1035166361 4479 80.91.224.250 (21 Oct 2002 02:12:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:12:41 +0000 (UTC) Return-Path: Original-Received: from bart.math.uh.edu (bart.math.uh.edu [129.7.128.48]) by mailhost.sclp.com (Postfix) with ESMTP id A5148D051E for ; Wed, 12 Apr 2000 06:05:43 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by bart.math.uh.edu (8.9.1/8.9.1) with ESMTP id FAB25470; Wed, 12 Apr 2000 05:05:21 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 12 Apr 2000 05:04:53 -0500 (CDT) Original-Received: from mailhost.sclp.com (postfix@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id FAA07972 for ; Wed, 12 Apr 2000 05:04:41 -0500 (CDT) Original-Received: from viffer.metis.no (viffer.oslo.metis.no [195.0.254.249]) by mailhost.sclp.com (Postfix) with ESMTP id 35964D051E for ; Wed, 12 Apr 2000 06:04:52 -0400 (EDT) Original-Received: (from sb@localhost) by viffer.metis.no (8.9.3/8.9.3) id MAA11005; Wed, 12 Apr 2000 12:04:50 +0200 Original-To: ding@gnus.org In-Reply-To: Steinar Bang's message of "12 Apr 2000 11:32:06 +0200" Original-Lines: 36 User-Agent: Gnus/5.0804 (Gnus v5.8.4) XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:29739 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:29739 >>>>> Steinar Bang : >>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Gro=DFjohann): >> Steinar Bang writes: >>> The rfc822 part looks like this at the start: >>> [...] >>> ie. I don't get to the forwarded message in such a way that I can >>> reply to it, and as far as I can remember, this used to be possible. >> Can you reply to the (innermost) text part? > Nope. It doesn't show up as a message. It's not even decoded from > q-p when I go down there. > This is what all headers of the part looks like after doing C-u g: [snip!] Hm... it could be the fact that the message/rfc822 part is q-p, that is the problem? Ie. _all_ of the message is q-p, including the headers. Maybe it would be better to shove all encoding down to the lowest part? Isn't this the behavior that the below quoted paragraph from section 6.4 of http://www.ietf.org/rfc/rfc2045.txt would seem to indicate? Certain Content-Transfer-Encoding values may only be used on certain media types. In particular, it is EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" with any composite media type, i.e. one that recursively includes other Content-Type fields. Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded.