From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/58030 Path: main.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: elisp encoding Date: Thu, 01 Jul 2004 18:15:34 +0900 Organization: Emacsen advocacy group Sender: ding-owner@lists.math.uh.edu Message-ID: References: <868ye5z6fp.fsf@rumba.de.uu.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1088673369 9497 80.91.224.253 (1 Jul 2004 09:16:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 1 Jul 2004 09:16:09 +0000 (UTC) Cc: bugs@gnus.org Original-X-From: ding-owner+M6571@lists.math.uh.edu Thu Jul 01 11:16:00 2004 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Bfxfk-0001Ef-00 for ; Thu, 01 Jul 2004 11:16:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1BfxfW-0002fg-00; Thu, 01 Jul 2004 04:15:46 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BfxfS-0002fb-00 for ding@lists.math.uh.edu; Thu, 01 Jul 2004 04:15:42 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BfxfR-0000LI-OA for ding@lists.math.uh.edu; Thu, 01 Jul 2004 04:15:41 -0500 Original-Received: from washington.hostforweb.net (washington.hostforweb.net [69.61.11.2]) by justine.libertine.org (Postfix) with ESMTP id 42F413A004B; Thu, 1 Jul 2004 04:15:41 -0500 (CDT) Original-Received: from yamaoka by washington.hostforweb.net with local (Exim 4.34) id 1BfxfO-0001X1-VI; Thu, 01 Jul 2004 05:15:39 -0400 Original-To: "Ilya N. Golubev" , ding@gnus.org X-Face: #kKnN,xUnmKia.'[pp`;Omh}odZK)?7wQSl"4o04=EixTF+V[""w~iNbM9ZL+.b*_CxUmFk B#Fu[*?MZZH@IkN:!"\w%I_zt>[$nm7nQosZ<3eu;B:$Q_:p!',P.c0-_Cy[dz4oIpw0ESA^D*1Lw= L&i*6&( User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:FltCF/GHGVTYO+/lthZ58AeT5JE= X-Hashcash: 0:040701:gin@mo.msk.ru:de860b1ef4081380 X-Hashcash: 0:040701:ding@gnus.org:59187cbabb6b17cf X-Hashcash: 0:040701:bugs@gnus.org:59fbe52596f69200 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - washington.hostforweb.net X-AntiAbuse: Original Domain - gnus.org X-AntiAbuse: Originator/Caller UID/GID - [32041 32041] / [47 12] X-AntiAbuse: Sender Address Domain - washington.hostforweb.net X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:58030 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:58030 >>>>> In <868ye5z6fp.fsf@rumba.de.uu.net> >>>>> Kai Grossjohann wrote: > Katsumi Yamaoka writes: >> I don't know why the part was modified into quoted-printable >> from 8bit, but it may be doing of MTAs. > I think it makes sense to use qp encoding for long lines, by breaking > them with the "= at end of line" trick. > That would explain why CTE qp might be useful. Perhaps someone > overlooked this when they changed from qp to 8bit? Thanks. Now I'm sure the 8bit-to-qp conversion has been done by a certain MTA. It is useful when a message contains very long lines of over 998 bytes. ShengHuo may have entrusted folding of them to MTA. However, every MTA always doesn't do so. >>>>> In <027c40e2d84907-gin@mo.msk.ru> >>>>> "Ilya N. Golubev" wrote: [...] > This certainly is not the processing of long lines in body parts as > specified by RFC 2045, which imposes line length limit of 998 octets, > and which concerns both 7bit and 8bit transfer encodings. So, I think Gnus should fold very long lines by itself. An easy way to do that is to replace all `8bit's with `quoted-printable' in the mm-content-transfer-encoding-defaults variable. WDYT? (let (e) (while (setq e (rassoc '(8bit) mm-content-transfer-encoding-defaults)) (setcdr e '(quoted-printable)))) Even if it is done, 7bit is used for short ascii lines. > Another bug of current processing is that it may leave an 8bit body > part with lines longer than allowed by RFC 2045. Actually observed > such a standard violation. > . Created an `.el' file containing 1 pure 7bit line of 1500 octets. > . Attached it to message. > . Evaluated `(mml-to-mime)'. I also tested it sending the .newsrc.eld file to me. The contents were completely broken by MTA. -- Katsumi Yamaoka