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

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Florian Weimer <fw@cygnus.stuttgart.netsurf.de> writes:

> Content-Type: multipart/signed; boundary=YD3LsXFS42OYHhNZ; micalg=pgp-md5;
> 	protocol="application/pgp-signature"

[...]

> 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'.

All the parameters in the Content-Type header are contained in the
MIME handle.

> 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.

Right.

> 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.

Yup.

> 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.

Do you mean that the decryption/verification hook should sweep the
message first, and then transform the message in some way?  By
decoding stuff or verifying stuff, and then replacing that stuff with
the decoded/verified stuff?  Hm.

A different way of doing this would be doing it like I said :-), but
add the "raw" part to the MIME handles as well.  Then it could verify
the headers as well.  And the decryption multipart handle is free to
MIME-decode the handles it gets, and then let Gnus handle the decoded
parts (recursively).

> 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?

Well, why not just quote the "\nFrom " lines before calling the
qp-encode function?  It seems like a cleaner way to do this.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen