	   Some notes on Mutt's PGP integration

	    1997-12-04, tlr <roessler@guug.de>
			      
	       Last updated: 1998-01-30, tlr


While encryption, verification and signing of messages are
done by an externally invoked PGP binary, the key
selection process is handled by mutt itself.  The public
key ring (2.6 or 5.0 format) is parsed; PGP's cached trust
parameters are evaluated and used to select the proper
numerical key IDs for a message's recipients. These key
IDs are then passed to the external PGP binary on the
command line.



Q: "How do it get PGP 5 support working?"

You'll have to set certain configuration options since
mutt's behaviour is completely run-time configurable and
defaults to PGP 2.*.  Assuming that your pgpv, pgpk and
pgpe binaries reside in /usr/local/bin, and your secret
and public key rings reside in $PGPPATH/pubring.pkr and
secring.pkr, respectively, add the following to your
.muttrc:

	set pgp_version=pgp5
	set pgp=/usr/local/bin/pgp
	set pgp_pubring=`echo $PGPPATH`/pubring.pkr
	set pgp_secring=`echo $PGPPATH`/secring.skr



Q: "Why doesn't this work with PGP 5.0i-b8?"

Because pgp-5.0i-b8 is not usable for our purpose:

 pgp-5.0i-b8 doesn't support passing the pass phrase
  through a previously-openend file descriptor (aka
  PGPPASSFD).  This non-existing feature is required by
  mutt.

 pgp-5.0i-b8 doesn't support redirecting specific parts
  of it's output to certain file descriptors (aka
  --OutputInformationFD).

But don't despair, the folks at www.pgpi.com are
apparently working on a legally exported Unix release
version of PGP which will most probably be able to do what
we need.



Q: "Why don't you use the SDK? It's available on the net!"

The old answer on this question said something about
illegal export and so on.  Well, www.pgpi.com has the SDK
for quite some time now, so we could actually start using
it.  

But by now, most of the code needed to do the things we
want to do is in place, and it's mostly independent of the
PGP version you are using - PGP 5.*, PGP 2.*, g10. Support
for other versions can easily be added by changing
pgpinvoke.c.



Q: "People are sending PGP messages which mutt doesn't
    recognize.  What can I do?"

Add the following lines to your ~/.procmailrc (you are
using procmail, aren't you?):

------------------------------

  ##
  ## PGP
  ##
  
  :0 H
  * ^Content-Type: text
  {
      :0 fBw
      * ^-----BEGIN PGP MESSAGE-----
      | formail -I "Content-Type: application/pgp; format=text; x-action=encryptsign"
  
      :0 fBw
      * ^-----BEGIN PGP SIGNED MESSAGE-----
      | formail -I "Content-Type: application/pgp; format=text; x-action=sign"
  }
  
  ##
  ## Add a "Content-Type: application/pgp" header so Mutt will know the
  ## mail is encrypted.
  ##
  
  :0 fBw
  * ^-----BEGIN PGP MESSAGE-----
  | formail -a "Content-Type: application/pgp; format=text; x-action=encryptsign"
  
  ##
  ## Add a "Content-Type: application/pgp" header so Mutt will know the
  ## mail is signed.
  ##
  
  :0 fBw
  * ^-----BEGIN PGP SIGNED MESSAGE-----
  | formail -a "Content-Type: application/pgp; format=text; x-action=sign"
  
------------------------------


Q: "I don't like that PGP/MIME stuff, but want to use the
    old way of PGP-signing my mails.  Can't you include
    that with mutt?"

No.  Application/pgp is not really suited to a world with
MIME, non-textual body parts and similar things.  Anyway,
if you really want to generate these old-style
attachments, include the following macro in your ~/.muttrc
(line breaks for readibility, this is actually one line):

  macro compose S "Fpgp +verbose=0 -fast
  	+clearsig=on\ny^T^Uapplication/pgp; format=text;
	x-action=sign\n"




If you encounter any bugs with mutt's PGP integration,
please drop me a short note about what happens, how to
reproduce it without illegally exporting PGP 5* from the
U.S. and how to fix the problem.  I'll happily integrate
any fixes with mutt's PGP support. 
