From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/79998 Path: news.gmane.org!not-for-mail From: Uwe Brauer Newsgroups: gmane.emacs.gnus.general,gmane.emacs.xemacs.beta Subject: Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22 Date: Thu, 22 Sep 2011 11:39:15 +0200 Message-ID: <87vcskhq64.fsf@gilgamesch.quim.ucm.es> References: <877h53i7um.fsf@gilgamesch.quim.ucm.es> <87ty86bqwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87y5xiqs2u.fsf@marauder.physik.uni-ulm.de> Reply-To: Uwe Brauer NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1316684426 4952 80.91.229.12 (22 Sep 2011 09:40:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Sep 2011 09:40:26 +0000 (UTC) Cc: ding@gnus.org, xemacs-beta@xemacs.org To: Katsumi Yamaoka Original-X-From: ding-owner+M28292@lists.math.uh.edu Thu Sep 22 11:40:21 2011 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6flU-0004rD-L5 for ding-account@gmane.org; Thu, 22 Sep 2011 11:40:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1R6fkq-0005Z4-WD; Thu, 22 Sep 2011 04:39:41 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1R6fkp-0005Ys-AY for ding@lists.math.uh.edu; Thu, 22 Sep 2011 04:39:39 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1R6fkd-0004zI-Sh for ding@lists.math.uh.edu; Thu, 22 Sep 2011 04:39:38 -0500 Original-Received: from mail-wy0-f172.google.com ([74.125.82.172]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1R6fkc-0001Jx-5s for ding@gnus.org; Thu, 22 Sep 2011 11:39:26 +0200 Original-Received: by wyh21 with SMTP id 21so832099wyh.17 for ; Thu, 22 Sep 2011 02:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:x-mailer:from:to:cc:subject:references:reply-to:x-hashcash :x-hashcash:x-hashcash:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=6+3Sd/Tz0tyDGiI37/MGBsyTAly0cnGQeQ1veWiL3ac=; b=YP2OPqDGeVlMrvVztF+LtlJN9bLKTowRDuG4CD9FeEfIbZzu6uO3X21l3JdzR71Geh YYg75PekEMsNZTz53sFBZlKdIcz5pM/hYiQ4mx6feQ+/8s5xEn+z0ZuweC3gW+vKLNc6 sj8hdqk1T2pi5gAQuh74/I20b6ZIIwAZFf8ts= Original-Received: by 10.227.11.132 with SMTP id t4mr1886625wbt.93.1316684360580; Thu, 22 Sep 2011 02:39:20 -0700 (PDT) Original-Received: from gilgamesch.quim.ucm.es (gilgamesch.quim.ucm.es. [147.96.12.99]) by mx.google.com with ESMTPS id es10sm4871634wbb.4.2011.09.22.02.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 02:39:18 -0700 (PDT) X-Mailer: 21.5 (beta29) "garbanzo" XEmacs Lucid (via feedmail 11-beta-1 I) X-Hashcash: 1:20:110922:yamaoka@jpl.org::1beeChdLbHqaKFXr:001yjI X-Hashcash: 1:20:110922:ding@gnus.org::aYL0yaO9S+jyNKYv:00006BaI X-Hashcash: 1:20:110922:xemacs-beta@xemacs.org::UkE1Mzu20Vx+XNxj:0000000000000000000000000000000000000006/M0 In-Reply-To: (Katsumi Yamaoka's message of "Thu, 22 Sep 2011 13:44:21 +0900") User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.5-b29 (linux) X-Spam-Score: -2.9 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:79998 gmane.emacs.xemacs.beta:35579 Archived-At: >> Regarding Re: [Bug: 21.5-b29] gnus can't send in 21.5.29 but in 21.4.22; Katsumi Yamaoka adds: > 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. Hm Aidan already committed a patch to Xemacs which takes care of the problem. Given that the sending function is already not very fast, I would recommend not to implement your solution, but this is just a personal opinion. Uwe Brauer