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....