lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (07/03/88)
In article <23@n0atp.UUCP> barry@n0atp.UUCP (Barry S. Berg) writes: > What I propose is to put a dummy local routine in. IBM calls this a > user exit on their mainframe software. The local definiation would > overide the external definition, not a lot of code would be generated, > and the system would allow the use of crypt(1) or a PD crypt if desired. > The following would be a code sample. I don't usually get upset about things like this (ask Phil :-), but NO DAMNIT!!!! Doing this just brings us back to the situation where site admin A uses crypt version X, and site admin B uses crypt version Z. User@A is still bitching because his encrypted mail worked *too* *good* when it got to Recipient@B because noone at B can decipher the damn thing! [ You could argue that each user could compile their own copy of elm with their own version of crypt. I would reply that this would just make the problem n factorial rather than n squared... ] Elm is a tool that helps the user interface with the mail transport system. It is *not* a replacement for crypt, banner, nroff, compress, uuencode, awk, or any of the other standalone commands for manipulating text or data. If you want to do things with your data prior to sending it, fine. Other people have already addressed developing those tools. Elm's sole purpose is to allow the user to send that data to someone else quickly and easily, and let them receive and manage incoming information in a similar manner. Any enhancements made should promote those goals. I think everyone could take a lesson in what a mailer should strive to be by examining MH. -- {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
barry@n0atp.UUCP (Barry S. Berg) (07/05/88)
In article <10305@ncc.Nexus.CA> lyndon@Nexus.CA writes: >In article <23@n0atp.UUCP> barry@n0atp.UUCP (Barry S. Berg) writes: >> What I propose is to put a dummy local routine in. [etc., etc., etc.] > >I don't usually get upset about things like this (ask Phil :-), but > >NO DAMNIT!!!! Why get upset, all that was offered was a compromise that might accommodate all parties needs? Your problem with encryption is another matter. If two sites agree on an encryption method, and then put it in, what can you say or do to prevent it. All that was offered, was a convienient means to package the "released" version to meet the needs expressed. > >Doing this just brings us back to the situation where site admin A >uses crypt version X, and site admin B uses crypt version Z. User@A >is still bitching because his encrypted mail worked *too* *good* >when it got to Recipient@B because noone at B can decipher the damn >thing! That is a problem between users. I am not sure why there is a need to encrypt, I personally have no reason to encrypt my mail, and so would probably never remove the dummy calls thereby saving me memory during execution. However, if I was mailing company confidential stuff from one location to another via the net (is that ethical by net standrds?) and may transit through a competitor's site maybe I would like to use the my mainframe encryption method. The point was a suggestion to simplify life for those out there that may need or want it. Lyndon, if you or I do not chose to use it I can afford a couple of null function calls. If I send you something you can't read, you are going to let me know, correct? I see no reason in forcing those sites that wish to encrypt, because you choose not to. > >Elm is a tool that helps the user interface with the mail >transport system. It is *not* a replacement for crypt, banner, >nroff, compress, uuencode, awk, or any of the other standalone >commands for manipulating text or data. If you want to do >things with your data prior to sending it, fine. Other people >have already addressed developing those tools. Elm's sole purpose >is to allow the user to send that data to someone else quickly >and easily, and let them receive and manage incoming information >in a similar manner. Any enhancements made should promote those >goals. I think everyone could take a lesson in what a mailer >should strive to be by examining MH. > It is obvious that other posters feel that Elm should be more. I really don't care whether encryption is provided or not as long as it does not take up too much room. I have enough problems with the 286 as is. However, some people want encryption, my point was we can make it flexible, and more important site dependent, and configurable. -- Barry S. Berg DOMAIN: barry@n0atp.N0ATP.MN.ORG N0ATP Packet Radio Gateway UUCP: {...}amdahl!bungia!n0atp!barry "Speech is civilization itself--it is silence which isolates." --Thomas Mann "Moderation in all things, most especially moderation." --Author as yet unknown.
edc@ALTOS.COM (Eric Christensen) (07/06/88)
In article <10305@ncc.Nexus.CA> libPW.a[crypt.o] writes: >In article <23@n0atp.UUCP> barry@n0atp.UUCP (Barry S. Berg) writes: >> What I propose is to put a dummy local routine in. IBM calls this a >> user exit on their mainframe software. The local definiation would >> overide the external definition, not a lot of code would be generated, >> and the system would allow the use of crypt(1) or a PD crypt if desired. >> The following would be a code sample. > >Doing this just brings us back to the situation where site admin A >uses crypt version X, and site admin B uses crypt version Z. User@A >is still bitching because his encrypted mail worked *too* *good* >when it got to Recipient@B because noone at B can decipher the damn >thing! OK folks, there are some real problems with encrypted mail. I'm the first to admit that. But there are some benefits too. As I stated earlier, I'm for providing encryption hooks on a optional basis (actually, Dave told me this afternoon that the crypt stuff is all ifdefed in his 2.01 version). Go ahead and flame me, but finish reading the rest of this first! :-) 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. I think we should provide one PD crypt with the Elm sources, so everyone who uses Elm will have access to the same routine, but they have the option of using their own if so desired. RFC 822 deals with this issue, and as such I believe that we should do it in the same way. (We ARE trying to be fully RFC 822 compliant, are we not?) The option field specification from RFC 822 looks like this: optional-field = / "Message-ID" ":" msg-id / "Resent-Message-ID" ":" msg-id / "In-Reply-To" ":" *(phrase / msg-id) / "References" ":" *(phrase / msg-id) / "Keywords" ":" #phrase / "Subject" ":" *text / "Comments" ":" *text LOOK!>>>>> / "Encrypted" ":" 1#2word / extension-field ; To be defined / user-defined-field ; May be pre-empted Ok? Now here's the explination of the Encrypted field: 4.7.3. ENCRYPTED Sometimes, data encryption is used to increase the privacy of message contents. If the body of a message has been encrypted, to keep its contents private, the "Encrypted" field can be used to note the fact and to indicate the nature of the encryption. The first <word> parameter indicates the software used to encrypt the body, and the second, optional <word> is intended to aid the recipient in selecting the proper decryption key. This code word may be viewed as an index to a table of keys held by the recipient. Note: Unfortunately, headers must contain envelope, as well as contents, information. Consequently, it is neces- sary that they remain unencrypted, so that mail tran- sport services may access them. Since names, addresses, and "Subject" field contents may contain sensitive information, this requirement limits total message privacy. Names of encryption software are registered with the Net- work Information Center, SRI International, Menlo Park, Cali- fornia. So we have a specification, as well as a registry for the encryption software. Is this so bad? Agreed, we're taking a little artistic licence with the 'encryption on, encyption off' feature, but I agree with Dave. That should probably stay. Now you can flame me! I would like to reach some agreement on this issue fairly soon. As it is, the 2.0 release will just have the crypt stuff ifdefed out. But I would really like to agree on what to do with future releases. If we've got to do it by vote, I'll accept that, but I hope that we don't have to resort to voting on every design issue, enhancement, or modification that someone comes up with. -- +-------------------------+--------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +--------------------------------------------------+ | 399 West Trimble Road | Note: There are no spelling errors in this | | San Jose, Ca. 95131 | message.... I just can't type! | +-------------------------+--------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them| +----------------------------------------------------------------------------+
zeeff@b-tech.UUCP (Jon Zeeff) (07/07/88)
In article <560@altnet.ALTOS.COM> edc@altnet.UUCP (Eric Christensen) writes: >programs for these nasty little tasks. I think we should provide one PD crypt >with the Elm sources, so everyone who uses Elm will have access to the same >routine, but they have the option of using their own if so desired. > >RFC 822 deals with this issue, and as such I believe that we should do it in >the same way. (We ARE trying to be fully RFC 822 compliant, are we not?) > >soon. As it is, the 2.0 release will just have the crypt stuff ifdefed out. But >I would really like to agree on what to do with future releases. If we've got > I propose that the current encryption code in elm be pulled out and put into a separate program (mailcrypt?) that elm will invoke. Do use the RFC 822 method of indicating encryption in the header. This is backward compatible, doesn't need any ifdefs (elm could invoke mailcrypt automatically or you can use | mailcrypt) and is flexible (in case someone wants to use something like crypt and uuencode/uudecode). Perhaps mailcrypt and crypt/uuencode should be registered rfc 822 encryption program names. I'd be really disappointed if I sent mail to someone who I knew used any version of elm and they replied that they couldn't decrypt my mail. The mailcrypt program could be distributed separately from elm and might become a standard. Make it smart enough to encrypt/decrypt the whole message body if there are no [encode] statements; possibly make it smart enough to recognize lines that are/are not encoded. Just do a good enough job that MH, mailx, and MUSH users can use it. I assume that elm is using crypt(3c). As far as everyone seems to know, this is not easily breakable as crypt(1) is. If someone does find a way to break it, then all the unix passwords are in trouble. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu
les@chinet.UUCP (Leslie Mikesell) (07/08/88)
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....
sewilco@datapg.MN.ORG (Scot E. Wilcoxon) (07/10/88)
In article <5958@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes: <In article <560@altnet.ALTOS.COM> edc@altnet.UUCP (Eric Christensen) writes: <>.. <>Now, the question is how do we deal with the optional encryption? I think that <>.. .. <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 .. Are we getting abstract enough for hyperdocuments? [plot 14342] to send an illustration? -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco July 5: 'The 700 Club' "news" program prays for rain, hours after the National Weather Service forecasts rain.
steve@jack.UUCP (Steven Harrison) (07/11/88)
> >OK folks, there are some real problems with encrypted mail. I'm the first to >admit that. But there are some benefits too. As I stated earlier, I'm for >providing encryption hooks on a optional basis (actually, Dave told me this >afternoon that the crypt stuff is all ifdefed in his 2.01 version). Go ahead >and flame me, but finish reading the rest of this first! :-) > When and where can I go about getting Version 2.01. We love it someone please help!! -- J. Steven Harrison VP Technical Services Informations Systems Group Inc San Diego CA {ucsdhub,nitro}!jack!steve
peter@ficc.UUCP (Peter da Silva) (07/12/88)
In article <4599@b-tech.UUCP>, zeeff@b-tech.UUCP (Jon Zeeff) writes: > I propose that the current encryption code in elm be pulled out and > put into a separate program (mailcrypt?) that elm will invoke. Do use > the RFC 822 method of indicating encryption in the header. This is ...the only logical thing to do, Captain. I think it's pretty surprising that, given the RFC822 encryption standard, anything else was even considered. -- -- `-_-' Peter (have you hugged your wolf today) da Silva. -- U Ferranti International Controls Corporation. -- Phone: 713-274-5180. CI$: 70216,1076. ICBM: 29 37 N / 95 36 W. -- UUCP: {uunet,academ!uhnix1,bellcore!tness1}!sugar!ficc!peter.