From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/30396 Path: main.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.gnus.general Subject: Re: More on forwarding quoted-printable encoded messages Date: 26 Apr 2000 10:23:22 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: <87d7qc557e.fsf@psyche.evansnet> <2n8zy1l1ug.fsf@tiger.jia.vnet> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035166940 8243 80.91.224.250 (21 Oct 2002 02:22:20 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 02:22:20 +0000 (UTC) Return-Path: Original-Received: from lisa.math.uh.edu (lisa.math.uh.edu [129.7.128.49]) by mailhost.sclp.com (Postfix) with ESMTP id 74F76D051E for ; Wed, 26 Apr 2000 04:23:48 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by lisa.math.uh.edu (8.9.1/8.9.1) with ESMTP id DAB29318; Wed, 26 Apr 2000 03:23:47 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 26 Apr 2000 03:23:16 -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 DAA14582 for ; Wed, 26 Apr 2000 03:23:06 -0500 (CDT) Original-Received: from viffer.metis.no (viffer.oslo.metis.no [195.0.254.249]) by mailhost.sclp.com (Postfix) with ESMTP id 58F63D051F for ; Wed, 26 Apr 2000 04:23:24 -0400 (EDT) Original-Received: (from sb@localhost) by viffer.metis.no (8.9.3/8.9.3) id KAA12239; Wed, 26 Apr 2000 10:23:23 +0200 Original-To: ding@gnus.org In-Reply-To: Shenghuo ZHU's message of "26 Apr 2000 04:10:15 -0400" Original-Lines: 31 User-Agent: Gnus/5.0805 (Gnus v5.8.5) XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:30396 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:30396 >>>>> Shenghuo ZHU : > 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.