Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!orion.oac.uci.edu!ucivax!gateway From: cwm@sooner.palo-alto.ca.us (Chris Moore) Newsgroups: comp.protocols.iso.x400 Subject: Re: Sun/Wollongong X.400 MTA...Can Someone Give Details? Message-ID: <1991Jun23.212908.17187@sooner.palo-alto.ca.us> Date: 25 Jun 91 23:03:34 GMT References: <9106192056.2.15147@cup.portal.com> <1991Jun21.154352.28104@sooner.palo-alto.ca.us> Organization: Moore Home Computing, Palo Alto Lines: 57 Approved: usenet@ics.uci.edu x-attn: jns ReSent-From: Re-sent but not originated by Jerry Sweet ReSent-To: mhsnews@ics.uci.edu In an earlier article I wrote: > ....... In some cases (IBM's >AIX 3.0?) there is a user agent that is intented to apear as if >it is in both communities and provide access to the various >service elements --- presumably this is done by with ........ Someone pointed out that I wasn't real clear in the above so I'm going to take another stab at it: In essence, with both TWG's and Sun's products as well as others in the market you are getting an X.400 capable transport system and an X.400/SMTP gateway to go along with your SMTP system. They provide different degrees of integration between the two transport systems but at this point these products are not providing you fundamentally new user agents. So if you are dealing with this type of product you will have existing popular interfaces (mailx, mh, elm, mailtool, etc.) available to you. For all practical purposes these interfaces are anchored in one community (SMTP) and must use a gateway to get mail to recipients in the other community (X.400). By having an interface that is "anchored" into the SMTP community you are going to be working with SMTP style addresses, header fields, etc.. X.400 has a different notion of these items. A gateway provides the mechanism to get between the two interpretations. Rarely is this totally transparent to the user. I'm aware of at least one product that uses a hybrid approach by taking MH and extending it to make it use X.400 transparently. The idea being that the same user-interface is attached directly to the X.400 system as well as the SMTP system. This has the advantage of allowing the user to directly access X.400 features that are otherwise not available in SMTP (i.e., multi-part bodies and binary encoded information). Of course it also has its disadvantages -- messages may be fundamentally different depending on the community they are from (X.400 or SMTP) -- for example an address for an X.400 users will appear in its native format which is quite different than the SMTP address. I believe this is bad since it puts the user in the position of thinking out the gateway process (i.e., is Bob an X.400 user or an SMTP user?). Back to the original question: > portal!cup.portal.com!Will@uunet.uu.net writes: > >Can someone give details about how Sun and Wollongong have > >implemented the X.400 Message Transfer Agent in UNIX? Is > >the intent to gateway SMTP names to X.400 names, or in theory > >could a single user agent simultaneously use SMTP and X.400 > >transfer agents to send mail to the respective domains? By my understanding, in both the Sun and Wollongong case you are still dealing with the same SMTP based user interfaces that you had before getting their X.400 products. This means that you will be using a gateway to get between SMTP and X.400. In order to interface to both transports (X.400 & SMTP) directly then a new/modified user agent it needed. - Chris