From: mauritz_c@spcvxb.spc.edu
Newsgroups: comp.os.coherent
Subject: Monthly Elm posting from comp.mail.elm
Date: 12 Nov 92 18:42:44 GMT
Organization: SPC Community Access System

This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator.  Please send all questions and comments about
this posting or Elm itself to elm@dsi.com (dsinc!elm).  See the
README section of this posting for info on some Elm 2.4 FAQ's.
This posting generated:
Tue Nov 10 15:24:15 EST 1992
 
Current release version: Elm 2.4 PL8
        This version was released at patch level 0.
        comp.sources.unix Posting-number: (Not yet posted)
        Archive-name: (Not yet posted)
        Patches are posted to comp.sources.bugs and comp.mail.elm
        After they are stable, patches are sent to comp.sources.unix
                Five patch sets have been posted, 1/2, 3, 4/5, 6, 7/8.
                Archive-name: (No patches yet posted to comp.sources.unix)
        Patches are available from the archive server at DSI.COM:
        send mail to archive-server@DSI.COM
        send elm index
 
Note: the archive server will not respond to users names root, daemon,
postmaster or mailer-daemon.  Please use your own login when requesting
information from the archive server.
 
Planned next version: Elm 3.0
        Current Elm 3.0 status: Development expected to start 1/1/93
        Expected release date: Sometime in 1994.
 
As of release 2.1, Elm is now being developed by a cooperative venture
of volunteers loosely being called the Elm Development Group.  There are
approximately 40 developers and an additional 16 testers, participating
at various levels of activity.
 
Comments, bug reports, feature requests, etc.  should be sent to
elm@DSI.COM.  I try to ack most reports, but over 60% fail due to
invalid addresses.  Note, I strip your address to name@fqdn or name@site
before replying.
 
New releases will be posted to comp.sources.unix, patches will be posted
to comp.sources.bugs.  After patches have been proven and out for a
while, they will be posted to comp.sources.unix.  Patches are available
from the archive server at DSI.COM.  The complete release as of the
current patch level is available via anonymous uucp from dsinc.  Also
available via anonymous uucp are postscript output files of the current
documentation.  This service is provided for those sites that have
postscript but do not have di-troff.  Instructions for obtaining files
via anonymous uucp from dsinc are also available from the archive
server.  Elm is too large to mail, don't bother asking.  Also don't
mail me asking for me to send you patches, I won't.  Use the archive
server.  The archive-server will not respond to users named root,
daemon, or postmaster to prevent loops.  Please do not use those names
for archive requests.  PLEASE do not send archive requests to elm@dsi.com.
 
The following sites have agreed to make Elm available via anonymous ftp.
 
        Site                    Contact
        In the US/Canada:
        wuarchive.wustl.edu     David J. Camp, david@wubios.WUstl.EDU
          (128.252.135.4)
 
        ftp.uu.net
          (137.39.1.9, 192.48.96.9)
 
        In Europe:
        ftp.cs.ruu.nl           Edwin Kremer, edwin@cs.ruu.nl
        (131.211.80.17)
 
        In the UK:
        uk.ac.soton.ecs         T.Chown@ecs.soton.ac.uk (bitnet)
        (152.78.64.201)         T.Chown@uk.ac.soton.ecs (JANET)
 
        In Australia:
        ftp.adelaide.edu.au     Mark Prior, mrp@itd.adelaide.edu.au
          (129.127.40.3)
 
        In Taiwan:
        NCTUCCCA.edu.tw         Huang, Chih-Hsien hch@NCTUCCCA.edu.tw
        (140.111.3.21)
 
 
The following sites have agreed to make Elm available via anonymous
uucp:
        Site                    Contact
        uunet                   Elm is /networking/mail/elm
 
        dsinc                   Syd Weinstein
                                syd@dsi.com, dsinc!syd
                                note: anon uucp info changed 12/16/91
                                For further info, send an e-mail
                                message to archive-server@dsi.com stating:
                                send anon how-to dir
 
 
        stanton                 Steven P. Donegan
                                donegan@stanton.cts.com, stanton!donegan
                                714-894-2246 uucp - nuucp no word
                                Elm is /u/public/elm2.3.tar.Z
 
 
-----------------------------README SECTION-----------------------------
First: See the README file that is part of the Elm Source Distribution.
Many questions might be answered there.
 
Where do I get the "Elm Reference Guide", "Elm Users Guide", ...
        Elm has several documents (over 100 pages worth of doc)
        that were written to help users install, support and use Elm.
        These are in the doc directory of the source distribution.
        Contact your systems administrator for a copy of the documents.
        For those sites that do not have troff (either di-troff or
        o-troff) and do have postscript printers, dsinc (dsinc.dsi.com)
        has a copy of the docs already in postscript format available
        for anonymous uucp or ftp.
 
Why do I get the remote signature on replies to local mail?  Can I
define what addresses are local?
        In Elm 2.4, any address with an ! or @ in it is considered
        remote, without those characters, its local.
        Any reply is qualified to prevent alias expansion.  If you had
        an alias in your private Elm aliases that matched the name of a
        user on your system, but that alias did not point to that user,
        there would be no way to reply to the message.  It would end up
        going to the alias name, not the user that mailed you.  To
        prevent this, Elm fully qualifies (adds the site name) to a
        reply address.  This makes the simplistic signature detector
        think that the message is 'remote'. This is not slated to
        change until 3.0.
 
From comp.mail.elm, dws@ssec.wisc.edu (DaviD W. Sanderson) writes:
>... whoever wrote the default termcap
>and/or terminfo descriptions for xterm included in the ti/te strings
>the special escape sequences to make xterm switch between the normal
>and alternate screen buffers.  These sequences are:
>
>       \E[?47h         - use alternate screen buffer
>       \E[?47l         - use normal screen buffer
>...
>The elm code is just fine as it is.  If you change it so that it
>doesn't ever send ti/te, you'll just break elm for somebody else.  Fix
>your termcap/terminfo definition instead.
 
Why can't I get SGI to work for non ROOT.....
        SGI, at 3.3, doesn't have vfork, but instead a stub that does
        not work.  Make sure vfork is undef in the configuration.
 
How do I link Elm on IBM AIX?
        On IBM RISC 6000 AIX, 3.2 or newer, to compile Elm
during Configure, specify -U__STR__ to the 'Additional CFLAGS'
question.  No other changes are needed.
 
        On IBM RISC 6000 AIX, prior to 3.2, you might get string
funtion errors on the compile.  The solution is to do the following:
        Look at /usr/lpp/bos/bsdsport. It tells you
        to add following lines to /etc/xlc.cfg
 
        * BSD 4.3 c compiler stanza
        bsdcc:  use        = DEFLT
                crt        = /lib/crt0.o
                mcrt       = /lib/mcrt0.o
                gcrt       = /lib/gcrt0.o
                libraries  = -lbsd, -lc
                proflibs   = -L/lib/profiled,-L/usr/lib/profiled
                options    = -H512,-T512, -qlanglvl=extended, -qnoro, -D_BSD, 
-D
_NONSTD_TYPES, -D_NO_PROTO, -D_BSD_INCLUDES, -bnodelcsect, -U__STR__, 
-U__MATH__
 
        And then link bsdcc to xlc and use bsdcc instead of cc.
 
In addition, Elm should be linked with the curses lib and not termcap lib
if /etc/termcap is not there. (You can always copy the termcap database
to etc (or make a symlink)).
 
 
        On 386bsd, the shell that is shipped with the system, ash, does
not work for sending messages within Elm.  Mail messages have headers only
and no body.  Replacing the shell with bash (from GNU) seems to solve the
problem.  The bash shell is in the 'etc' distribution of 386bsd.
 
 
Why does my mail to Dave Taylor bounce?
        His new address is limbo!taylor, or, taylor@intuitive.com
 
--END--END--END--END--END----README SECTION----END--END--END--END--END--
 
Starting with release 2.2, the Elm Development group will attempt to
provide official patches to the release version to fix problems reported
at the same time we are working on the next release.  Also starting with
release 2.2 a list of known problems will be published in this posting.
 
Known bugs in Elm 2.4 PL5:
        The following are from the Elm 2.4 "To.Do" list that are
considered bugs, not enhancements, that have not yet been done.  Items
which are enhancements are not listed here.  It is our intention to
release changes to 2.4 for some, but not necessarly all of these.  Some
of these will only be fixed in 3.0.  (It depends on how extensive the
change is to fix it, and what else it ties into in the 3.0 work).
Items marked fixed will be deleted from the list on the next posting.
 
1.  General bugs and configuration bugs
 
GB01 The ordering of some sets of configuration questions could
     be improved.  In some cases, the answer to a later question
     renders an earlier question moot.  In such cases, the latter
     should proceed the former so that the former would only be
     asked if need be.
 
GB02 All programs need to use the same algorithm elm(1) and
     frm(1) use in establishing the user's id and the user's in-
     coming mailbox.
 
GB10 [next item goes here]
 
2.  Elm(1) bugs
 
EB02 Encryption is not fully implemented in ELM.  In elm(1) we
     have the following problems:
 
     When `b' (bouncing) a message or `f' (forwarding) a message
     without editing, an encrypted section of text in the origi-
     nal message wrongly gets encrypted a second time.  The func-
     tion that looks for encryption delimiters needs to know to
     ignore them in these situations.
 
     When `p' (printing) or `|' (piping) a message, an encrypted
     message does not get decrypted.  This is because elm(1) in-
     vokes readmsg(1) to pull the message out of the folder and
     readmsg(1) does not deal with encryption at all.  Even if we
     gave readmsg(1) the ability to decrypt messages, we'd still
     have problems because readmsg itself would have to prompt
     for the decryption key.  Now if we were printing or piping a
     set of tagged messages, readmsg(1) would have to prompt for
     decryption keys for each message individually.  In doing
     that readmsg(1) would have to indicate which message of the
     set it was working on.  This would be difficult since
     readmsg(1) uses actual ordinal message position in the fold-
     er, and that would be confusing if the user has folders
     sorted in other than mailbox order: the message numbers
     wouldn't match up.  The solution therefore involves replac-
     ing readmsg(1) with a new function in elm(1) to handle the
     `p' or `|' commands, and this function would need to detect
     the encryption delimiters and prompt for the decryption key.
     Furthermore, readmsg(1) should get enhanced to deal with en-
     crypted text, or else carry a disclaimer that it doesn't
     work on encrypted text.
 
     When including the text of an original message for a `r'
     (reply) or `f' (forward), encrypted sections do not get de-
     crypted first, resulting in decrypted text inside the in-
     clude text.  This means that the elm(1) function that in-
     cludes text of an original message must detect encryption
     delimiters and decrypt encrypted text before including it in
     a reply or forwarded message.
 
EB26 When using an address of the form "node!user@domain" and
     having Elm convert it to an all ! address, RFC976 states
     that the proper address should be domain!node!user, but Elm
     translates that to node!domain!user.
 
EB36 When Elm is configured not to look at the password file for
     full name information, it sometimes places the user name in
     ()s as the comment in addition to the full name.
 
EB41 [next item goes here]
 
3.  Utilities bugs
 
UB02 Newmail(1) displays a null "From" when a message does not
     contain a From: header line.  It needs to be able to parse
     the return path and display the "last two words" of it, just
     like elm(1) does  when it encounters a message without a
     From:
 
UB07 Arepdaemon has a bad security hole because it does not check
     to see if the user can read the file used for reply.
 
UB09 Autoreply.c tries to unlink the file "/etc/autoreply.data"
     when there is only one entry in it and does not check the
     return value of unlink.  This can have bad repercussions if
     the unlink fails because the program nevertheless reports
     success.
 
UB13 If filter is run on a system that allows multiple delivery
     agents, that can start up multiple copies of filter,
     delivery of messages can get intermixed.  Filter needs a
     complete interlocking to prevent this.
 
UB14 [next item goes here]
 
 
                           The Elm(tm) Mail System
 
 
            (C) Copyright 1988-1992, USENET Community Trust
            (C) Copyright 1986,1987, by Dave Taylor
 
                        An Overview of the Elm Mail System
                        ----------------------------------
1. What is Elm?
 
        Currently on Unix, there seems to be a preponderence of line-oriented
software.  This is most unfortunate as most of the software on Unix tends to
be pretty darn hard to use!  I believe that there is more than a slight
correlation between the two, and, since I was myself having problems using
"mailx" with high-volume mail, I created a new mail system.
 
        In the lingo of the mail guru, Elm is a "User Agent" system,
        it's designed to run with "sendmail" or "/bin/rmail" or any
other UNIX Mail Transport Agent (according to what's on your system)
and is a full replacement of programs like "/bin/mail" and "mailx".
The system is more than just a single program, however, and includes
programs like "frm" to list a 'table of contents' of your mail,
"printmail" to quickly paginate mail files (to allow 'clean'
printouts), and "autoreply", a systemwide daemon that can autoanswer
mail for people while they're on vacation without having multiple
copies spawned on the system.
 
2. What's New about Elm?
 
        The most significant difference between Elm and earlier mail
systems is that Elm is screen-oriented.  Upon further use, however,
users will find that Elm is also quite a bit easier to use, and quite a
bit more "intelligent" about sending mail and so on.   For example, say
you're on "usenet" and receive a message from someone on the Internet.
The sender also "cc'd" another person on Internet.  With Elm you can
simply G)roup reply and it will build the correct return addresses.
 
        There are lots of subtleties like that in the program, most of
which you'll probably find when you need them.
 
3. What systems does it work on?
 
        The Elm development group uses almost every UNIX system out
there between all of its volunteers.  Elm runs on USL System V, BSD,
SunOS, Apollo, UTS, Pyramid and Xenix and should run on almost any Unix
systems without any modifications (if there turn out to be
modifications, please notify the Elm Development Group as soon as
possible).
 
4. Does it obey existing mail standards?
 
        Yes!  That's another of the basic reasons the program was
originally written!  To ensure that the date field, the "From:" line
and so on were all added in the correct format.  The program is 100%
correct according to the RFC-822 electronic mail header protocol
guide.
 
5. What were the main motivating factors for Dave to write Elm?
 
        The first two I've already mentioned, but here's a (somewhat
partial) list;
 
        -  To have a mail system that exploited the CRT instead of
           assuming I'm on a teletype.
 
        - To have a mailer that was 100% correct when dealing with
          network mail (ie RFC-822).
 
        - To create a system that needed no documentation for the
          casual user, but was still powerful enough and sophisticated
          enough for a mail expert.
 
        - To write a "significant" piece of software as a learning
          experience (I admit it!)
 
        - To find out how reasonable it is to try to modify a program
          to meet the expectations of the users, rather than vice-versa.
 
        - To basically correct some of the dumb things that the current
          mailers do, like letting you send mail to addresses that it
          could trivially figure out are going to result in 'dead.letter'
 
        - To tie in intimately with the pathalias program output, and
          allow users to specify machine!user or user@machine and have
          the COMPUTER do the work of figuring out addresses...
 
6. Is it reliable?
 
        The mailer, in various incarnations, has logged literally
thousands upon thousands of hours without any problems that aren't
now corrected.  As new problems arise they're dealt with in as
rapid a manner as possible...
 
7. Disclaimers
 
        The author of this program will deny all liability for any
damages, either real or imagined, due to the execution of this program
or anything related to either the software or the system.  Furthermore,
the entire system and all source within, including the presentation
screens and commands, are legally copyrighted by the author, and while
they can be used, and abused, for public domain systems, it will be in
violation of the law if used in systems or programs sold for profit.
 
        By installing the mailer or even extracting it from the network,
you are agreeing to the above disclaimer.
 
8. Finally
 
        I think it's a good program, and I can cite at least 75 people
who would (begrudgingly, I'm sure) agree.  You should most certainly
install the program and try it!!
 
 
                                -- Dave Taylor
                                taylor@intuitive.com
                                -- Syd Weinstein, Coordinator
                                Elm Development Group
                                elm@dsi.com
 
--
========================================================================
Sydney S. Weinstein, CDP, CCP          Elm Coordinator - Current 2.4PL08
Datacomp Systems, Inc.                 Projected 3.0 Release: ??? ?,1994
syd@DSI.COM or dsinc!syd      Voice: (215) 947-9900, FAX: (215) 938-0235