From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79999 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.xemacs.beta,gmane.emacs.gnus.general Subject: Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22 Date: Thu, 22 Sep 2011 20:10:47 +0900 Organization: Emacsen advocacy group Message-ID: References: <877h53i7um.fsf@gilgamesch.quim.ucm.es> <87ty86bqwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87y5xiqs2u.fsf@marauder.physik.uni-ulm.de> <87fwjpoytt.fsf@marauder.physik.uni-ulm.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1316689853 10717 80.91.229.12 (22 Sep 2011 11:10:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Sep 2011 11:10:53 +0000 (UTC) Cc: xemacs-beta@xemacs.org To: ding@gnus.org Original-X-From: xemacs-beta-bounces@xemacs.org Thu Sep 22 13:10:49 2011 Return-path: Envelope-to: gexb-xemacs-beta-2@gmane.org Original-Received: from 99.f7bed1.client.atlantech.net ([209.190.247.153] helo=calypso.tux.org) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6hB2-0003IX-56 for gexb-xemacs-beta-2@gmane.org; Thu, 22 Sep 2011 13:10:48 +0200 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by calypso.tux.org (Postfix) with ESMTP id 5FFA3D180B0; Thu, 22 Sep 2011 07:10:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at tux.org Original-Received: from calypso.tux.org ([127.0.0.1]) by localhost (calypso.tux.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSBluz4QfsC0; Thu, 22 Sep 2011 07:10:40 -0400 (EDT) Original-Received: from calypso2.tux.org (localhost.localdomain [127.0.0.1]) by calypso.tux.org (Postfix) with ESMTP id C66C1D180AB; Thu, 22 Sep 2011 07:10:37 -0400 (EDT) Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by calypso.tux.org (Postfix) with ESMTP id EABABD180AB for ; Thu, 22 Sep 2011 07:10:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at tux.org Original-Received: from calypso.tux.org ([127.0.0.1]) by localhost (calypso.tux.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYV8Hoba2WAx for ; Thu, 22 Sep 2011 07:10:35 -0400 (EDT) Original-Received: from gwyn.tux.org (gwyn.tux.org [207.172.156.132]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by calypso.tux.org (Postfix) with ESMTP id 35CE5D1809D for ; Thu, 22 Sep 2011 07:10:35 -0400 (EDT) Original-Received: from gwyn.tux.org (ident-user@localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id p8MBAY6K012632 for ; Thu, 22 Sep 2011 07:10:34 -0400 Original-Received: (from xemacweb@localhost) by gwyn.tux.org (8.12.11/8.12.11/Submit) id p8MBAY0j012631 for xemacs-beta@calypso.tux.org; Thu, 22 Sep 2011 07:10:34 -0400 Original-Received: from gwyn.tux.org (ident-user@localhost.localdomain [127.0.0.1]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id p8MBAVwM012620 for ; Thu, 22 Sep 2011 07:10:31 -0400 Original-Received: (from mailnull@localhost) by gwyn.tux.org (8.12.11/8.12.11/Submit) id p8MBAVbZ012618 for xemacweb@tux.org; Thu, 22 Sep 2011 07:10:31 -0400 Original-Received: from orlando.hostforweb.net (orlando.hostforweb.net [216.246.45.90]) by gwyn.tux.org (8.12.11/8.12.11) with ESMTP id p8MBAP9h012606 for ; Thu, 22 Sep 2011 07:10:30 -0400 Original-Received: from localhost ([127.0.0.1]:35567) by orlando.hostforweb.net with smtp (Exim 4.69) (envelope-from ) id 1R6hAc-00054k-RG; Thu, 22 Sep 2011 06:10:23 -0500 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.110018 (No Gnus v0.18) Emacs/24.0.50 (i686-pc-cygwin) Cancel-Lock: sha1:LulwnaDIa6zwdq5V6sdjony3sf0= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - orlando.hostforweb.net X-AntiAbuse: Original Domain - xemacs.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jpl.org X-Source: X-Source-Args: X-Source-Dir: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gwyn.tux.org [0.0.0.0]); Thu, 22 Sep 2011 07:10:34 -0400 (EDT) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gwyn.tux.org [0.0.0.0]); Thu, 22 Sep 2011 07:10:31 -0400 (EDT) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-1.6 (gwyn.tux.org [207.172.156.133]); Thu, 22 Sep 2011 07:10:31 -0400 (EDT) X-XEmacs-List: beta X-BeenThere: xemacs-beta@xemacs.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Bug reports and discussion of XEmacs development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: xemacs-beta-bounces@xemacs.org Errors-To: xemacs-beta-bounces@xemacs.org Xref: news.gmane.org gmane.emacs.xemacs.beta:35582 gmane.emacs.gnus.general:79999 Archived-At: Reiner Steib wrote: > On Thu, Sep 22 2011, Katsumi Yamaoka wrote: >> Katsumi Yamaoka wrote: >>> I realized what we have to fix is `mml-compute-boundary-1'. [...] >>> The function looks for ones that are the same as a MIME boundary >>> (e.g., =-=-=) in contents of MIME parts, and updates the boundary >>> pattern so as to be unique, if any. Contents to be checked should >>> be encoded ones, however it doesn't so. As for a file to attach, >>> it reads the file without binding `coding-system-for-read', doesn't >>> encode it, and looks for things like the boundary in it. That is >>> the root cause of an XEmacs 21.5 error. >> >> Done. Not yet tested with XEmacs 21.5 though. >> The new function definition encodes every part in the same way >> practicing when actually sending them in advance and then looks >> for things like a MIME boundary. So it may slow message sending. >> In addition, it assumes that signing and encrypting will never >> generate a boundary pattern in data. > Note that Aidan Kehoe added ".pdf" to `binary-file-regexps' in XEmacs > 21.5 now[1]. I knew it. Aidan's change seems generally useful. But I realized today, avoiding the error in question is not a solution in this case. The root cause is that `mml-compute-boundary-1' was mis-designed. > If the slowdown is notable and the change is only > because of the reported XEmacs problem, it is not necessary, I think. > Or does your commit fix a more general problem? > [1] http://thread.gmane.org/gmane.emacs.xemacs.beta/35574 Yes, it is necessary for not only XEmacs. If the slowdown is not disregarded, I think we will possibly be able to make a change so as to make the mml functions encode a part only once. Though it will need major changes on those functions and will take much time.