From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/23246 Path: main.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.gnus.general Subject: MIME-PGP (was: Re: I'm alive!) Date: 13 Jun 1999 14:48:05 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035161015 978 80.91.224.250 (21 Oct 2002 00:43:35 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:43:35 +0000 (UTC) Return-Path: Original-Received: from farabi.math.uh.edu (farabi.math.uh.edu [129.7.128.57]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id IAA19135 for ; Sun, 13 Jun 1999 08:44:31 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by farabi.math.uh.edu (8.9.1/8.9.1) with ESMTP id HAB18091; Sun, 13 Jun 1999 07:44:14 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sun, 13 Jun 1999 07:44:36 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id HAA25307 for ; Sun, 13 Jun 1999 07:44:24 -0500 (CDT) Original-Received: from delos.stuttgart.netsurf.de (delos.stuttgart.netsurf.de [194.163.56.1]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id IAA19129 for ; Sun, 13 Jun 1999 08:43:27 -0400 (EDT) Original-Received: by delos.stuttgart.netsurf.de (Smail3.2.0.103/delos.LF.net) via LF.net GmbH Internet Services via remoteip 194.163.56.20 via remotehost cygnus.stuttgart.netsurf.de with esmtp for mailhost.sclp.com id m10t9bh-000RzoC; Sun, 13 Jun 1999 14:43:25 +0200 (MET DST) Original-Received: from deneb.cygnus.stuttgart.netsurf.de (deneb.cygnus.stuttgart.netsurf.de [192.168.0.1]) by cygnus.stuttgart.netsurf.de (8.8.7/8.8.7) with ESMTP id OAA00757 for ; Sun, 13 Jun 1999 14:44:35 +0200 Original-Received: (from fw@localhost) by deneb.cygnus.stuttgart.netsurf.de (8.9.3/8.9.3) id OAA03430; Sun, 13 Jun 1999 14:48:05 +0200 Original-To: ding@gnus.org Original-Lines: 170 User-Agent: Gnus/5.070086 (Pterodactyl Gnus v0.86) XEmacs/21.1 (20 Minutes to Nikko) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:23246 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:23246 Lars Magne Ingebrigtsen writes: > There is a `gnus-mime-multipart-functions' variable, and it can do > whatever it wants with the multiparts it receives. (I added this to > make it possible to do RFC 2015.) I haven't really looked all that > closely at what a function that were to do RFC 2015 decoding would > have to do, though. I don't think that this hook can be used. Let's have a look at the following message which conforms to RFC 2015: ---------------------------------------------------------------------- Date: Sun, 13 Jun 1999 13:32:15 +0200 From: mutt@cygnus.stuttgart.netsurf.de To: Florian Weimer Subject: Signed with attachment X-Gnus-Mail-Source: directory:~/Mail/INCOMING/ Message-ID: <19990613133215.B2917@deneb.cygnus.stuttgart.netsurf.de> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=YD3LsXFS42OYHhNZ; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.1i Lines: 50 Xref: deneb.cygnus.stuttgart.netsurf.de misc:178 --YD3LsXFS42OYHhNZ Content-Type: multipart/mixed; boundary=ADZbWkCsHQ7r3kzd --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Description: Message A signed message with an attachment. --ADZbWkCsHQ7r3kzd Content-Type: text/plain; charset=us-ascii Content-Description: Assembler code Content-Disposition: attachment; filename="t.s" .file "t.c" .version "01.01" gcc2_compiled.: .text .align 4 .globl foo .type foo,@function foo: pushl %ebp movl %esp,%ebp movl 4660,%eax movl %ebp,%esp popl %ebp ret .Lfe1: .size foo,.Lfe1-foo .ident "GCC: (GNU) egcs-2.91.57 19980901 (egcs-1.1 release)" --ADZbWkCsHQ7r3kzd-- --YD3LsXFS42OYHhNZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQBFAwUBN2OWvzyNAitYx2a1AQHgRgGA5fYIevSaZao25ZMudtaN+PDAbLIze3rn aChV9rUthqm8lOp2nsD313AiGxpJwhr/ =eKxI -----END PGP SIGNATURE----- --YD3LsXFS42OYHhNZ-- ---------------------------------------------------------------------- The `micalg' and `protocol' parameters in the primary `Content-Type' header are vital, but it seems as if they aren't passed to functions listed in `gnus-mime-multipart-functions'. In addition, everything between the first and second `--YD3LsXFS42OYHhNZ' boundary is covered by the PGP signature, including the MIME headers and boundaries, which get lost during the translation from raw message text to MIME handles. Finally, in the `multipart/encrypted' case, as shown below, the encrypted part contains data which has to be put through the MIME translation process as well. This has not happend during the first translation, because obviously, the data contained in the part wasn't readable then. ---------------------------------------------------------------------- Date: Sun, 13 Jun 1999 12:17:23 +0200 From: mutt@cygnus.stuttgart.netsurf.de To: Florian Weimer Subject: test X-Gnus-Mail-Source: directory:~/Mail/INCOMING/ Message-ID: <19990613121723.A2917@deneb.cygnus.stuttgart.netsurf.de> Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary=Kj7319i9nmIyA2yE; protocol="application/pgp-encrypted" X-Mailer: Mutt 0.95.1i Lines: 24 Xref: deneb.cygnus.stuttgart.netsurf.de misc:177 --Kj7319i9nmIyA2yE Content-Type: application/pgp-encrypted Version: 1 --Kj7319i9nmIyA2yE Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: 2.6.3i hIwDbSMVHQQS92EBBACFUjqnO8eDDinYfo183PYgd7GQInt3BHhZCnRP807uGwra F2zAc4PBgGhBKYnU/nZiOZvqYVh+CA7JqjTzku0sM12RLg2R6bg2nB+V+CzOkK8R 5TQczKGI/Tyhs/ktej0pbMxR5rt5FwvDuB8hcCNKPPTfaeu/4RQsfnlaxsJXm4Q8 AzyNAitYx2a1AQGAug9oiCsl6+omafWxqlJBohEjXJCKjAASE9pfBHNqk6vhUMx3 qbLv6ai7AXOa9voApgAAAFwh2dnqGHsvY9WxPhIGgwkE9/CdjCX8p+jIG50F05Qe HUyZLv61ibRCm8EYEO2SBUO0brS2u7wtJuOhtGO03SLiDuPuZh2gaqIkpB7xwDxv T3BUKwC4W9ZIVybX7A== =oXnI -----END PGP MESSAGE----- --Kj7319i9nmIyA2yE-- ---------------------------------------------------------------------- The encrypted data looks like this (but it might contain attachments and other MIME mess as well): ---------------------------------------------------------------------- Content-Type: text/plain; charset=us-ascii Just another test ---------------------------------------------------------------------- IMHO, an appropiate hook into `mm-dissect-buffer' would allow to do all these things in a relatively straightforward manner. `gnus-mime-multipart-functions' could be used to put information gathered during the MIME translation process (signer, valid/invalid signature, beginning/end of signed data) into the *Article* buffer in a nicely formatted form. For the other way round, i.e. creating MIME-PGP messages, a hook into `mml-generate-mime' which allows post-processing the generated message text (encryption, added signature) should be sufficient. A hook into into `mml-generate-mime-1' surely would be more general because it would allow to sign and/or encrypt only some parts of a message in a MIME-PGP compliant way. But I don't think this is really necessary. > I don't think this belongs in `quoted-printable-encode-region'. I > certainly wouldn't want to see (say) a news article get bumped up from > 7bit to qouted-printable just because there's a "\nFrom " in the > message somewhere. I think the RFC 2015 function itself should do > this encoding -- by calling `quoted-printable-encode-region', and then > encoding the "\nFrom "'s itself. I didn't want to suggest that this should be made the default behaviour. But what if `quoted-printable-encode-region' checked a global variable and encodes "\nFrom " if it is non-nil -- this wouldn't change anything for regular messages? This variable should never be set explicitly, but bound by a wrapper of `message-encode-message-body'. This way, the information that "\nFrom " has to be encoded can easily be passed down the encoding process. Of course, the checks whether to call `quoted-printable-encode-region' have to be changed as well, so that this function is really called if the flag variable is non-nil and there's a line beginning with `From ' in the text to be encoded.