Re: More on forwarding quoted-printable encoded messages

["Bjørn Mork" <bmork@dod.no>]

Steinar Bang <sb@metis.no> writes:
> >>>>> 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

I believe the forwarded message should be unchanged even if the it
violates RFC2046/7 e.g. by using 8bit headers. The message/rfc822 CTE 
would then be 8bit if the original message, including headers, contains 
any 8bit chars, otherwise 7bit. RFC2046 does not require the forwarded 
message to comply with RFCs 2046-49. It even explicitly states that the 
body of a message/rfc822 part does not need to be RFC822-conformant! How 
do you encode the forwarded message if it contains 8bit characters but 
no CT/CTE headers? Isn't it better not to make any charset and encoding 
choice for the final recipient, and therefore forward the message 
untouched?


Bjørn