Re: More on forwarding quoted-printable encoded messages

[Steinar Bang <sb@metis.no>]

>>>>> Shenghuo ZHU <zsh@cs.rochester.edu>:

> I don't think that the problem is simply the c-t-e of
> message/rfc822. In the current version, the message/rfc822 part is
> only charset-decoded (gnus-article-decode-hook). When the message is
> sent, the part is re-encoded.  I don't think this is a right
> solution.  The message/rfc822 part should be unchanged or totally
> decoded/re-encoded (mml <-> mime). The former solution is not
> acceptable to many users, because those users may want to change the
> content. In the latter solution, the c-t-e is not necessary at all.

According to RFC-2046 section 5.2.1 (covering message/rfc822), last
paragraph, the only legal c-t-encodings for message/rfc822, are 7bit,
8bit, and binary.

The way I see it, this means that the only safe c-t-e to chose when
creating a message/rfc822 part, would be 7bit, which according to
RFC-2046 would require the message itself to be encoded before
inclusion, and with any non-ASCII headers encododed according to
RFC-2047

Here's the last parargraph of section 5.2.1 of
	http://www.ietf.org/rfc/rfc2046.txt

   No encoding other than "7bit", "8bit", or "binary" is permitted for
   the body of a "message/rfc822" entity.  The message header fields are
   always US-ASCII in any case, and data within the body can still be
   encoded, in which case the Content-Transfer-Encoding header field in
   the encapsulated message will reflect this.  Non-US-ASCII text in the
   headers of an encapsulated message can be specified using the
   mechanisms described in RFC 2047.