lubich@ethz.UUCP (08/31/87)
Being co-responsible for parts of the e-mail systems here at ethz and for ean-administration in Switzerland, I would just make some remarks on Mitch's posting. In Article 347 of comp.mail.misc taylor@hplabsz.HPL.HP.COM (Dave Taylor) writes: >In an environment of that nature, it is somewhat ironic to read that >a sophisticated, knowledgeable Unix user like Mitchell Grin, grin (sorry Mitch, I just couldn't resist) :-) >My first curious question is how long will Mitchell be able >to use Berkeley Mail to send and receive mail there in Switzerland? I >can imagine in the very near future his machine suddenly not speaking >the "RFC-822 style" mail that Berkeley Mail expects and generates. Or, >as an alternative, having the extra overhead of a gateway/translator >for each message sent, even those local to his machine. Switzerland is already embedded into the RARE research and development message handling systems project that will end up in a x.400 mail network all over Switzerland within the next 6 months or so and, as the main goal, in a x.400 network all over Europe within the next years. At first the network, here in Switzerland at least, will base on EAN V2. There will be an official RFC822 to x.400 gateway (according to RFC987) maintained by the same service people that will be responsible for the X.400 network here in Switzerland. If Mitchell decides to connect to this gateway using a standard interface that will be announced to everybody here and to support this connecting by himself, that's just fine. What makes me most angry about Mitch's flame posting is that most of the 'bugs' and inconveniances that he talks about could be cured by just reading the manual. Anyway, here is just a quick comment to the points Mitch tried to make: (gathered by B. Plattner and me:) > >Because ean uses a >bizarre method of storing its data (db5), one must periodically "clean" >the data files ean creates. Otherwise, they would continue to grow >without bound, until the disk is full. True. >One day, the "eanrebuild" >command destroyed all of my ean data. Upon restoring the data from a >backup tape, ean refused to read the restored data. This is in contrast to our experiences. The EAN storage method is compatible with tar and dump/restore backup programs. Moreover the "eanrebuild" command allocates a disk backup folder system (ean.bak) before rebuilding. Rumors say that Wyle deleted this backup himself ...and that the rebuild operation failed because he had 2 rebuild processes running at the same time. >A mail system >which 1) needs a dangerous, periodic "clean-up" command, and 2) cannot >read restored data is unacceptable. The data cannot be moved to tape >and back to disk. No backup is possible; therefore ean is >unacceptable. If anything is unacceptable, it's this conclusion. > >The eanrebuild command is simply a nuisance which does not belong in a >computer system. Agree. >One could live with such an inconvenience if backup >were possible. It is. > >Ean's user interface is as poor as most other electronic mail >systems'. True, but speak to UBC instead of just flaming. >There is no way to specify rules and actions (it is not >programmable). False. You may use message selector to automatically have messages stored in folders. >It has a flat storage method (one level of folders). True. >It does not take advantage of a video screen terminal. With the exception of full screen pagers and editors. >It has no >information retrieval system for mail messages. False. Messages may be retrieved on header fields, message numbers and history (e.g. chains of replies). Read the manual (message selectors) or use "help message". > >Ean cannot run on all unix systems. >It is specific for the DEC vax. The new version will run on BSD, ULTRIX, System V, and SUN. Moreover it runs on DEC VMS. >It's files cannot be used by other applications. False. You may use "print on file" and "#include" or editor functions to exchange data with the UNIX file system. >Almost all ean >messages I send arrive with an annoying "Parse error of original >messages in Switzerland" error message, which leads me to assume that >the lower layers of the system are as weak as the user interface and >no-backup features. This has nothing to do with EAN. The CSNET gateway code is quite picky with freeform addresses ("Bernhard Plattner" <plattner@ifi.ethz.ch>). True RFC822 Addresses should have the freeform name in double quotes, as shown above. The error message documents that the gateway fixed a user error by inserting the quotes. This I have explained to Mitch several times but he doesn't seem to listen to me :-) > >The public domain, University of California Berkeley's (UCB) Unix mail >system is not much better True. >but at least there is no "rebuild" command, >and the files are standard unix text files. One can use the Unix shell >environment, the "mail-tool" interface on Suns, and the file directory >tree to add structure to mail messages. UCB Unix mail is programmable >and richer in commands. It is standard on many different machines, and >identical on Suns and vaxen. Most importantly, the data are >interchangeable, and can be backed up! These conclusions are based on invalid assumptions, as shown above. --Hannes (still angry) ~ UUCP/Usenet : {known world}!seismo!mcvax!cernvax!ethz!lubich ~ CSNET : lubich%ifi.ethz.chunet@relay.cs.net ~ ARPA : lubich%ifi.ethz.chunet@csnet-relay.arpa The usual disclaimer : No, it wasn't me, somebody must have used my account. -- ~ UUCP/Usenet : {known world}!seismo!mcvax!cernvax!ethz!lubich ~ CSNET : lubich%ifi.ethz.chunet@relay.cs.net ~ ARPA : lubich%ifi.ethz.chunet@csnet-relay.arpa The usual disclaimer : No, it wasn't me, somebody must have used my account.