Software infrastructure

In thinking more about Eric's proposal for a terminal program, I can
see the value in putting in the hooks for stream encryption even if we
don't implement it right away.  That should be one of the points of
this software, to have it be easily expandable.  So we would want to
make it so that a layer could be inserted just above the serial I/O
layer which would do transparent encryption.  The mechanism for
creating the shared keys could be added later, perhaps.

We are seeing a lot of different suggestions here, which is good at
this point.  Some of the issues:

Overall functionality

To keep our focus: we want something which will help the average
computer user who has a PC or something similar at home be able to use
encryption easily in sending and receiving email.

The problem is that people send and receive mail in very many
different ways.  So we propose to provide a very flexible and
extensible solution that can be adapted to many situations.  This
leads to the idea of a terminal program with built-in encryption,
since most people can use a terminal program to get their mail.

This would not be aimed at people running UUCP or similar fancy
protocols on their home machines.  They must be pretty sophisticated
to get this stuff working.  PGP and RIPEM already come with a bunch of
scripts to let them be used in Unix and similar environments.  (Maybe
I'm mistaken, though, in thinking that good solutions already exist
for these people.  I don't know much about this mode of operation.)

Build or Buy

Do we roll our own or do we try to tap into an existing program?
Among existing terminal programs, do we: try to provide add-ons to
widely used commercial or shareware programs (for which we don't have
source); try to convince the authors of these programs to make the
changes we desire; or find such a program which has source available
(e.g. kermit) and take that as our starting point?

Target OS

We have seen suggestions for DOS, Windows, Unix, and Linux (about
which I know nothing).  DOS and Windows are the biggest target market
and the most likely to be used by the naive users we are trying to
help, IMO.  It would not be too hard to write for DOS but to isolate
the OS dependencies so it could be easily moved to Unix (and perhaps
Linux).

But the DOS vs Windows decision is more fundamental.  More generally,
it is the command-line vs GUI decision.  It's very hard to write code
which is portable across these two approaches.  I would lean towards the
command line approach because it is easier to write portable code, in
my experience (portable between DOS and Unix, say, is easier than
portable between Windows, X, and Mac).  But just fixing on Windows is
another option.

Serial Interface

Focusing on DOS, apparently there are several ways of interfacing to
the serial port.  I know nothing about these.  The main issues would
be portability - does it require the user to have some third-party
software, or to run on only a limited subset of PC clones - and
efficiency - can we run at 9.6 or 14.4 Kbaud?  What solutions
accomplish both of these?

And what if we went with Windows?  Does that narrow our options?

User Interface

I still think this is one of the harder issues.  How exactly can we
make this easy to use?  Can anyone suggest a non-magical (e.g. no
mind-reading) but still ideal interface for encryption?  I kind of
liked Greg's suggestion of using the rollback buffer for decryption -
when it sees an encrypted message go by it automatically decrypts it
and offers it to the user to see.  I'm not exactly sure what you do
with it then, though.



It would be helpful for me to hear more about how people read and send
mail on their home computers, in some detail.  If Mike Diehl got
enough responses to his survey that would be good to hear about, too.

Hal Finney
74076.1041@compuserve.com

According to nobody@shell.portal.com:
> 
> It would be helpful for me to hear more about how people read and send
> mail on their home computers, in some detail.  If Mike Diehl got
> enough responses to his survey that would be good to hear about, too.

I've gotten a bunch!  I'm storing the messages in a file which will later be 
edited.  Then I'll tally everything up.  Expect results on the list monday.  Of
course this means that if you haven't replied to my poll, you need to do so by
saturday night, mountain time.

Well, now I will describe how I send/receive mail on my system, the killer
8086-8 from Hell! ;^)  I've been hyping my setup on this list for about a month.
But since I've partially implimented a system like what we have been discussing,
I'll give more details.

First, my system configuration:
MACHINE: AT&T 6300 PC 
HARDWARE: 640K, CGA, 1-360K fd, 1-20M hd.
OS: PMS-DOS 3.1 and 4DOS 4.02
COMM PROGRAM: Telix 3.15

As you can see, I am developing for the low-end computer......  ;^)

My email system is composed of (basicly) 2 files, a telix script, and a 4dos
batch file.  

The telix script, at the moment, assumes it is already logged into my unix 
account.  Then it does a 'frm' command and finds out how many NEW messages are
in; it would actually be easier to simply dload all of my messages, but this is
a bit more usefull.  Anyway, it dloads them one at a time onto my pc using 
zmodem.  Once on my machine, the script extracts From: and Subject: information
from the message.  Then it finds a unique filename to give the new message.
This information is then stored in a form usable by the batch file, later.  
After it has done all this, it quits elm, and does some housekeeping.  At this
point, the communications program is finished and the mail is on my pc ready to
read.  Under an automatic implimentation (for, say a pay-as-you-go system) this
can be done without any human intervention.

After the messages have been collected, I, of course, want to read them.  To do
this, I run the mail.bat program.  I am then presented with a menu allowing me 
to Create, Encrypt, Send, Read, Delete mail.  Create, Encrypt, and Delete are 
trivial and don't lend much to this discussion. 

Read presents a menu of messages from the data file created by the telix script.
At the moment, when a user selects a message to read, I use pgp to view it even
if it is not encrypted.  That can be fixed later.

To send a message, you first have to have a file containing the message, duh.
The user is asked for the name of this file, the address of the recipient, and
a subject to use.  This is information is then stored in a form usable by a
third telix script.  Ok, I lied, there are 3 files needed by my system. ;^)

The actuall sending process is simple.  The telix script reads the message 
information and starts elm, supplying the address and subject when asked.  Then
when it gets into vi, it ascii uploads the message directly into vi.  This may
seem kludgy, but it is rather portable since almost every online service lets
you enter a message into an editor.  

Overall, the system works pretty well.  I've still got a few bugs, mostly speed-
related.  But there is room for a lot of improvement.  Here is what I would like
to impliment.

I'd like to have "encryption detection" which would allow my system to use the
appropriate decryption software for message reading.  If a message isn't coded,
it should use list.com.

I'd also like to expand "encryption detection" to recognize several types of 
encryption, pgp, pem, ripem, des, my-bitchin-crypto, etc.  The telix script
could tag the message as it s dloaded.

I'd like to be able to use the system on many online services.  The telix script
could check the phone directory to see which system is it on.  Then, when any
system-specific stuff has to be done, such as starting the mail program on the
host, a special function can be called to do that function on that host.  The
ascii up/down loading is fairly constant, and the local file manipulation 
doesn't depend on the host.

At the moment, I am working on a Reply function.  I know how I'm going to do it,
I just haven't done it yet.  More later.

Well, if you have followed my this far, you either crazy or interested. ;^)  It 
puzzles me why we are contemplating writing our own comm package when so many 
good ones are out there that can be made to serve our purposes.  I'm open to
comments.....  Fire away!

+-----------------------+-----------------------------+---------+
| J. Michael Diehl ;-)  | I thought I was wrong once. | PGP KEY |
| mdiehl@triton.unm.edu |   But, I was mistaken.      |available|
| mike.diehl@fido.org   |                             | Ask Me! |
| (505) 299-2282        +-----------------------------+---------+
|                                                               |
+------"I'm just looking for the opportunity to be -------------+
|            Politically Incorrect!"   <Me>                     |
+-----If codes are outlawed, only criminals wil have codes.-----+
+----Is Big Brother in your phone?  If you don't know, ask me---+

> Well, now I will describe how I send/receive mail on my system, the killer
> 8086-8 from Hell! ;^)  I've been hyping my setup on this list for about a
> month.
> But since I've partially implimented a system like what we have been
> discussing, I'll give more details.


I'm rather surprised that nobody has mentioned UUPC. It's PD, runs on
plain-vanilla DOS, and allows automatic, batched mail traffic (and even
netnews) to/from your local PC.

On your host (typically an UNIX box) you configure
sendmail/smail/binmail/whatever to forward your mail over uucp to your
home machine. On the home machine, you simply configure UUCP to poll
when needed, and transfer the stuff down onto your local disk. From
there you can use UUPC's local mail reader (or any mail package you
want), and the replies get spooled to a spool directory, and uploaded
automatically the next time you (or the software) opens the connection.

Automatic polling, automatic bi-directional batch file transfer,
insertion of encryption trivial....

I use it to read and reply to my mail while on the beach, using a
notebook computer and a cellular phone... The ability to efficiently
batch transfer the stuff makes a *big* difference if you are paying
cellular rates...

	Julf

>On your host (typically an UNIX box) you configure
>sendmail/smail/binmail/whatever to forward your mail over uucp to your
>home machine. 

This is a huge hurdle for people who don't own their own machines and
haven't convinced a sympathetic sysadmin to do the configuration.
A solution that works from a dialup login account can still be a batch
solution and should require no extra involvement from the sysadmins.

Eric

> >On your host (typically an UNIX box) you configure
> >sendmail/smail/binmail/whatever to forward your mail over uucp to your
> >home machine. 
> 
> This is a huge hurdle for people who don't own their own machines and
> haven't convinced a sympathetic sysadmin to do the configuration.

Yes. Sorry. Brain disengaged. Been my own sysadmin for 10 years now, so
it just didn't occur to me... :-(

	Julf

>It 
>puzzles me why we are contemplating writing our own comm package when so many 
>good ones are out there that can be made to serve our purposes.  

Reliability.  Scripts do not easily handle error conditions that might
result in lost mail.  They're fine for a few, but they aren't for all.

Integration.  Remembering what to do next is a large hurdle.

Eric

According to Eric Hughes:
>>Itpuzzles mewhy weare contemplating writing our own comm package when so many 
>>good ones are out there that can be made to serve our purposes.  
> 
> Reliability.  Scripts do not easily handle error conditions that might
> result in lost mail.  They're fine for a few, but they aren't for all.

Well, this is a problem with any nontrivial program.  But a script has going 
for it several very high-level constructs.  As people use any software, the
author will undoubtably have to improve it.  So, what is the difference if
he has to improve a script or a comm program?

> 
> Integration.  Remembering what to do next is a large hurdle.

That's why we have scripts in the first place!  Scripts' main purpose is to 
automate things.  How is this different with a comm program?  You still have to
remember how to use it....


+-----------------------+-----------------------------+---------+
| J. Michael Diehl ;-)  | I thought I was wrong once. | PGP KEY |
| mdiehl@triton.unm.edu |   But, I was mistaken.      |available|
| mike.diehl@fido.org   |                             | Ask Me! |
| (505) 299-2282        +-----------------------------+---------+
|                                                               |
+------"I'm just looking for the opportunity to be -------------+
|            Politically Incorrect!"   <Me>                     |
+-----If codes are outlawed, only criminals wil have codes.-----+
+----Is Big Brother in your phone?  If you don't know, ask me---+