From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/80621 Path: news.gmane.org!not-for-mail From: Katsumi Yamaoka Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus asking for key twice Date: Tue, 29 Nov 2011 19:00:54 +0900 Organization: Emacsen advocacy group Message-ID: References: <87sjl8dt6t.fsf@earth.home> <878vmz7uvi.fsf@earth.home> <8762i36fig.fsf@earth.home> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1322560918 1994 80.91.229.12 (29 Nov 2011 10:01:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2011 10:01:58 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M28903@lists.math.uh.edu Tue Nov 29 11:01:54 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 1RVKVd-0006jk-6p for ding-account@gmane.org; Tue, 29 Nov 2011 11:01:53 +0100 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 1RVKV1-0002UH-3t; Tue, 29 Nov 2011 04:01:15 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1RVKUz-0002U5-Rx for ding@lists.math.uh.edu; Tue, 29 Nov 2011 04:01:13 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RVKUy-00031o-FI for ding@lists.math.uh.edu; Tue, 29 Nov 2011 04:01:13 -0600 Original-Received: from orlando.hostforweb.net ([216.246.45.90]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1RVKUw-0006At-Cj for ding@gnus.org; Tue, 29 Nov 2011 11:01:10 +0100 Original-Received: from localhost ([127.0.0.1]:47694) by orlando.hostforweb.net with smtp (Exim 4.69) (envelope-from ) id 1RVKUr-0007Ui-V0 for ding@gnus.org; Tue, 29 Nov 2011 04:01:06 -0600 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.91 (i686-pc-cygwin) Cancel-Lock: sha1:YwLn/ldBPCCvZICu3aWWGvZOz3g= 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 - gnus.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-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:80621 Archived-At: Adam wrote: > Adam writes: >> Adam writes: >> >>> Whenever I send a signed mail which has a Gcc'ed header pointing to my >>> archive group, I am asked to select the sign key twice - once before >>> connecting to my smtp server, and once after actually sending the mail. >>> mm-sign-option is set to guided. When there is no Gcc header, I am only >>> asked once. >>> >>> Is this a bug or a feature? >> >> I investigated. gnus-inews-do-gcc is calling >> message-encode-message-body, which internally triggers the key >> selection dialogue. This looks like a real design flaw to me. Gnus >> should encode the message only once, and preserve the result. > The easiest solution is to add a new hook. It should be called in > messages-send-mail right after the message has been dispatched to the > server, with the current buffer being the actual message buffer that has > been sent. Gnus then should add gnus-inews-do-gcc to this hook, and use > the processed buffer to save. > Do I sound reasonable? Whats a good name for such a new hook? A sent message and Gcc'd one are not exactly the same. AFAICT, the Gcc header remains in a Gcc copy but is deleted in the one sent. Maybe there are other differences besides I cannot recall. So, we will have to verify all the message sending functions and situations in order to make such a change, I think. How about making the expiry time of the passphrase cache longer? The `mml-secure-passphrase-cache-expiry' controls it; the default value might be too short. If you want to try changing it briefly where mml2015.elc has already been loaded, you'll need to change `mml2015-passphrase-cache-expiry' instead (it inherits the value of `mml-secure-passphrase-cache-expiry' as the default value).