RE: [mv] How-To PGP 6.5

[David Babler <dbabler@rigel.orionsys.com>]

******    message to minivend-users from David Babler <dbabler@Rigel.orionsys.com>     ******



On Mon, 22 May 2000, Cameron B. Prince wrote:

> | Pretty Good Privacy(tm) 2.6.2 - Public-key encryption for the masses.
> | (c) 1990-1994 Philip Zimmermann, Phil's Pretty Good Software. 11 Oct 94
> | Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
> | Distributed by the Massachusetts Institute of Technology.
> | Export of this software may be restricted by the U.S. government.
> | Current time: 2000/05/23 22:35 GMT
> 
>  
> ******    message to minivend-users from "Cameron B. Prince" <cbp@InternetExpertsLLC.com>     ******
> 
> I am not sure this is known in this thread, but you can specify the unix cat
> command as the default encryptor and then use pgp in the order route.
> 
> This will encrypt the entire order, but not the attached credit card number.
> 
> I use the following with MV4.04 and PGP5.0:
> 
> Variable    ENCRYPTOR       /bin/cat
> 
> # Main route must be last to make default
> Route main      attach           0
> Route main      credit_card      0
> Route main      cybermode        ""
> Route main      default          1
> Route main      email            __ORDERS_TO__
> Route main      encrypt          1
> Route main      encrypt_program  "/usr/local/bin/pgpe -fat -q -r %s"
> Route main      errors_to        __ORDERS_TO__
> Route main      increment        0
> Route main      pgp_cc_key       ""
> Route main      pgp_key          0xXXXXXXXX
> Route main      receipt          etc/receipt.html
> Route main      report           etc/report
> Route main      supplant         1
> Route main      individual_track orders
> Route main      track            etc/tracking.asc
> 
> 
> Hope this helps,
> 
> Cameron

Sigh. Well, it's a nice idea... unfortunately it doesn't work either. Why?
Because this combination produces an email that isn't readable by Pine
(and probably other MUAs). Yes, the included CC number is *not* seperately
encoded, but the combined message ends up as:

  [beginning of headers]
  Subject: ORDER xxxxxx
  MIME-Version: 1.0
  Content-Type: MULTIPART/MIXED; BOUNDARY="-xxxxxxxx-000:=xxxxx"
  Content-ID: <MiniVnd.4.04.0005....>

  -----BEGIN PGP MESSAGE-----
  Version 2.6.2

  hIwDbzM...
  [rest of armored pgp block]
  -----END PGP MESSAGE-----
  --
  ---xxxxxxxx-000:=xxxxx--

I'll need to look at the MIME RFC again, but I believe Pine interprets
this as "this is a multi-part message, so I'm looking for the first
boundary string"... but it won't see one until the end of the message. It
then picks off what's following (maybe, since the boundary line says it is
the last one) - which is nothing - and shows the resultant "first part" of
what it believes is a multi-part message, which in this case is nothing at
all.

If you manually add a boundary line after the headers and before the PGP
line, it works okay. The problem is that the boundary line, Content-Type,
Content-ID and Content-Description lines end up INSIDE the encrypted pgp
block where the MUA has no way of seeing them. Nobody's seen this before?
I, for one, usually expect that an example actually works <g>. I wonder if
this crops up in version 4 and not in 3 because it's in the 'route'
definitions?

-Dave

-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list