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

[Carey Evans <c.evans@clear.net.nz>]

Steinar Bang <sb@metis.no> writes:

[snip: problems with message/rfc822]

This sounds like it's related to some problems I have with Gnus
5.8.3.  I haven't tried the latest CVS version to see if they still
exist though.

See:

    http://www.gnus.org/list-archives/ding/200001/msg00417.html
    http://www.gnus.org/list-archives/ding/200002/msg00069.html

[...]

> 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.

It looks like that to me.

In fact, I don't think Gnus should be touching the content of the
forwarded message at all.  For S/MIME and PGP MIME, the entire MIME
part is signed, including the headers, so any changes from
quoted-printable to 7bit, or 8bit to quoted-printable, will make the
signature invalid.  Gnus should be able to forward the message intact
so that the signature can still be validated.

-- 
	 Carey Evans  http://home.clear.net.nz/pages/c.evans/

"Perl Programmers are from Mars, Python Programmers are from Yorkshire?"
Catchy title.                                              - Alex in c.l.py