Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!think!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!pyramid!fmsrl7!wayne From: wayne@fmsrl7.UUCP (//ichael R. //ayne) Newsgroups: comp.mail.misc Subject: Re: MH (was Re: X.400 ean mail system) Message-ID: <1866@fmsrl7.UUCP> Date: Thu, 3-Sep-87 20:59:21 EDT Article-I.D.: fmsrl7.1866 Posted: Thu Sep 3 20:59:21 1987 Date-Received: Sat, 5-Sep-87 15:33:28 EDT References: <186@bernina.UUCP> <1518@fmsrl7.UUCP> <21683@lll-tis.arpa> Reply-To: wayne@fmsrl7.UUCP (/\/\ichael R. \/\/ayne) Organization: Ford Motor Company, Scientific Research Labs, Dearborn, MI Lines: 70 Keywords: MH (Rand Mail Handler), sendmail, Summary: elm is lacking In article <21683@lll-tis.arpa> kehres@lll-tis.arpa (Tim Kehres) writes: >In article <1518@fmsrl7.UUCP> wayne@fmsrl7.UUCP(/\/\ichael R. \/\/ayne) writes: >> >> MH is a fabulous mail handling system if you get lots of mail. >> Having used it, I find other mailers intolerable (elm is particularly >> infuriating). > >I think Dave Taylor's comments should apply here also. If you dislike >the way a given piece of software runs (as it appears you do), please also >include some description of what it is you dislike about the software, and >if possible, some suggestions for the improvement of that software. There >are a lot of folks running elm and from what I have heard, most are quite >happy with it. As with most software, there is probably some room for >improvement, but the best way that the developers (or maintainers) can >decide what to improve, they many times rely on constructive feedback from >the user community. Although I could probably write a 25 page response to this, it would be useless. The elm manual even suggests that MH is preferred if you recieve a lot of mail (in the section discussing other mailers). This implies that the author is already familiar with MH, knows it's advantages and chose not to implement them. I suppose that I should mention a few specific complaints. Elm likes to use 1 file to hold a folder, MH uses a directory (like news). Loading a 850K folder(my inbox, for example) with elm takes a LONG time. Elm believes in "hiding" the header info from the user when composing a message, assuming that you typed it in correctly when you started. No recursive folders (without directories, this would be difficult), no filters (without sendmail), alias list is VERY limited (I tried to set up a simple, 25 person mailing list and it choked), minimal message manipulation commands (like, how do I link, not copy, a message into two folders?). In summary, elm is fine if you only get a few messages per day. For those people who get 250+ messages over a weekend, however, it just doesn't make it. On a vanilla SysV box, with the 1 meg file limitation, folders become useless real fast. I do like the "answering service" feature though, I suspect that this could be implemented in MH but have not tried. >> Unfortunately, the developers REALLY want you to run >> sendmail as a transport agent. The documentation claims that MH can run >> without it but it doesn't really work. > >I have heard that it also works quite well with mmdf. Anyone running this >wish to comment??? The MH installation guide suggests the following: sendmail - best mmdf - OK standalone (ie MH as a transport layer) - not recommneded >> If you are on a BSD machine and you get a lot of mail, try MH. >> If you are on a System V machine and you have sendmail, contact me (I >> want it BAAAD) and get MH. > >If you have access to the arpanet, there is a copy of the sendmail sources >on one of the Berkeley machines. I have source to sendmail, but it does not compile on either of my machines and I have not had the time to really dig into it. I have repeatedly posted requests for sendmail running on SysV. The only thing I have gotten back is a LOT of requests from other people that want it too (looks like a common problem). One person (mcvax!eiger!peter@uunet) sent me a shell script which is supposed to "replace" sendmail. I have not managed to get it to work for me, however (although I'm still working on it). -- Michael R. Wayne *** TMC & Associates *** Arpa: wayne@ford-vax.arpa uucp: {philabs | pyramid} !fmsrl7!wayne OR wayne@fmsrl7.UUCP