Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!mcvax!cernvax!ethz!peter From: peter@ethz.UUCP (Peter Beadle) Newsgroups: comp.mail.misc Subject: Re: X.400 ean mail system Message-ID: <189@bernina.UUCP> Date: Mon, 31-Aug-87 07:53:21 EDT Article-I.D.: bernina.189 Posted: Mon Aug 31 07:53:21 1987 Date-Received: Sat, 5-Sep-87 09:42:45 EDT References: <186@bernina.UUCP> <719@hplabsz.HPL.HP.COM> Reply-To: peter@bernina.UUCP (Peter Beadle) Organization: Institute for Integrated Systems, ETH Zuerich, Switzerland Lines: 152 Keywords: ean, mail, x.400 Summary: a gentle flame, a little long (164 lines) In article <719@hplabsz.HPL.HP.COM> taylor@hplabsz.UUCP (Dave Taylor) writes: >First off, I think it is important to note that X.400 and the related >ISO/CCITT standards are indeed an up and coming standard for the >interchange of electronic mail in the world (certainly in Europe). In >fact sources from both DEC, HP, and some third party market analysts >tell me that it is almost impossible to sell any large computer boxes >to firms there unless they have available an X.400 mail system... To this I agree, the X.400 protocols are quiet nice. Unfortunately the group here responsible for maintaining the ean mail system repeatedly tell me "the EAN implementation of the x.400 protocol package is a heap of sh*t". I manage the mail and wide area network for the machine Mitchel Wyle's mail goes through. This machine has 4 gateways to disparate networks (uucp, cipon, ean and ACSnet) and sometimes (depending on the weather) acts as the ean-csnet gateway. ACSnet runs itself and tells me what it's been doing once a month (it suports remote job execution, binary transfer (on 7bit, 8bit and x25 lines), file server, remote printing, and acts as an inter network gateway) all the others require work. All the machines in a cluster of ~40 run uucp (over ethernet) as the transport level with the upas mail system (Bell Labs) doing the routing and acting as a name server. Running on top of that we have a modified /bin/mail, ucb/mail, mh and sun's mailtool interface to /ucb/mail there are also a gagle of emacs based mail programs and Mail (if anyone remembers that antique). On the gateway machine we also have ean running. I don't administer ean and frankly wish it would go away. I have used the system and gave up after many complaints from correspondants who got tired of "auto forwarding" as the non-delivery reason in the bounce messages they received. It also appears that there is no way in ean to do any of the usefull mail filtering things that make email usefull in administering machines. I say apparently because the only documentation available is the online help from inside the ean system, there is no machine manual and no paper manual available to users of the system and I doubt it is available to the administrators. >package. 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. Yes the ean-isation of Switzerland is well underway. It's a pity they couldnt be bothered to develope their own x400 system instead of importing a bad one from Canada. I am also not really worried about the translation time, I simply want a mail system that works. Most sites understand either rfc-822 or uucp mail headers, we provide both. We have no trouble gatewaying into ean with our rfc-822 headers. Unfortunately the ean system can't even provide a from address to our mailer so it can correctly set the from fields on mail coming from ean into uucp/rfc-822. I have also been told that on the next release of ean they will provide a date field in the header. A great leap forward. >standard either. The tough fact of the matter is that it is almost >completely irrelevant whether we like the standard or not - X.400 is >happening now regardless. There are already countries where, as I said >previously, you *cannot* sell machines unless you offer a complete X.400 The point is the ean implementation of x.400, not x.400 itself. Could you please supply some proof for your claim about x400 and computer sales. >So with that preamble, I'd like to highlight the deficient areas of the >EAN package, based *purely* on what Mitchell Wyle posted in his article. Have you ever tried to use the ean package. If not I sugest you try to get access to an ean system and see how it feels. (give me a call and I will give you our modem number). >The first problem that is raised is that of the data storage method. Not >only does EAN use a unique format for the storage of data (which, I would >venture a guess, is related to X.408 (MHS: Encoded Information Type >Conversion Rules) and X.409 (MHS: Presentation Transfer Syntax and Notation) >standards if nothing else..) No it's because ean seems to use the cheap nasty dbm data base that comes with 4.2 with the result that the files it creates can't be manipulated with standard unix comands. Still I supose popple live with the Itallian postal service (average delivery speed 6 m.p.h. and a nasty habit of shreading the mail backlog. >One of the stranger aspects of the X.400 suite from our anglocentric >point of view here in the US is that it doesn't store everything in an >English-based format. In fact, the method by which the message >envelope (as they say) is built up and saved is designed to be as >*in*dependant of host language as possible. One of the 'headers' of >an X.400 message is in fact the language that it was composed in, so >that the displaying system can easily choose the appropriate character >set. An obvious side effect of this is that the data storage format >for the messages cannot suddenly be in a different, '822 style, format. >So instead, you're left with the necessity of having to use various >utilities to help maintain your data space. All very interesting, if you could rely on your data base the it might even work. If you could rely on your communication medium there would be no need for uuencode/decode, binhex and innumerable other programs that convert binary into ascii and back and you would be much further towards a usable "communications" system. I think the reliable communication system would bring you a lot more than selecting the language style in the mail header. >Given that, I would suspect that the EAN group would be more than just >interested in hearing about problems with the reliability of their >system! They already know of the problems, see my earlier quote about their summary of the system. > people aren't willing to work with their software vendors in situations > such as this It's a little hard when the software vendor is a University on the other side of the Atlantic and the people who developed th code have long since graduated and moved on. I refer you to another article in this news group about a commercial x400 system, source lisence only 250,000 pounds sterling. Per cpu lisence only 5000 pounds. Summary: There is nothing wrong with the x.400 protocols. It would be good if they become a european standard. The currently available x-400 implementations stink. I would love to hear somone from the University of British Columbia defend their system. Ean appears to lack: . adequate documentation for users, . support for mail filtering, . methods of turning off stupidities (like auto forwarding as a non delivery reason) . alternate presentation system (you get the ean presentation system and thats all) . support for file transfer and remote execution which where there in the most primative uucp mail systems Peter Beadle uucp peter@eiger.uucp ean/csnet peter@ifi.ethz.ch (try this one for a non delivery bounce message) uucp mcvax!cernvax!ethz!eiger!peter acsnet peter@bernina.ch