[comp.mail.elm] Elm Monthly Posting - Elm 2.2 Released

syd@dsinc.UUCP (Syd Weinstein) (04/11/89)

This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator.  This posting generated:
Tue Apr 11 10:14:12 EDT 1989

Current release version: Elm 2.2 PL0
	This version was released at patch level 0.
	comp.sources.unix Posting-number: Volume 18, Issue 80
	Archive-name: elm2.2/part01
	Patches are available from the archive server at dsinc.UUCP:
	send mail to archive-server@dsinc.UUCP
	send elm index

Known bugs in Elm 2.2 PL0:
	The following are from the Elm 2.2 "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.2 for some, but not necessarly all of these.  Some
of these will only be fixed in 2.3.  (It depends on how extensive the
change is to fix it, and what else it ties into in the 2.3 work).

	When sorting by date sent, timezones need to be taken into
consideration.

	When doing a group reply, the user's address is not removed
from the cc list if present.

	When bouncing a message or forwarding a message without editing,
Elm doesn't know not to encrypt an already encrypted section.

	When printing or piping a message with encryption, decryption
doesn't take place because "readmsg" is used, which doesn't deal with
encryption at all.

	When quoting a message with decryption for replying or
forwarding, Elm doesn't know to decrypt the message prior to quoting.

	We ought to use the RFC822 standard headerline order.  We
therefore need to add a configuration setting to establish the need for
a -s option when fastmail and Elm exec rmail in certain UNIX flavors.

	If you forward a message, and don't elect to edit it at first,
but later do, the message is not quoted.

	Configure should ask which mail transport agent should be
used by filter.  Filter is hardcoded to use sendmail.

	A message with an Expires: header is marked as expired
regardless of the expiration date.

	Expiration dates not calculated properly, perhaps only around
changes of year.  For example, 10 days into the future in December comes
up in the file as 1 month and 10 days into the future.

	Use of termcap "ti" and "te" (I think these may not be the
correct ones) for proper memory locking so that terminals with multipage
memory do not scroll in a bad way.

	On vt100 under ULTRIX, the standout bar has a leading and
trailing "2" because the homebrew curses doesn't deal with termcap delay
numbers.  This may have to wait until the curses rewrite.

	Ordering configure questions more effectively can eliminate
asking questions that were rendered moot by the answers to other
questions.

	There may be places where writes to file (this includes fclose)
fail due to a full filesystem and ELM doesn't check return codes.  If
this happens with the temp mbox for a spool mailfile, one's spool mail
file can loose messages or become corrupted.

	Newmail displays a null from if there is no From: header line.
It needs to be able to parse the From and Received header lines to get a
returnpath type of from.

	Sometimes newmail gets in a state where it simply outputs a
newline when new mail arrives.  This may have to do with it finding mail
deleted and added in at the same check of the mailfile.

	Duplicate addresses need to be removed in outbound messages.
(This can occur when two used aliases have an address in common.)

	Filter locks mail files only via lock files and needs to lock
via flock under the appropriate configurations.

	Newmail doesn't shut down on some systems that screwup use of
SIGHUP.  Perhaps newmail should use getppid() and shutdown when the
parent pid changes.

Current development version: Elm 2.3d
	Freeze for testing:  9/1/89
	Anticipated release: 10/1/89
	both dates subject to change without notice.

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 26 developers and an additional 16 testers, participating
at various levels of activity.

Comments, bug reports, feature requests, etc.  should be sent to
elm@dsinc.UUCP.  I try to ack most reports, but over 60% fail due to
invalid addresses.  Note, I strip your address to name@site before
replying.

New releases will be posted to comp.sources.unix, patches will be posted
to comp.sources.bugs.  Patches are available from the archive server at
dsinc.UUCP.  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.

The following sites have agreed to make Elm available via anonymous ftp.

	Site			Contact
	mthvax.miami.edu	a.e.mossberg, aem@mthvax.miami.edu
	wugate.wustl.edu	David J. Camp, david@wubios.WUstl.EDU
          (128.252.120.1)



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 2.3 release.  Also starting with
release 2.2 a list of known problems will be published in this posting.



                           The Elm(tm) Mail System
  		 

		    (C) Copyright 1986, 1987, by Dave Taylor
                    (C) Copyright 1988, 1989, USENET Community Trust

			An Overview of the Elm Mail System
			----------------------------------

1. What is Elm?

	In the lingo of the mail guru, Elm is a "User Agent" system,  it's
designed to run with "sendmail" or "/bin/rmail" (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.

3. What systems does it work on?

	Elm was originally written on HP-UX, HP's proprietary version
of AT&T System V, with a little BSD thrown in.  Since then, it has been
ported to AT&T, Berkeley, Sun, UTS, Pyramid and Xenix and should run on 
all these systems without any modifications.

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.

-- 
=====================================================================
Sydney S. Weinstein, CDP, CCP                   Elm Coordinator
Datacomp Systems, Inc.				Voice: (215) 947-9900
{allegra,bpa,vu-vlsi}!dsinc!syd	                FAX:   (215) 938-0235

zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (04/12/89)

In article <105@dsinc.UUCP> syd@dsinc.UUCP (Syd Weinstein) writes:

>Known bugs in Elm 2.2 PL0:

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

Actually no.  Elm currently has problems replying to some rfc822 legal
addresses (like the examples in rfc822).  This should have been added to
the bug list.








-- 
  Jon Zeeff			zeeff@b-tech.ann-arbor.mi.us
  Ann Arbor, MI			mailrus!b-tech!zeeff