From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80026 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen 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: Mon, 26 Sep 2011 21:19:41 +0200 Message-ID: References: <877h53i7um.fsf@gilgamesch.quim.ucm.es> <87ty86bqwj.fsf@uwakimon.sk.tsukuba.ac.jp> <87y5xiqs2u.fsf@marauder.physik.uni-ulm.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1317064811 14608 80.91.229.12 (26 Sep 2011 19:20:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 26 Sep 2011 19:20:11 +0000 (UTC) Cc: ding@gnus.org, xemacs-beta@xemacs.org To: Katsumi Yamaoka Original-X-From: ding-owner+M28321@lists.math.uh.edu Mon Sep 26 21:20:06 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 1R8Gii-0006fx-Rb for ding-account@gmane.org; Mon, 26 Sep 2011 21:20:05 +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 1R8Gid-00049O-OQ; Mon, 26 Sep 2011 14:19:59 -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 1R8Gic-00049C-JY for ding@lists.math.uh.edu; Mon, 26 Sep 2011 14:19:58 -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 1R8Gib-0000Wo-CU for ding@lists.math.uh.edu; Mon, 26 Sep 2011 14:19:58 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1R8Gia-00055N-0u for ding@gnus.org; Mon, 26 Sep 2011 21:19:56 +0200 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1R8GiQ-00046h-Gy; Mon, 26 Sep 2011 21:19:46 +0200 In-Reply-To: (Katsumi Yamaoka's message of "Thu, 22 Sep 2011 13:44:21 +0900") User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAElBMVEUAAABlRkoqGCDCopgK BAcBAAEbIqgdAAACfUlEQVQ4jWVTS5bjIAzU5ME+ArwPHx8AKweIadiTDLr/VUbYmZ7uHt7DJEiq UkkCmLtm5tGgtsFtJF3Wqm4Au3FPH4x/bzNPDG7AWNxzd8Yz3p6IflH4eBpjqhjQe3GcW744o8Lz CsDrK9WSauXaGo/R+mDWHcALjxxf10O2QCUdzLf7DuWhDaTC1X2PgNJfBOvzoX4aAEYGHlDTfwZo P4nnqnKnPlPq77OqFvj8qb96v6x3IkCy+g6lLe1XYPi4vyH0iZbYkijmXop8/mHpUGPODKHreOg/ IzTofY10Uw/uT/oqKilaYp65umgEik9+rbu2LRoHCtedgDnc3mgdXnvGVe33SBuwfh00kgPDZXdJ 7xbpMKiTHyI2LYadmkrl/lmKoioVn5MRZ62HF5Uwjlog5xJNSHYVPo+Tc3YYPnIfzqJhlDmTmZgR oIQ55hCNpfWy9Dq88/BWcYmbi97TVaEw2CWKjsOkrBGg1V/VbKrNGSofdUKLSJv4qAa8W0ktHCp+ bXb7oEV8LqDYW3sXqINis3e/zgnQMF4ywxXO/qo1bosgdjHJ9KPMDp990mOO4+WmjXa7TVK3v0U/ 0nsuA1tAWsX/4JBkQll5+FQxZCn9YZj56irvgPet+mwzmn5GTEMbbaA1wRJlbPCG6npwXI23GKLc G2GTN9gnRWt+dxIxRHNtfPajT4om9fEkhcnr0PDydKYrIyUYgk/2Pv//tiiGQ0jDHOQ+2wfMPk3D XNC5oCfy2QhvsYQZRgkhpBQsWsrZlBJECErGI4i25MkIPslz3wUv1dalUX2+CjEguZFmAk5PgY25 7TMdolXASbo6hTPUEelcrtDh0GbZ+A9UEZYwf50T1gAAAABJRU5ErkJggg== X-Now-Playing: Tuxedomoon's _Suite En Sous-Sol-Time To Lose-Short Stories_: "Time To Lose" X-MailScanner-ID: 1R8GiQ-00046h-Gy MailScanner-NULL-Check: 1317669586.66098@D4YvPz6CTJNgel7e5X7t/Q X-Spam-Status: No X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:80026 gmane.emacs.xemacs.beta:35597 Archived-At: Katsumi Yamaoka writes: > Done. Great; thanks. > 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. But it should be done -- otherwise we can't be sure of successfully sending these messages, so I think your fix is totally the right thing. > In addition, it assumes that signing and encrypting will never > generate a boundary pattern in data. True. Hm... is that possible? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/