Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sooner.palo-alto.ca.us!cwm
From: cwm@sooner.palo-alto.ca.us (Chris Moore)
Newsgroups: comp.dcom.lans
Subject: Re: SMTP--MHS gateway? (was Re: SMTP Email gateway)
Message-ID: <1991Jun18.214601.13146@sooner.palo-alto.ca.us>
Date: 18 Jun 91 21:46:01 GMT
References: <7816@spdcc.SPDCC.COM> <04ig41w164w@wwoh.com> <59923@aurs01.UUCP> <46175@cos.com>
Distribution: usa
Organization: Moore Home Computing, Palo Alto
Lines: 57

howard@cos.com (Howard C. Berkowitz) writes:
>Many UNIX-based X.400 systems have an inherent SMTP (or at least
>UNIX mail) to X.400 capability, due to the architecture
>of the overall messaging product.  Remember that X.400 is
>effectively a mailer, not a user interface.

>A common way of implementing X.400 on UNIX is to leave
>sendmail as is, and let it build the normal uucp queues.
>Periodically, crontab scans the uucp queues and looks for
>messages with X.400 addresses.  Those messages are then
>converted to X.400 format.  The uucp mailer and X.400
>Message Transfer Agent are invoked independently to send
>out queued messages.

Howard makes a good point that SMTP is a standard feature on most (all?)
unix systems.  However, I am not aware of any systems, other than the Berkeley
software releases which have ISODE (? I'm not even sure about those), that 
actually ship X.400 software with the system.  Typically you are going to look
to either the system maker or a third party like Touch or Retix to provide the
X.400 component at an additional cost.  Just about all of your options will use
different internal architecures -- using Sendmail for SMTP processing and some
X.400 software coexisting with it is common (I know that Touch does it this way).

I'd never heard of a system actually using cron for processing the mail queues.
All the software I've seen for this kind of processing either implemented its
own polling mechanism or used a dynamic invocation method for transfering mail
between the two communities (X.400 and SMTP).

>This explanation deals with creating mail to send out.
>As long as a system can create UNIX mail and get it to the
>queues of a machine with UNIX and X.400 mailers, the
>necessary conversions can take place.

In this scenario it is important to take note that the two communities of
users (X.400 and SMTP) are being gatewayed between.  This, in many cases,
results in awkward representations of information particular to one community
or the other in the other.  X.400 addresses can be difficult to deal with
in the SMTP community and vice versa.  There are many ways that people have
used to simplify this -- some work well and others are quite limited in their
ability to support large user communities.

If you are using an SMTP based mail interface (mailx, mh, elm, etc.) you will
be able to get mail to recipients on the other side of the gateway but it isn't
guaranteed that you will be able to utilize all types of X.400 services options.
The opposit is also quite true -- X.400 users may not be able to make use of
all their services in sending a message to an SMTP recipient.

All this really leads to the observation that today some software systems exist
that stuggle to allow the various communities to coexist.  Using an X.400 mail
system and Sendmail on the same system is duplicating many functions and in 
most cases brings on additional administrative problems.  There are some newer
software systems, like PP which was developed at UCL, that take an integrated
approach to handling both communities (and others).... I really think this is
the type of long term direction that the software systems will have to follow
in order to provide adequate support for both communities.

  - Chris