syd@dsinc.UUCP (Syd Weinstein) (02/13/89)
This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator. This posting generated:
Mon Feb 13 10:36:36 EST 1989
Current release version: Elm 2.1 PL1
Patches are available from the archive server at dsinc.UUCP:
send mail to archive-server@dsinc.UUCP, patch 1 is available as
send elm elm2.1.p1
Current development version: Elm 2.2d
Freeze for testing: 3/1/89
Anticipated release: 4/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 currently
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
and releases as of the current patch level are available via anon. uucp from
dsinc. Instructions for obtaining files via anon. uucp from dsinc are also
available from the archive server. Elm is too large to mail, don't bother
asking.
Currently, your coordinator does not have records on any ftp sites offering
Elm for anon. ftp. Those sites offering that service should send a message
to elm@dsinc and they will be included in future postings of this message.
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 Bell system V, with a little BSD thrown in. Since then, it has been
ported to Bell, 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-0235syd@dsinc.DSI.COM (Syd Weinstein) (04/29/89)
This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator. This posting generated:
Fri Apr 28 21:03:16 EDT 1989
Current release version: Elm 2.2 PL5
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 DSI.COM:
send mail to archive-server@DSI.COM
send elm index
Known bugs in Elm 2.2 PL5:
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).
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. (Partially fixed in PL5)
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.
GB08 [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.
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.
EB04 When the user `r' replies to a form (fills in a form),
elm(1) doesn't prompt correctly for the fields in the form.
This has not be researched and it is not clear how broken
the forms feature is.
EB05 Expiration dates in elm(1) are allegedly not calculated
correctly, perhaps only around changes of year. One user
reported than in asking for an expiration 10 days into the
future in December, the expiration date was calculated to be
in February, and thinks that elm(1) might have added in 1
month and 10 days instead of merely 10 days.
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.
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.
EB18 The USE_DOMAIN option should only be configurable if INTER-
NET addresses are being configured.
EB19 The USE_DOMAIN option adds the domain name before the selec-
tion of the local vs. remote signature is decided thereby
causing a local address to appear as if remote.
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.
EB22 If you have a BSD system and want to compile in the host-
name, you don't get the needed include of <sys/utsname> in
opt_utils.c
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. This might not be correct as smail 2.5 using the
same pathalias database gives precedence to the @.
EB27 [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.
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.
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 [next item goes here]
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@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. 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.
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
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235news@ivucsb.UUCP (Todd Day) (05/03/89)
In article <122@dsinc.DSI.COM> syd@dsinc.DSI.COM (Syd Weinstein) writes:
~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.
I don't consider this a bug, just a feature. Lots of times when I am
forwarding messages, I don't wan't all the quote stuff in the left
hand column. Before I found this "bug", I had to use
:s/^~//g
in vi to get rid of them. If you do plan to "fix" this, please add
an easy way to get rid of the quotes.
~
--
-Todd Day-
UUCP: {pyramid, ucbvax}!ucsbcsl!nessus!ivucsb!todd
Internet: todd%ivucsb.UUCP@anise.acc.comindra@hobbes.amd.com (Indra Singhal) (05/03/89)
In article <770@ivucsb.UUCP> news@ivucsb.UUCP (Todd Day) writes: #In article <122@dsinc.DSI.COM> syd@dsinc.DSI.COM (Syd Weinstein) writes: #~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. # #I don't consider this a bug, just a feature. #-Todd Day- #Internet: todd%ivucsb.UUCP@anise.acc.com Ditto. I agree with Todd. I think if you are forwarding a message and are not adding any text of your own, there is no need to distinguish between added text and forwarded text. Therefore, there is no need to prepend the prefix string to the forwarded text. Further, like Todd said, this is a good way when you dont want to have the prefix string rather than having to use an editor to get rid of it. Oh, BTW, has anyone been able to compile on a SunOS4 on Sun3/60 at PL5? Indra K. Singhal {ucbvax,decwrl,allegra}!amdcad!indra indra@amdcad.AMD.COM (408) 749-5445(w)
tim@attdso.att.com (Tim J Ihde) (05/03/89)
In article <770@ivucsb.UUCP> news@ivucsb.UUCP (Todd Day) writes: >In article <122@dsinc.DSI.COM> syd@dsinc.DSI.COM (Syd Weinstein) writes: >~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. >I don't consider this a bug, just a feature. Lots of times when I am >forwarding messages, I don't wan't all the quote stuff in the left >hand column. Before I found this "bug", I had to use >:s/^~//g >in vi to get rid of them. If you do plan to "fix" this, please add >an easy way to get rid of the quotes. I used to do this alot, mostly if I got back a message that bounced off another machine due to an invalid address that I wanted to correct. With the new version, though, I find the (b)ounce command takes care of this quite nicely - the only problem being that it does not give you the option to edit the bounced mail. I would suggest that adding an edit option to (b)ouncing mail would be more consistant than not quoting forwarded mail. tim -- Tim J Ihde INTERNET: tim@attdso.att.com (201) 898-6687 UUCP: att!attdso!tim "Blimey - this redistribution of wealth is more complicated than I'd thought!" - Dennis Moore and various Presidents
syd@dsinc.DSI.COM (Syd Weinstein) (05/25/89)
This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator. This posting generated:
Wed May 24 21:46:47 EDT 1989
Current release version: Elm 2.2 PL8
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 DSI.COM:
send mail to archive-server@DSI.COM
send elm index
Known bugs in Elm 2.2 PL8:
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.
GB08 [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.
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.
EB04 When the user `r' replies to a form (fills in a form),
elm(1) doesn't prompt correctly for the fields in the form.
This has not be researched and it is not clear how broken
the forms feature is.
EB05 [ Fixed in patch 8 ] Expiration dates in elm(1) are alleged-
ly not calculated correctly, perhaps only around changes of
year. One user reported than in asking for an expiration 10
days into the future in December, the expiration date was
calculated to be in February, and thinks that elm(1) might
have added in 1 month and 10 days instead of merely 10 days.
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.
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.
EB18 [ Fixed in patch 8 ] The USE_DOMAIN option should only be
configurable if INTERNET addresses are being configured.
EB19 [ Fixed in patch 8 ] The USE_DOMAIN option adds the domain
name before the selection of the local vs. remote signature
is decided thereby causing a local address to appear as if
remote.
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.
EB22 [ Fixed ] If you have a BSD system and want to compile in
the hostname, you don't get the needed include of
<sys/utsname> in opt_utils.c
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. This might not be correct as smail 2.5 using the
same pathalias database gives precedence to the @.
EB27 [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.
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.
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 [next item goes here]
May 24, 1989
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@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. 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.
The following sites have agreed to make Elm available via anonymous ftp.
Site Contact
mthvax.miami.edu a.e.mossberg, aem@mthvax.miami.edu
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-0235syd@DSI.COM (Syd Weinstein) (11/15/89)
This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator. This posting generated:
Tue Nov 14 23:06:14 EST 1989
Current release version: Elm 2.2 PL13
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
All 13 patches have been sent to comp.sources.unix,
none have yet appeared.
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 PL13:
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] [fixed in
2.3]
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. [partially fixed in 2.3]
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 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.
EB37 When Elm is setgid, it was allowing access to other mail-
boxes. [fixed in patch 13]
EB38 [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:
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: 2/1/90
Anticipated release: 4/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-0235syd@dsinc.DSI.COM (Syd Weinstein) (05/25/90)
This is the monthly Elm Posting from the Elm Development Group and
your Elm Coordinator. This posting generated:
Thu May 24 13:20:21 EDT 1990
Current release version: Elm 2.3 PL0
This version was released at patch level 0.
comp.sources.unix Posting-number: Volume 22, Issues 60-85
Archive-name: elm2.3/part01 thru elm2.3/part26
Patches are posted to comp.sources.bugs and comp.mail.elm
After they are stable, patches are sent to comp.sources.unix
No patches have yet been generated.
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,
or mailer-daemon. Please use your own login when requesting information
from the archive server.
Planed next version: Elm 2.4
Current Elm 2.4 status: Not even started
Expected release date: 5/1/91
Known bugs in Elm 2.3 PL0:
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.3 for some, but not necessarly all of these. Some
of these will only be fixed in 2.4. (It depends on how extensive the
change is to fix it, and what else it ties into in the 2.4 work).
Items marked fixed will be deleted from the list on the next posting.
Known bugs in ELM 2.3
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.
GB09 [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.
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.
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.
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" 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.
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.
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.
EB40 [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.
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.
UB12 [next item goes here]
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 this new version to reduce the
surprise element. This list is not designed to be a complete list
of the changes in 2.3.
1. Aliases will now be case insensitive. This as per the survey
results of Elm users and matches sendmail aliases.
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.
If no uuname command exists, then unreachable address warnings
are not performed.
3. Support for NFS in that the alias data file can be kept in
network byte order.
4. Support for MMDF style mailboxes.
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)
In Europe:
sol.cs.ruu.nl Edwin Kremer, edwin@cs.ruu.nl
(131.211.80.5)
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.
The Elm(tm) Mail System
(C) Copyright 1986, 1987, by Dave Taylor
(C) Copyright 1988, 1989, 1990, 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 dsinc!syd FAX: (215) 938-0235syd@dsinc.DSI.COM (Syd Weinstein) (10/03/90)
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). This posting
generated:
Tue Oct 2 16:58:29 EDT 1990
Current release version: Elm 2.3 PL6
This version was released at patch level 0.
comp.sources.unix Posting-number: Volume 22, Issues 60-85
Archive-name: elm2.3/part01 thru elm2.3/part26
Patches are posted to comp.sources.bugs and comp.mail.elm
After they are stable, patches are sent to comp.sources.unix
Patches 1 through 6 have been sent to comp.sources.unix.
No patches have yet appeared in 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.
Planed next version: Elm 2.4
Current Elm 2.4 status: In development
Expected release date: not before 5/1/91
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 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
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)
In Europe:
sol.cs.ruu.nl Edwin Kremer, edwin@cs.ruu.nl
(131.211.80.5)
In the UK:
uk.ac.soton.ecs T.Chown@ecs.soton.ac.uk (bitnet)
T.Chown@uk.ac.soton.ecs (JANET)
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.3 PL6:
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.3 for some, but not necessarly all of these. Some
of these will only be fixed in 2.4. (It depends on how extensive the
change is to fix it, and what else it ties into in the 2.4 work).
Items marked fixed will be deleted from the list on the next posting.
Known bugs in ELM 2.3
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.
GB09 All addresses need to support both an escape character and
quoting the name portion to allow for illegal chars and
blanks.
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.
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.
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.
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.
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" 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.
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.
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.
EB40 If reading an alternate folder and all messages are marked
for deletion and a resync is performed, the folder is delet-
ed and Elm exits saying it cannot open the folder. [par-
tially fixed in PL 6]
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.
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.
UB12 X.400 now also uses the = in its addresses, newalias was
changed from : to = due to X.400, but now even = is not
good for a delimiter. Newalias needs to have an escape
mechanism for its addresses. This needs to be coordinated
with GBxx.
UB13 [next item goes here]
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 this new version to reduce the
surprise element. This list is not designed to be a complete list
of the changes in 2.3.
1. Aliases will now be case insensitive. This as per the survey
results of Elm users and matches sendmail aliases.
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.
If no uuname command exists, then unreachable address warnings
are not performed.
3. Support for NFS in that the alias data file can be kept in
network byte order.
4. Support for MMDF style mailboxes.
The Elm(tm) Mail System
(C) Copyright 1986, 1987, by Dave Taylor
(C) Copyright 1988, 1989, 1990, 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 dsinc!syd FAX: (215) 938-0235syd@dsinc.DSI.COM (Syd Weinstein) (10/25/90)
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). This posting
generated:
Wed Oct 24 16:55:15 EDT 1990
Current release version: Elm 2.3 PL8
This version was released at patch level 0.
comp.sources.unix Posting-number: Volume 22, Issues 60-85
Archive-name: elm2.3/part01 thru elm2.3/part26
Patches are posted to comp.sources.bugs and comp.mail.elm
After they are stable, patches are sent to comp.sources.unix
Patches 1 through 6 have been sent to comp.sources.unix.
No patches have yet appeared in 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.
Planed next version: Elm 2.4
Current Elm 2.4 status: In development
Expected release date: not before 5/1/91
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 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
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)
In Europe:
sol.cs.ruu.nl Edwin Kremer, edwin@cs.ruu.nl
(131.211.80.5)
In the UK:
uk.ac.soton.ecs T.Chown@ecs.soton.ac.uk (bitnet)
T.Chown@uk.ac.soton.ecs (JANET)
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.3 PL8:
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.3 for some, but not necessarly all of these. Some
of these will only be fixed in 2.4. (It depends on how extensive the
change is to fix it, and what else it ties into in the 2.4 work).
Items marked fixed will be deleted from the list on the next posting.
Known bugs in ELM 2.3
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. [Reported no longer to be a problem, speak
up fast if you think it still is.]
GB09 All addresses need to support both an escape character and
quoting the name portion to allow for illegal chars and
blanks.
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.
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.
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.
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.
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" 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.
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". [Fixed in 2.3 PL7]
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.
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.
EB40 If reading an alternate folder and all messages are marked
for deletion and a resync is performed, the folder is delet-
ed and Elm exits saying it cannot open the folder. [par-
tially fixed in PL 6]
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.
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.
UB12 X.400 now also uses the = in its addresses, newalias was
changed from : to = due to X.400, but now even = is not
good for a delimiter. Newalias needs to have an escape
mechanism for its addresses. This needs to be coordinated
with GBxx.
UB13 [next item goes here]
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 this new version to reduce the
surprise element. This list is not designed to be a complete list
of the changes in 2.3.
1. Aliases will now be case insensitive. This as per the survey
results of Elm users and matches sendmail aliases.
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.
If no uuname command exists, then unreachable address warnings
are not performed.
3. Support for NFS in that the alias data file can be kept in
network byte order.
4. Support for MMDF style mailboxes.
The Elm(tm) Mail System
(C) Copyright 1986, 1987, by Dave Taylor
(C) Copyright 1988, 1989, 1990, 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 dsinc!syd FAX: (215) 938-0235syd@dsinc.DSI.COM (Syd Weinstein) (11/30/90)
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). This posting
generated:
Thu Nov 29 13:52:35 EST 1990
Current release version: Elm 2.3 PL8
This version was released at patch level 0.
comp.sources.unix Posting-number: Volume 22, Issues 60-85
Archive-name: elm2.3/part01 thru elm2.3/part26
Patches are posted to comp.sources.bugs and comp.mail.elm
After they are stable, patches are sent to comp.sources.unix
Patches 1 through 6 have been sent to comp.sources.unix.
No patches have yet appeared in 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.
Planed next version: Elm 2.4
Current Elm 2.4 status: In development
Expected release date: not before 5/1/91
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 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
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)
In Europe:
sol.cs.ruu.nl Edwin Kremer, edwin@cs.ruu.nl
(131.211.80.5)
In the UK:
uk.ac.soton.ecs T.Chown@ecs.soton.ac.uk (bitnet)
T.Chown@uk.ac.soton.ecs (JANET)
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.3 PL8:
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.3 for some, but not necessarly all of these. Some
of these will only be fixed in 2.4. (It depends on how extensive the
change is to fix it, and what else it ties into in the 2.4 work).
Items marked fixed will be deleted from the list on the next posting.
Known bugs in ELM 2.3
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.
GB09 All addresses need to support both an escape character and
quoting the name portion to allow for illegal chars and
blanks.
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.
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.
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.
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.
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" 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.
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.
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.
EB40 If reading an alternate folder and all messages are marked
for deletion and a resync is performed, the folder is delet-
ed and Elm exits saying it cannot open the folder. [par-
tially fixed in PL 6]
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.
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.
UB12 X.400 now also uses the = in its addresses, newalias was
changed from : to = due to X.400, but now even = is not
good for a delimiter. Newalias needs to have an escape
mechanism for its addresses. This needs to be coordinated
with GBxx.
UB13 [next item goes here]
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 this new version to reduce the
surprise element. This list is not designed to be a complete list
of the changes in 2.3.
1. Aliases will now be case insensitive. This as per the survey
results of Elm users and matches sendmail aliases.
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.
If no uuname command exists, then unreachable address warnings
are not performed.
3. Support for NFS in that the alias data file can be kept in
network byte order.
4. Support for MMDF style mailboxes.
The Elm(tm) Mail System
(C) Copyright 1986, 1987, by Dave Taylor
(C) Copyright 1988, 1989, 1990, 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 dsinc!syd FAX: (215) 938-0235