From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53966 Path: main.gmane.org!not-for-mail From: Matthias Andree Newsgroups: gmane.emacs.gnus.general Subject: Re: Entering passphrase twice when sending PGP signed message Date: Mon, 15 Sep 2003 02:10:56 +0200 Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1063584699 26050 80.91.224.253 (15 Sep 2003 00:11:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 Sep 2003 00:11:39 +0000 (UTC) Original-X-From: ding-owner+M2506@lists.math.uh.edu Mon Sep 15 02:11:37 2003 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 19ygxt-0006CU-00 for ; Mon, 15 Sep 2003 02:11:37 +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 19ygxO-0005Jn-00; Sun, 14 Sep 2003 19:11:06 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ygxH-0005Jh-00 for ding@lists.math.uh.edu; Sun, 14 Sep 2003 19:10:59 -0500 Original-Received: (qmail 36570 invoked by alias); 15 Sep 2003 00:10:59 -0000 Original-Received: (qmail 36564 invoked from network); 15 Sep 2003 00:10:58 -0000 Original-Received: from pd951f1a0.dip.t-dialin.net (HELO m2a2.dyndns.org) (?/L5EnSSnZ4/Jp6ouQB1jTITw7sIOydQm?@217.81.241.160) by sclp3.sclp.com with SMTP; 15 Sep 2003 00:10:58 -0000 Original-Received: by merlin.emma.line.org (Postfix, from userid 500) id F13A89483C; Mon, 15 Sep 2003 02:10:56 +0200 (CEST) Original-To: ding@gnus.org In-Reply-To: (Simon Josefsson's message of "Mon, 15 Sep 2003 01:49:55 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53966 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53966 Simon Josefsson writes: > E.g., different charsets for different destinations. Sometimes a > specific charset in 8bit in newsgroups is desired (and Gnus get this > right in several hierarchies), while QP is sometimes preferred for > mail. > > I think one difference lies in how an article is _preferred_ to be > sent. Just because you legally can send a news posting in mail, > doesn't make it the best way to send that message via mail. Compare > above where the preferences between mail and news differ. > > It is probably best made customizable IMHO; if a user has opted to > externalize attachments, I think they would expect that to happen for > all messages, even signed or encrypted. > > Yes, but what I think were we disagree is how to find out if the > possible differences apply to a specific message or not. > > I agree with you that it would be _better_ if Gcc did not require > another run of the MIME generator, and simply stored whatever was > sent, but I don't know how to implement that safely, so I'm pointing > out possible problems. If you have a patch in mind that handle the > potential problems, that would prove me wrong easily. I'm afraid I don't speak elisp. As to the (unquoted) UTF-8 in news discussion: RFC-2047 will be around long enough we don't need to care. The other points you raise miss one important point: the signature and the whole point why an article is signed at all. You'll have one particular article (with or without attachments, mail or news or both) signed, and that SIGNATURE MUST BE THE SAME (including time stamp and all that) across all transports and all formatting preferences. Anything else defeats the purpose: if three different signatures for the same document are around, the signature is worthless and will cause more grief than benefit. I'd think that any of the "sign" modes must defeat any variation in the article. Re-encoding and particularly re-signing is a "MUST NOT" in this scenario, so the approach is: 1. make sure to GENERATE (message.el & Co.) a uniform mail that suits all transports (lowest common denominator, saves any case discrimination in MML+PGG or other postprocessors). 2. make sure to POSTPROCESS uniformly 3. diversity only to add mandatory headers for the respective transport (SMTP, NNTP) It's simply Not The Right Thing to have different signatures when a posting is posted & mailed, no matter how many options, buts and ifs you attach. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95