🚀 go-pugleaf

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