Path: utzoo!utgpu!water!watmath!clyde!att!ihlpa!ihnp4!chinet!les
From: les@chinet.UUCP (Leslie Mikesell)
Newsgroups: comp.mail.elm
Subject: Re: Whatever happened to "Elm - the MAILER" ??
Keywords: RFC822 Encryption
Message-ID: <5958@chinet.UUCP>
Date: 7 Jul 88 20:56:21 GMT
References: <470@altnet.ALTOS.COM> <278@clout.Jhereg.MN.ORG> <485@altnet.ALTOS.COM> <10291@ncc.Nexus.CA> <1060@datapg.DataPg.MN.ORG> <520@a <23@n0atp.UUCP> <10305@ncc.Nexus.CA> <560@altnet.ALTOS.COM>
Reply-To: les@chinet.UUCP (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 23

In article <560@altnet.ALTOS.COM> edc@altnet.UUCP (Eric Christensen) writes:
>OK folks, there are some real problems with encrypted mail.
>..
>Now, the question is how do we deal with the optional encryption? I think that
>embedding ANY routine into Elm itself is a mistake. I'm all for using standalone
>programs for these nasty little tasks. 
>..
>LOOK!>>>>>           /  "Encrypted"         ":" 1#2word

Does this have to apply to the entire body of the text or can it be
done for arbitrary portions.  If this method does not allow parts of
the message to be clear text, it loses functionality as compared
to the original ELM method.  

Anyway, I'm more interested in being able to attach/detach multiple
files with optional uuencoding.  Perhaps some more general method
could be used, like [nnn xxx] where nnn is the number of characters
to be passed to command xxx.  For safety, something special should
be found at position nnn+1 to check for damage in transit (or perhaps
a CRC could be used), and command xxx would have to be checked against
a list of legal things at the receiving end.  Elm, being the user-friendly
beast that it is, would show you the command about to be executed and
ask for permission....