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.