Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!ukma!rutgers!bellcore!tness7!petro!swrinde!dpmizar!com50!n0atp!barry From: barry@n0atp.UUCP (Barry S. Berg) Newsgroups: comp.mail.elm Subject: Re: Whatever happened to "Elm - the MAILER" ?? Message-ID: <26@n0atp.UUCP> Date: 5 Jul 88 05:12:38 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 Reply-To: barry@n0atp.UUCP (Barry S. Berg) Organization: N0ATP, Amateur Radio Packet Gateway, St. Paul, MN Lines: 60 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.