From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/34153 Path: main.gmane.org!not-for-mail From: vvv@vsu.ru Newsgroups: gmane.emacs.gnus.general Subject: content-transfer-encoding Date: 09 Jan 2001 13:37:37 +0300 Sender: owner-ding@hpc.uh.edu Message-ID: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: main.gmane.org 1035170132 28908 80.91.224.250 (21 Oct 2002 03:15:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 03:15:32 +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 7B2A2D04A0 for ; Tue, 9 Jan 2001 05:38:39 -0500 (EST) 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 EAB16640; Tue, 9 Jan 2001 04:38:32 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 09 Jan 2001 04:37:52 -0600 (CST) Original-Received: from mailhost.sclp.com (postfix@66-209.196.61.interliant.com [209.196.61.66] (may be forged)) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id EAA03096 for ; Tue, 9 Jan 2001 04:37:43 -0600 (CST) Original-Received: from vsu.ru (relay1.vsu.ru [62.76.169.14]) by mailhost.sclp.com (Postfix) with ESMTP id A4F24D04A0 for ; Tue, 9 Jan 2001 05:37:37 -0500 (EST) Original-Received: from video.uic.vsu.ru ([62.76.169.38] verified) by vsu.ru (CommuniGate Pro SMTP 3.4b8) with ESMTP id 2282046 for ding@gnus.org; Tue, 09 Jan 2001 13:37:36 +0300 Original-To: ding@gnus.org User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.6 Precedence: list X-Majordomo: 1.94.jlt7 Original-Lines: 28 Xref: main.gmane.org gmane.emacs.gnus.general:34153 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:34153 --=-=-= Hi, rfc2045 has the following requirement: RFC> It should also be noted that, by definition, if a composite entity RFC> has a transfer-encoding value such as "7bit", but one of the enclosed RFC> entities has a less restrictive value such as "8bit", then either the RFC> outer "7bit" labelling is in error, because 8bit data are included, RFC> or the inner "8bit" labelling placed an unnecessarily high demand on RFC> the transport system because the actual included data were actually RFC> 7bit-safe. but when gnus sends a multipart messages, it does not set the content-transfer-encoding=8bit of the whole message when one of the parts has 8bit (or content-transfer-encoding=binary when one of the parts has binary CTE). by default, the CTE, if omitted, is assumed to be 7bit (as stated in the same RFC). This message has a part with 8bit CTE, but gnus does not set the 8bit CTE for the whole message. Best, v. --=-=-= Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit this part has a 8bit CTE: проба пера --=-=-=--