Re: Gnus doesn't understand its own message/rfc forwarding

[Steinar Bang <sb@metis.no>]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann):
>> Steinar Bang <sb@metis.no> 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.