Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!cbmvax!vu-vlsi!dsinc!syd
From: syd@DSI.COM (Syd Weinstein)
Newsgroups: comp.mail.elm
Subject: Elm Group monthly posting - October 1989
Keywords: elm monthly
Message-ID: <1989Oct9.181919.15598@DSI.COM>
Date: 9 Oct 89 18:19:19 GMT
Expires: 31 Oct 89 00:00:00 GMT
Reply-To: syd@dsinc.DSI.COM (Syd Weinstein)
Followup-To: comp.mail.elm
Organization: Datacomp Systems, Inc., Huntingdon Valley, PA 19006
Lines: 398


This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator.  This posting generated:
Mon Oct  9 14:09:05 EDT 1989

Current release version: Elm 2.2 PL11
	This version was released at patch level 0.
	comp.sources.unix Posting-number: Volume 18, Issue 80
	Archive-name: elm2.2/part01
	Patches are posted to comp.sources.bugs and comp.mail.elm
	After they are stable, patches are sent to comp.sources.unix
	Patches are available from the archive server at DSI.COM:
	send mail to archive-server@DSI.COM
	send elm index

Known bugs in Elm 2.2 PL11:
	The following are from the Elm 2.3 "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).
Items marked fixed will be deleted from the list on the next posting.

Known bugs in ELM 2.2

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.	This occurs with many of the configura-
     tion questions that deal with the domain routing and
     pathalias databases, appending the	hostname and internet ad-
     dress style, etc.

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.

GB03 RFC822 should be obeyed with regards to the recommended (but
     not obligatory) order of message header lines.  Currently
     filter(1) and elm(1) put Subject: first because of	a problem
     with some USG versions of rmail(1).  Some USG versions of
     rmail(1) will put a null line before the header lines,
     thereby making them text body instead of header, if either
     the Subject:  header line is not first or rmail(1)	isn't
     called with a -s flag.  The set of	rmail(1)'s that	tolerate
     the -s flag is a superset of the rmail(1)'s with this ``Sub-
     ject: first'' requirement,	but not	all rmail(1)'s tolerate
     -s.  Therefore we need to find a way that Configure can
     determine if the rmail(1) on the system will tolerate the -s
     flag.

GB04 The preprocessor testing in Configure does	not work with gcc
     as	the compiler.

GB05 Configure makes some wrong	assumptions for	ULTRIX 2.?, name-
     ly	that termio is "#define"'d and it uses termlib instead of
     termcap.

GB06 Configure misassumes that timezone	vs tzname is dependent on
     BSD as some BSD systems might have	acquired the public
     domain zoneinfo stuff including tzname and	no longer have
     timezone.	It needs it's own test in Configure.

GB07 Configure wrongly thinks utimbuf exists on	3B1's (running
     3.51a), causing a failure to compile src/leavembox.c.

GB09 [next item	goes here]

2.  Elm(1) bugs

EB01 When elm(1) sorts messages	by date	sent, timezones	are not
     taken into	account, only date and time, leading to	inaccu-
     rate sorting.  [Fixed in 2.3]

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.

EB03 When `f' (forwarding) a message, if the user doesn't elect
     to	edit the forwarded message at first but	later does so on
     the ``send	menu'',	the text of the	message	is not quoted
     with the prefix string.  [needs to	be documented as a
     feature, not a bug, due to	user community demand]

EB06 RFC822 standard format for	expiration dates is not	honored
     by	elm(1) when parsing Expires: headers.

EB07 Elm(1) does not correctly reply to	some legal RFC822 ad-
     dresses, such as "@gozzy.com:zeef@b-tech.ann-arbor.mi.us" or
     "Jon Zeeff	<jon @ b-tech.ann-arbor.mi.us".

EB08 Long address lists	wrap in	ugly fashion on	the headers edit-
     ing screen.

EB09 Elm(1) does not check for failed writes and closes	of files.
     This can have a disastrous	affect if /tmp runs out	of space.
     In	this case, elm(1) might	copy a mailbox to a /tmp file and
     then back.	 Since elm(1) wouldn't detect that the copy to
     the temp file failed, the temp file would wind up empty,
     thereby causing the copy back to the mailbox to lose all
     messages.

EB10 There is an inconsistency in the format of	the domain rout-
     ing database as presented by the documentation and	the
     elm(1) code.  Whichever is	wrong needs to be corrected.

EB11 Some terminals with multipage memory do not scroll	correct-
     ly.  It was recommended that elm(1) use termcap ti	and te
     values, but this bug may need to wait until we convert
     elm(1) to use standard curses.

EB12 On	vt100 terminals	on ULTRIX, the reverse video bar has a
     leading and trailing ``2''.  It was recommended that elm(1)
     pay attend	to delay numbers in termcap values, but	this bug
     may need to wait until we convert elm(1) to use standard
     curses.

EB14 On	the header editing screen, error messages that appear as
     a result of user input should linger on the screen	until the
     user enters the next command, as happens on the index
     screen.  Currently	they disappear too quickly to be read.

EB15 On	the mini menu, ``q)uit'' is out	of alphabetical	order.
     [fixed in 2.3]

EB16 Elm(1) uses sendmail(1) as	the MTA	just because Configure
     found it, even if another MTA was specified during	confi-
     guration.

EB17 A comma in	the username/groupname field of	an alias causes
     elm(1) to only take the username/groupname	up to the comma
     and the rest of the field is ignored.

EB20 Apollo SR9.7 nodes	get _IOEOF and _IOERR undefined	when com-
     piled hdrconfig.c.	 This is an  Apollo porting bug, and so
     should be documented in the installation instructions.

EB21 System_call() in src/syscall.c presumes that a system has
     SIG_CONT because SIGTSTP is defined.  On CCI systems this
     may be wrong and a	better check is	the existence of the file
     /usr/lib/libjobs.a.

EB23 Complaint (probably occurs	under certain configurations
     only) that	address	optimization occurs regardless of whether
     its configured.

EB24 Complaint (probably occurs	under certain configurations
     only) that	address	optimization "over optimizes" -	the last
     node in the address is claimed to be known	when it	isn't.

EB25 If	elm is replying	to a message and considers From: lines
     valid and resolves	pathaliases, if	the reply path from the
     From: line	could not be resolved, elm should report the er-
     ror and ask the user if the "From " lines should be used in-
     stead.

EB26 When using	an address of the form "node!user@domain", the !
     has higher	precedence than	the @ when elm resolves	the ad-
     dress.  The @ should have higher precedence.

EB28 Shell-special characters in addresses (e.g. '&') can foul up
     the shell command by which	elm(1) executes	the MTA.  A solu-
     tion may be to single quote each address in the command.

EB29 Mailbox editing always uses the alternative_editor.  It
     should use	the regular editor and only the
     alternative_editor	if the regular editor is "none"	or "buil-
     tin".

EB30 Deletion of an alias with multiple	alias names does not
     work.  The	alias is not deleted.

EB31 Return addresses are not checked in the same way that manu-
     ally entered addresses are	checked	against	the pathalias da-
     tabase, and this sometimes	allows a bad address to	be used.

EB32 Printing or piping	with too many messages tagged causes a
     segmentation violation.  [fixed in	2.3]

EB33 Elm in saving a mail folder after it being	the current mail
     folder uses a copy	to temp	and then remove	and recreate the
     folder method.  This breaks any links the old folder had.
     Instead it	should use copy	to temp, truncate and then copy
     back keeping the links intact.

EB34 When expanding an Elm system alias, Elm will use a	user
     alias within that expansion.  When	expanding system aliases,
     only other	system aliases should be used.	[fixed in 2.3]

EB35 Configure does not	recognize the mail group if the	mail
     spool directory is	a symbolic link.  [fixed in 2.3]

EB36 [next item	goes here]

3.  Utilities bugs

UB01 Arepdaem.c	repeatedly opens the autoreply file but	doesn't
     close it after each open.	This could result in failure once
     it	has exceeded the maximum allowed number	of open	files.
     [fixed in patch 11]

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:

UB03 Sometimes newmail(1) gets in a state when it outputs a blank
     line instead of the From and Subject whenever new messages
     are received.  This appears to happen after the user removes
     messages from the mailbox.	 This may not be fixable since it
     may be due	to newmail(1)'s	simple-minded way of deciding
     when a message has	been added to the mailbox.  I.e. this may
     require newmail(1)	having a more sophisticated way	of iden-
     tifying each message in a mailbox.	 [partial fix in 2.3]

UB04 Filter(1) locks incoming mailboxes	only with lock files.
     Filter(1) needs to	use flock(2) on	mailboxes on the ap-
     propriate systems,	just like elm(1) does.

UB05 Newmail(1)	does not shut down on certain systems that do not
     send SIGHUP to background processes when the user logs off.
     One solution is for newmail(1) to do a getppid(2) before it
     forks the background process and to terminate when	the pro-
     cess id returned by that getppid(2) (the user's login shell)
     no	longer exists.

UB06 Filter(1) always uses sendmail(1) as the mail transport
     agent.  The MTA should be configurable.

UB07 Arepdaemon	has a bad security hole	because	it does	not check
     to	see if the user	can read the file used for reply.

UB08 The move_left function in arepdaemon.c does not work for a
     move of 1 byte.

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.

UB10 Readmsg doesn't understand	continued header lines and there-
     fore doesn't list all the "To" header, for	example, if
     presented on more than one	line.

UB11 Newalias wrongly treats a comma in	the comment field as the
     end of the	field.

UB12 [next item	goes here]



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

New Features/Changes in 2.3:

This section will list some of the new features, or changes to the
appearence or functioning of Elm in the next version to reduce the
surprise element.  This list is not designed to be a complete list
of the changes in the next version.

1.  Aliases will now be case insensitive.  This as per the survey
results of Elm users.

2.  Elm will no longer be able to access the L.sys/Systems file
itself.  It will only use the output of uuname for security reasons.


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@DSI.COM.  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.  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 following sites have agreed to make Elm available via anonymous ftp.

	Site			Contact
	mthvax.cs.miami.edu	a.e.mossberg, aem@mthvax.cs.miami.edu
	  (129.171.32.5)
	wuarchive.wustl.edu	David J. Camp, david@wubios.WUstl.EDU
          (128.252.135.4)


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
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd	        FAX:   (215) 938-0235