From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/53965 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Entering passphrase twice when sending PGP signed message Date: Mon, 15 Sep 2003 01:49:55 +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 1063583424 24703 80.91.224.253 (14 Sep 2003 23:50:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 14 Sep 2003 23:50:24 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M2505@lists.math.uh.edu Mon Sep 15 01:50:23 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 19ygdK-0005Vb-00 for ; Mon, 15 Sep 2003 01:50:22 +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 19ygd8-0005EW-00; Sun, 14 Sep 2003 18:50:10 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19ygd0-0005EQ-00 for ding@lists.math.uh.edu; Sun, 14 Sep 2003 18:50:02 -0500 Original-Received: (qmail 35723 invoked by alias); 14 Sep 2003 23:50:02 -0000 Original-Received: (qmail 35717 invoked from network); 14 Sep 2003 23:50:01 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by sclp3.sclp.com with SMTP; 14 Sep 2003 23:50:01 -0000 Original-Received: from latte.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h8ENntdk003034 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 15 Sep 2003 01:49:57 +0200 Original-To: Matthias Andree Mail-Copies-To: nobody X-Payment: hashcash 1.2 0:030914:ma@dt.e-technik.uni-dortmund.de:bacb5fe9eb3e6889 X-Hashcash: 0:030914:ma@dt.e-technik.uni-dortmund.de:bacb5fe9eb3e6889 X-Payment: hashcash 1.2 0:030914:ding@gnus.org:7b858a30bde2519f X-Hashcash: 0:030914:ding@gnus.org:7b858a30bde2519f In-Reply-To: (Matthias Andree's message of "Mon, 15 Sep 2003 01:12:15 +0200") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:53965 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:53965 Matthias Andree writes: >> The advantage of generate Gcc separately from mail and news is, of >> course, that your local copy isn't restricted to the arbitrary, and >> sometimes incompatible, limitations in mail and news, > > What are these incompatible limitations? 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. >> and to support Gcc rewriting functionality, >> e.g. gnus-gcc-externalize-attachments. > > AFAICS, any News posting can be sent as a mail, technically, because > RFC-1036 requires a subset of RFC-2822. IOW, if Gnus only uses > constructs legal in News, we don't need this distinction except to > choose between SMTP and NNTP -- which is the posting-method in the first > place. > > I wonder if there's anything that mail allows for but news doesn't > that's needed in real life. 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. >> (The logic would have to, besides checking for the intersection >> between (2)822 and 1036(bis), also check if any of the enabled Gcc >> rewriting features would modify the "object". > > The logic would be to only generate RFC-1036 + RFC-2045..2049 (+ 2231), > even for mail. I. e. 7bit US-ASCII headers, with limited folding and > limited RFC-2822 syntax. Still doesn't solve the case where mail and news wants different charsets. Non-ASCII in news is not standardized AFAIK, and using MIME as defined for mail does not seem to be a conservative solution. USEFOR has discussed incompatible solutions, and at least some time ago people argued for using 8bit UTF-8 in headers. > Any archival or "keep a local copy" function MUST NOT tamper with the > content in any case, particularly not when the content is being > signed. gnus-gcc-externalize-attachments MUST NOT apply to signed > material. 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. >> Even so, it must have knowledge about certain MML tags, such as >> security tags, which generate different output each time, but can >> (probably, and not in all situations) be considered equal, for Gcc:ing >> purposes. Also remember that MIME encoding can be different in news >> than from mail too.) > > How does MIME encoding for news differ from MIME encoding for mail? > > All these possible differences look academic to me ATM. The real-world > differences are: Path vs. References and Newsgroups vs. To. That's it. 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. >> There are already features that require the saved article to differ >> from what was sent, so it is not always a bad thing, assuming people >> do use those features. > > I really wonder what features these are. Confusion Inductor v1.0 perhaps. * gnus-gcc-externalize-attachments * automatic message/partial, do you really want the GCC group to contain all X partial parts, instead of one message? * different charsets, content-transfer-encoding preferences. Perhaps there are more.