Things to do:

        - split mails for receipients not having a key

        - When sending a message to someone whose public key I don't have,
          how about automagically SIGNING that message?

        - replace subject line with a random cookie and put the real subject
          in the encrypted body.
From dino.dinoco.de!teralon.GUN.de!atnf.CSIRO.AU!rgooch Tue, 12 Apr 94 20:33:18 +0100
Received: by peti.GUN.de ($Id: sendmail.c,v 1.4 1994/02/13 04:50:43 wusel Exp wusel $ (Feb 13 1994, 05:52:58))
          id <1age@peti.GUN.de>; Tue, 12 Apr 94 20:33:18 +0100
Received: by dino.dinoco.de (V1.16/wusel)
          id <dh40@dino.dinoco.de>; Tue, 12 Apr 94 12:16:30 +0100
Received: by teralon.GUN.de (Smail3.1.28.1)
          from rs1.rrz.Uni-Koeln.DE with smtp
          id <m0pqgMZ-0004PPA>; Tue, 12 Apr 94 11:10 CET
Received: from rp.CSIRO.AU (crux.rp.CSIRO.AU) by rs1.rrz.Uni-Koeln.DE with SMTP id AA80059
  (5.67b/IDA-1.5 for <simons@peti.gun.de>); Tue, 12 Apr 1994 11:07:31 +0200
Received: from wyvern.rp.CSIRO.AU by rp.CSIRO.AU (4.1/RPAT-2.09)
        id AA23319; Tue, 12 Apr 94 19:05:27 EST
Received: by wyvern.rp.CSIRO.AU (4.1/SMI-4.1/RPAT-1.02)
        id AA24603; Tue, 12 Apr 94 19:05:03 EST
Date: Tue, 12 Apr 94 19:05:03 EST
Message-Id: <9404120905.AA24603@wyvern.rp.CSIRO.AU>
In-Reply-To: <1e9c3836.83d63-simons@peti.GUN.de>
References: <1e9c3836.83d63-simons@peti.GUN.de>
        <9404090419.AA13298@wyvern.rp.CSIRO.AU>
From: rgooch@atnf.CSIRO.AU (Richard Gooch)
To: simons@peti.gun.de (Peter Simons)
Subject: Re: PGPSendmail for UNIX/AmigaOS
X-Status: OR

======== BEGIN OF PGP BLOCK ========
  Hi, Peter.

 > I just read your code and it looks like joining both versions would be
 > possible but would require pretty much effort. What do you think?

  I've been reading your code (it's somewhat bigger!), and it looks
like it might be hard to merge. I guess we have a few options:

1)  Don't do anything (the politician's option :-)

2)  Merge one into the other (hard)

3)  Take ideas from one and add it to the other, making an
Uber-PGPsendmail package :-) and dump the other in  /dev/null

4)  Take ideas from each other. You target Amigas, I target Unices,
have separate source code for each, but distribute it together so that
people don't get confused about "competing" packages (the ultimate
aim, I think).

  (3) or (4) look to be the real choice. What do you think?

 >  > Great. One thing I'd like to throw out is ideas for header keywords.
 > 
 > That is indeed a good idea. Where do you place this keyword? I would
 > use it as follows:
 > 
 >      To: address
 >      Subject: secret: some subject
 > 
 >      mailbody

  Hm. I saw it more as:

To: address(es)
Subject: hi there
secure: always return-receipt
[message body]

OR:

To: address(es)
Subject: Hi there
secure
return-receipt
[message body]

  Or some such.

 > Then PGPSendmail would scan the subject-line, recognize all keywords
 > and insert "some subject" instead. One could even combine keywords,
 > such as
 > 
 >      Subject: secret+cookie
 > 
 > for example. "cookie" should replace the subject line with a random
 > cookie from a database. :-) What do you think?

  Hm. I had planned to move the subject down into the encrpyted
section too, but I figured on a plain "Encrpyted Message" subject line.

 >  > I (quickly) incorporated the "secure" keyword. I've thought of an
 >  > "insecure" keyword, as well as "return-receipt" or "discard-receipt"
 >  > keywords. The default action for my PGPsendmail is "return-receipt".
 > 
 > What do these keywords mean exactly? "return-receipt" is obvious, but
 > what do the others do?

  "insecure" is don't encrypt, don't even bother checking for keys.

 >  > Also, building in more smarts, either with header keywords or
 >  > configuration files to link Email addresses to public keys (for those
 >  > who have a different Email address from what is on their key) might
 >  > also be worthwhile.
 > 
 > Very nice idea!! Hey Richard, you're worth a gold bar. I'll rename my
 > TODO file to RIL (Richard Idea List). :-)

  Aw, shucks. Another idea is to configure a resource file so that a
user can default to "secure" "return-receipt" or whatever they choose.
Also, keys/recipients can be tagged to always encrypt or never encrypt
(why not just remove them from the keyring, you ask? Well, someone
whooo doesn't want to receive encrypted messages, but has signed my
key. I don't want an "unknown signator" entry :-)

				Regards,

					Richard....
======== END OF PGP BLOCK ========

From dino.dinoco.de!teralon.GUN.de!zikzak.in-berlin.de!amk Fri, 15 Apr 94 18:32:09 +0100
Received: by peti.GUN.de ($Id: sendmail.c,v 1.4 1994/02/13 04:50:43 wusel Exp wusel $ (Feb 13 1994, 05:52:58))
	  id <1b0r@peti.GUN.de>; Fri, 15 Apr 94 18:32:09 +0100
Received: by dino.dinoco.de (V1.16/wusel)
	  id <dlop@dino.dinoco.de>; Fri, 15 Apr 94 02:16:24 +0100
Received: by teralon.GUN.de (Smail3.1.28.1)
	  from rs1.rrz.Uni-Koeln.DE with smtp
	  id <m0pra9k-0004S2A>; Thu, 14 Apr 94 22:45 CET
Received: from methan.chemie.fu-berlin.de by rs1.rrz.Uni-Koeln.DE with SMTP id AA64332
  (5.67b/IDA-1.5 for <simons@peti.gun.de>); Thu, 14 Apr 1994 22:42:42 +0200
Received: by methan.chemie.fu-berlin.de (Smail3.1.28.1)
	  from zikzak.in-berlin.de with uucp
	  id <m0prYE9-0000dOC>; Thu, 14 Apr 94 22:41 MES
Received: by zikzak.in-berlin.de
	  (using \/<>\/ SmailAmiga 1.02j20 with rerouting enabled)
	  for peti.gun.de!simons (via fub)
	  id <m0prVDU-000061W>; Thu, 14 Apr 1994 17:28:40 +0200
In-Reply-To: <1e9ecdca.ea603-simons@peti.GUN.de>
      (from simons@peti.gun.de (Peter Simons))
      (at Tue, 12 Apr 94 21:04:18 +0100)
X-Mailer: //\\miga Electronic Mail (AmiElm 3.98)
Organization: 20 minutes into the future.
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Message-Id: <1ea13e3f.2-amk@zikzak.in-berlin.de>
Date: Thu, 14 Apr 1994 17:28:40 +0200
From: amk@zikzak.in-berlin.de (Andreas M. Kirchwitz)
To: simons@peti.gun.de (Peter Simons)
Cc: aussem@mavhh.hanse.de
Subject: PGP und quoted-printable
X-Status: OR

Moin Peter,

> BTW: Bitte schalte nicht quoted-printable ein, wenn die Mail hinterher
> mit PGP kodiert wird, sonst kann Elm das nicht dekodieren, weil er die
> '='-Zeichen im ASCII-Armor als MIME-Steuerzeichen versteht!!
> 
> Andreas, meinst Du man sollte die Funktion des Uebersetzens beim
> dekodieren abschalten?? Oder zumindest einen RAW-Save einbauen? Sonst
> muss man mit dem Texteditor direkt an den Folder gehen. :-(

Das ist der Nachteil, wenn man das Verschluesseln und Entschluesseln
auf verschiedenen Schichten vornimmt.  Natuerlich geht das in die
Hose.

Daher ruft Elm das Verschluesselungs-Programm ja auch auf, BEVOR der
Message-Body MIME-maessig gewandelt wird.  Entsprechend umgekehrt
beim Entschluesseln.

> Naja, auf jeden Fall weiss ich jetzt schon ein neues Feature fuer den
> PGPSendmail 3.0. :-)

Eben ;-)  Der PGP-Sendmail muss entweder den Header entsprechend
aendern oder den Message-Body nach dem Verschluesseln so kodieren,
dass der Header wieder stimmt.  Entsprechend bei eingehender Mail.

Da es jedem weiterleitendem System freisteht, den Modus fuer
Content-Transfer-Encoding zu aendern (und den Body entsprechend
neu zu kodieren), muessen also Header und Body sowieso IMMER
aufeinander abgestimmt sein.  

	Tschuessi,
		Andreas

