🚀 go-pugleaf

I made some wrapper scripts around PGP a while back to handle this sort of
thing.  I *do* use 'text/x-pgp' and 'pgp -a' because it allows people with
pgp but not MIME to still read the messages.


Here's a start for mh + MIME users: an "editor" that runs out of the MH
"What now?" prompt, and PGP encodes your message in a nice mhn-processable
format.  Note that this works only on MH 6.7.2-MIME+mtr or later.

Call this script "pgpedit" and make links to it called: pgpe, pgpes, pgpk,
pgka.

After you're done writing your message, type "edit pgpe" at the What now?
prompt, it will try to figure out who you're sending to, encode with their
key if you have it, and format it for MHN.  Then type "edit mhn" and voila
your message is ready to go.  The type is "text/x-pgp" and needs an
.mh_profile line like:

mhn-show-text/x-pgp: pgp -m %F

You can call it by different names for different options, notable "pgpk" to
send someone your public key, or "pgpka" to send the whole keyring.
Anyway, here's the script.

#!/bin/sh

case `basename $0` in
        pgpes) opt="-feast" ;;
        pgps) opt="-staf +clearsig=on" ;;
        pgpe) opt="-feat" ;;
        pgpka) pgp -kxa "" pubkey$$
                (echo '#<text/x-pgp';cat pubkey$$.asc;echo '#') >> $*
                rm -f pubkey$$.asc
                exit 0 ;;
        pgpk)   pgp -kxa $USER pubkey$$
                (echo '#<text/x-pgp';cat pubkey$$.asc;echo '#') >> $* 
                rm -f pubkey$$.asc 
                exit 0 ;;
esac

if head -20 $* | grep -s '^--------$' ; then
        sed -ne '1,/^--------$/p' $* > header$$
        sed -e '1,/^--------$/d' $* > body$$
else
        sed -ne '1,/^$/p' $* > header$$
        sed -e '1,/^$/d' $* > body$$
fi

to=`sed -ne 's/^[tT]o: //p' header$$`

if [ -n "$to" ] ; then
        if pgp -kv "$to" 2>&1 | grep -s '^pub' ; then
                echo Using public key for $to.
                opt="$opt $to"
        fi
fi

(cat header$$;echo '#<text/x-pgp';pgp $opt < body$$;echo '#')  > $*
rm -f header$$ body$$
--

) Dave Disser                 UM-CAEN User Services    
) disser@engin.umich.edu      229 Chrysler Center    
) (313) 763-3067              Ann Arbor, MI 48109-2092

In article <C18C4r.6K8@wizzy.com> andyr@wizzy.com (Andy Rabagliati) writes:

   Has anyone been working on a pgp interface for MIME ?


here's what a friend of mine have been using (under mhn):

mhn-show-application/x-pgp: %ppgp -m %F
mhn-store-application/x-pgp: %m%P.pgp

which seems to work fine.  i initially tried text/x-pgp but for some
reason the encrypted file wasn't being transferred properly.  i don't
use the -a option of pgp.  so the procedure is much like this:

 edit file
 pgp -e file user_name
 comp
  [insert proper directives for mhn to insert a application/x-pgp file]
 send the message and delete the original files.

works like a charm.  now if i could only get mh to auto-encrypt my
messages, i'd be a really happy camper.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Gradual Student/Systems Guy  Department of Computer Science
Internet:   khera@cs.duke.edu             Box 90129
            (MIME mail accepted)          Durham, NC 27708-0129 (919)660-6528

In article <C18C4r.6K8@wizzy.com>,
andyr@wizzy.com (Andy Rabagliati) writes:
> In correspondence with Tobias Weingartner <weingart@inf.ethz.ch> he
> suggests 
> TW> I think pgp data should go so:
> TW> 
> TW> Content-Type: text/plain; charset=ISO-8859-1
> TW> Content-transfer-encoding: X-PGP-{VERSION}

No!  PGP is not a content-transfer-encoding.  If anything, its an
application.

I strongly suggest that any PGP-MIME format should be compatible with
the proposed PEM-MIME format, described in dratf-ietf-pem-mime-00.txt
available from your friendly Internet-Drafts repository.  Here's the
example from section 7 of the Nov 1992 version of the draft.  (Note,
as always that I-D's are subject to change without notice.)

draft>   7.  An Example
draft>
draft>   For example, suppose the following message was being readied
draft>   for submission:
draft>
draft>        Date:    Thu, 12 Nov 1992 21:43:40 -0800
draft>        From:    scrocker@tis.com
draft>        To:      ned@innosoft.com
draft>        Subject: example #1
draft>        MIME-Version:    1.0
draft>        Content-Type:    text/plain; charset=us-ascii
draft>        Content-Privacy: mic-clear
draft>
draft>        Hi Ned.  See how much nicer this works!
draft>
draft>   After applying pre-submission algorithm, the message submitted
draft>   for delivery would appear as:
draft>
draft>        Date:    Thu, 12 Nov 1992 21:43:40 -0800
draft>        From:    scrocker@tis.com
draft>        To:      ned@innosoft.com
draft>        Subject: example #1
draft>        MIME-Version: 1.0
draft>        Content-Type: multipart/pem; boundary="next-part";
draft>                                     privacy=mic-clear
draft>
              [ The draft forgot the boundary line here.  --apb ]
draft>        Content-Type: text/plain; charset=us-ascii
draft>
draft>        Hi Ned.  See how much nicer this works!
draft>
draft>        --next-part
draft>        Content-Type: application/pem
draft>
draft>        Proc-Type: 4,MIC-CLEAR
draft>        Content-Domain: RFC822
draft>        Originator-ID-Asymmetric: ...
draft>        MIC-Info: RSA-MD5,RSA, ...
draft>
draft>        --next-part--
draft>
draft>   After applying the post-delivery algorithm, the resulting
draft>   message would appear as:
draft>
draft>        Date:    Thu, 12 Nov 1992 21:43:40 -0800
draft>        From:    scrocker@tis.com
draft>        To:      ned@innosoft.com
draft>        Subject: example #1
draft>        MIME-Version:      1.0
draft>        Content-Type:      text/plain; charset=us-ascii
draft>        Content-Annotation: mic-clear;
draft>                            Thu, 12 Nov 1992 22:13:40 -0800
draft>                            (integrity verified)
draft>
draft>        Hi Ned.  See how much nicer this works!
draft>
draft>   Of course, as the message being submitted was only plain text,
draft>   the Content-Type: header could be ommitted.  In that case,
draft>   after applying the pre-submission algorithm, the message
draft>   submitted for delivery would appear as:
draft>
draft>        Date:    Thu, 12 Nov 1992 21:43:40 -0800
draft>        From:    scrocker@tis.com
draft>        To:      ned@innosoft.com
draft>        Subject: example #1
draft>        MIME-Version: 1.0
draft>        Content-Type: multipart/pem; boundary="next-part";
draft>                                     privacy=mic-clear
draft>
              [ The draft forgot the boundary line here.  --apb ]
	      [ also the blank line below the boundary line.   --apb ]
draft>        Hi Ned.  See how much nicer this works!
draft>
draft>        --next-part
draft>        Content-Type: application/pem
draft>
draft>        Proc-Type: 4,MIC-CLEAR
draft>        Content-Domain: RFC822
draft>        Originator-ID-Asymmetric: ...
draft>        MIC-Info: RSA-MD5,RSA, ...
draft>
draft>        --next-part--

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za

In article <C18C4r.6K8@wizzy.com> andyr@wizzy.com (Andy Rabagliati) writes:
>Has anyone been working on a pgp interface for MIME ?
>[...]
>In correspondence with Tobias Weingartner <weingart@inf.ethz.ch> he
>suggests 
>[...]
>TW> Content-Type: text/plain; charset=ISO-8859-1
>TW> Content-transfer-encoding: X-PGP-{VERSION}
>TW> 
>TW> Where {VERSION} would be: 2.0, 2.1, etc...

No!  You should use an application sub-type... that way you're
MIME conformant.  If you define a new transfer encoding, the
message is NOT A MIME MESSAGE.

Sigh... why do people always think that standards need to be
improved upon?
-- 
Jurgen Botz, jbotz@mtholyoke.edu
Northampton, MA, USA