Archive-name: elm/monthly/part1 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. In addition, Piero Serini , posts a FAQ for Elm in comp.mail.elm, news.answers and comp.answers with the Subject: Elm Mail User Agent FAQ - monthly posting. Its archive-name on pit-manager.mit.edu is elm/FAQ. This posting generated: Sun Jun 6 14:37:31 EDT 1993 Current release version: Elm 2.4 PL22 This version was released at patch level 22. 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 The following patch sets have been posted: NONE 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 Patch 23 is in the works and is a bug fix patch only. It will be a patch and not a re-release again. I expect it to be relatively small, and hopefully the last patch for 2.4 (or is that the last patch before 24 :-) ) 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 4/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 chris@wugate.wustl.edu (Chris Myers) (128.252.135.4) /mirrors/elm ftp.uu.net (137.39.1.9, 192.48.96.9) /networking/mail/elm In Europe: ftp.cs.ruu.nl Edwin Kremer, edwin@cs.ruu.nl (131.211.80.17) /pub/ELM-2.4 ftp.th-darmstadt.de ftpadmin@ftp.th-darmstadt.de (130.83.55.75) /pub/networking/mail/elm 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) ftp.demon.co.uk Cliff Stanford, cliff@demon.co.uk (158.152.1.65) /pub/unix/mail/elm In Australia: ftp.adelaide.edu.au Mark Prior, mrp@itd.adelaide.edu.au (129.127.40.3) /pub/mailers In Taiwan: NCTUCCCA.edu.tw Huang, Chih-Hsien hch@NCTUCCCA.edu.tw (140.111.3.21) /packages/mail/elm 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. Why Elm adds your local hosts qualification to reply addresses: (Or why the DANGER WILL ROBINSON KLUDGE is in the code) Elm passes any address off to the alias mapper to see if it needs expansion. If you are replying to a bare user name of abc, Elm converts it to abc@localhost.domain (assuming internet addressing, myhost!abc for the rest). This is to prevent the alias expansion. If you were to have, in you private Elm alias table an alias of abc that pointer to J.Q.Public@somewhere.domain, if the address wasn't qualified, Elm would convert the reply to abc to go to J.Q.Public@somewhere.domain. This is generally not what you want :-) If you can guarantee that no private alias will ever match a local user name on your system, then you can disable the kludge code. The kludge will have to remain until 3.0 when Elm will track whether an address has been/should be expanded, and its prior to and after expansion values. In 2.x it doesn't do that. How can I get elm to NOT expand the alias list on outgoing msgs? Problem is if a list has, say, 100 names in it then sending to the list expands every single one of the 100 names. I would like the message to have the "To" line = the name of the list itself and have the actual recipients' names not appear. You can't and don't want to. (and yet you can also) An alias is a mechanism of making Elm address a message to multiple people. However, when the message gets to its destination, Elm also has to allow that person do a group reply. If the message only has your local private elm alias in it, the group reply will try and go to that alias name. Unfortunately, that name is meaningless to that other person (its private to both Elm and you). There are two solutions: The preferred if replies are desired: Have your mail administrator create a file include alias for you in your MTA (sendmail, et al).. This is usually of the type alias :include:/some/path/to/a/file where the file would be in a place you control and you have write access to the file. Then you can add/drop members of the list, and the mail just goes to the alias, and, someone sending to alias@your.system will be able to send to all members. (group reply works correctly) The less preferred method: (no group reply is possible) Send the message to yourself, with a bcc to the Elm alias. Of course, the Bcc: won't be expanded by the MTA internal to the message, so it won't appear in the message. 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? This version of Elm 2.4 should not require any changes to the configure run to link under AIX 3.2 or newer. 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 PL22: 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. Database last updated on Friday 12-February-93 9:45:34 +0000 (GMT) General bugs and configuration bugs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GB01 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Configuration questions need rearranging Description: 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 configuration questions that deal with the domain routing and pathalias databases, appending the hostname and internet address style, etc. GB02 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: User id & mailbox algorithm should be consistant. Description: All programs need to use the same algorithm elm(1) and frm(1) use in establishing the user's id and the user's incoming mailbox. Elm(1) bugs ~~~~~~~~~~~ EB02 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Encryption is not fully implemented in ELM. Description: 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 original message wrongly gets encrypted a second time. The function 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) invokes 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 folder, 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 replacing 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 encrypted 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 decrypted first, resulting in decrypted text inside the include text. This means that the elm(1) function that includes text of an original message must detect encryption delimiters and decrypt encrypted text before including it in a reply or forwarded message. EB26 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Addresses "node!user@domain" not handled as RFC976 Description: 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 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Sometimes user name is added into full name field Description: 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 Version: 2.3PL11 Status: Open Open Date: 2-Dec-92 Close Date: Reported by: rp@mis29.cypress.com (Rob Price) Summary: Incoming mail incorrectly handled in subset mode. Description: If a subset of mail is displayed using the "l" command, new incoming mail is displayed with the subset mail. However the mail count at the top of the screen is not updated, and the final few items (ie those numerically after the number of messages shown) cannot be selected by the cursor keys. EB42 Version: 2.4PL3 Status: Closed Open Date: 2-Dec-92 Close Date: 12-Feb-93 Reported by: moore@email.ncsc.navy.mil (Jim Moore) Summary: Builtin editor unable to delete back over line boundary. Description: The builtin editor is unable to delete back over a line boundary. Attempts to delete back over a line boundary can cause the whole message to be lost, and unpredictable effects to be seen on screen and possibly garbage characters in the file. [Fixed in 2.4PL21] EB43 Version: 2.4PL3 Status: Open Open Date: 2-Dec-92 Close Date: Reported by: cytron@jimmy.harvard.edu (Andrew Cytron) Summary: Elm does not enforce newline at end of message. Description: Some MTAs (notably Sun sendmail) require that the message end in a newline character. Elm does not enforce this, which can result in the MTA failing or hanging. EB44 Version: 2.4PL6 Status: Closed Open Date: 2-Dec-92 Close Date: 12-Feb-93 Reported by: marc@ibmpa.awdpa.ibm.com (Marc Pawliger) Summary: Builtin editor treats "/" as white space char. Description: The builtin editor treats "/" as a whitespace character and performs wordwrap (including deleting the "/") on things such as file names. [Fixed in 2.4PL21] EB45 Version: 2.4devPL65 Status: Open Open Date: 2-Dec-92 Close Date: Reported by: jgreco@solaria.mil.wi.us (Joe Greco) Summary: Incoming messages can confuse the index screen display. Description: Elm can lose track of incoming (new) messages so that although the number of messages at the top of the screen is correct, the new messages are not displayed on the index page. However these messages can be accessed in the normal way, they just aren't listed in the index. Redrawing the screen restores things to normal. EB46 Version: 2.4PL13 Status: Open Open Date: 2-Dec-92 Close Date: Reported by: phil@wubios.wustl.edu (J. Philip Miller) Summary: To: addresses split over lines can confuse group reply. Description: If an address in the To: part of a message is split over more than one line, a group reply to that message will incorectly parse the addresses and build an incorrect Cc: header. The example given had the fullname part of an address in () split onto a continuation line. In this case elm added 2 additional addresses into the Cc: line - made up of the 2 parts of the full name each with the original senders domain name suffixed on. EB47 Version: 2.4PL13 Status: Open Open Date: 3-Dec-92 Close Date: Reported by: morwyn!forrie@unhtel.unh.edu (Forrest Aldrich) Summary: Only last line of each header can be edited Description: The header editor only allows the editing of the last screen line of a header. Backing up to previous lines is not possible. EB48 Version: 2.4PL20 Status: Open Open Date: 4-Jan-93 Close Date: Reported by: jason@Germany.Sun.COM Summary: Empty Reply-To: header prevents reply including original text Description: When the received Mail has an empty "Reply-To: " entry in the header, it is not possible to reply to the mail including the text, Elm simply doesn't ask to include the text (or if autocopy is set then no text is included). EB49 Version: 2.4PL13 Status: Closed Open Date: 4-Jan-93 Close Date: 4-Jan-93 Reported by: sl@wimsey.com (Stuart Lynne) Summary: Aborting reply causes next reply to insist on using aborted message Description: I had R(eplied to a message then used abort. Then tried to R(eply to a different message. At that point it asked if I wanted to use the old message and would not accept anything but yes. [Fixed in 2.4PL20] EB50 Version: 2.4PL17 Status: Open Open Date: 30-Dec-1992 Close Date: Reported by: weisen@alw.nih.gov (Neil Weisenfeld) Summary: Elm incorrectly displays folder name on index page Description: My main mail directory is "~/Mail", but I also keep some stuff in another directory "~/MailDelivery". The bug that I came across is when I change to the folder "~/MailDelivery/xxx", it prints the current folder name as "=Delivery/xxx" EB51 Version: 2.4PL17 Status: Open Open Date: 25-Dec-92 Close Date: Reported by: Larry Rosenman Summary: Forms is set off whenever options are saved Description: Whenever the options are saved from within elm, the forms option is forced to OFF no matter what it used to be. EB52 Version: 2.4PL20 Status: Open Open Date: 7-Jan-93 Close Date: Reported by: steve@avalon.dartmouth.edu (Steve Campbell) Summary: Suspend/resume does not return you to builtin editor. Description: If elm is suspended (ie ^Z in csh), when composing a message in the builtin editor, a resume (fg in csh) brings you back in at the send/edit/forget set of prompts. EB53 Version: 2.4PL20 Status: Open Open Date: 7-Jan-93 Close Date: Reported by: robert.howard@matd.gatech.edu Summary: Change alias can list names incorrectly. Description: Using the new (C)hange Alias in the alias screen, the first name and the last name are displayed as the same thing (the entire string). [Comment from Dev team] This is a feature not a bug. This occurs for entries that weren't set up as Howard; Robert in the text file (entry was still the old way, Robert Howard). Thus you get the whole thing both times so you can delete what you don't want. Utilities bugs ~~~~~~~~~~~~~~ UB02 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Newmail cannot handle null From: headers. Description: 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 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Arepdaemon does not check user permissions. Description: Arepdaemon has a bad security hole because it does not check to see if the user can read the file used for reply. UB09 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Arepdeamon does not check status when unlinking data file. Description: 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 Version: 2.4PL0 Status: Open Open Date: 1-Oct-92 Close Date: Reported by: Elm Development Group Summary: Filter has no locking against multiple instantiations. Description: 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. UB15 Version: 2.4PL17 Status: Open Open Date: 25-Dec-92 Close Date: Reported by: Larry Rosenman Summary: readmsg does not honour Content-Length: headers Description: Readmsg does not honour Content-Length: headers - it uses the old standard of marking messages with From_ headers. This makes it inconsistent with elm, and can make it imposible to print messages from within elm. -- elmbugs speaking for nigelm -- end of elm bug database The Elm(tm) Mail System (C) Copyright 1988-1993, 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... (Note: As of 2.4, this has been removed from Elm, as routing mail transports are now readily available for all UNIX systems). 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.4PL22 Datacomp Systems, Inc. Projected 3.0 Release: ??? ?,1994 syd@DSI.COM or dsinc!syd Voice: (215) 947-9900, FAX: (215) 938-0235