MIME-PGP (was: Re: I'm alive!)

[Florian Weimer <fw@cygnus.stuttgart.netsurf.de>]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> 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 <fw@deneb.cygnus.stuttgart.netsurf.de>
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 <fw@deneb.cygnus.stuttgart.netsurf.de>
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.