From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 24-NOV-1989 13:56
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: BITNET on VMS

Received: From UCBVAX.BERKELEY.EDU by GIZMO.SRI.COM with TCP; Wed, 22 NOV 89 19:20:57 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.39)
	id AA18791; Wed, 22 Nov 89 19:06:23 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 22 Nov 89 16:31:50 GMT
From: att!watmath!ria!uwovax!reggers@ucbvax.Berkeley.EDU  (Reg Quinton)
Subject: Re: BITNET on VMS
Message-Id: <4363.256a83a6@uwovax.uwo.ca>
References: <1243@atha.AthabascaU.CA>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <1243@atha.AthabascaU.CA>, tech@cs.AthabascaU.CA (Richard Loken) writes:
> What is available to handle BITNET on VMS both incoming and outgoing and if
> possible over TCP/IP (so that I can pass it off to the Unix machine with the
> bisync connection)?

The following came to my attention recently, the mention of our work for
vax/vms is a bit out of date. But suffice to say, we have a mailer for
vax/vms which *replaces* vax/vms mail, talks bsmtp to bitnet, talks smtp
over tcp/ip (using cmu/tek, fusion, or multinet). If you need more
information about my work, send me a note. You may retrieve it by ANONYMOUS
FTP from the PUB:[MAIL] area of hydra.uwo.ca [129.100.2.13]; I can also
send distributions out over BITNET.

For information about the other products listed, talk to the parties listed

************************************************************************
* MAILSOFT PRODUCTS is a collection of informations about free/low     *
*                   charged mail software products.                    *
*                   Contributions are welcome, please contact          *
*                          Udo Meyer <MEYER@DEARN.BITNET>.             *
************************************************************************
 
IBM VM/SP RSCS - > MAILER <
===========================
 .... deleted as not appropriate, REQ
************************************************************************
DEC VAX/VMS - > GMAIL <
=======================
 
  What is GMAIL?
  -------------
  GMAIL is a utility, implemented by a DCL command file, designed primarily
  to support the SENDing of mail messages to nodes on networks other
  than those directly supported by VMS MAIL and its jnet (or other)
  extension for BITNET.  The user interface for GMAIL is patterned
  closely after the sending functions of VMS MAIL.  GMAIL fully
  supports address lists and distribution files, and can handle a mix
  of 'foreign-network' addresses together with addresses which can be
  handled by VMS MAIL.  GMAIL invokes VMS MAIL to deal with those
  addresses which are VMS MAIL addresses.
 
  The address syntax that GMAIL supports for 'foreign-network' addresses
  is most often in the form  "user@host.domain", for instance,
  "USERX@NODEY.ARPA".  Such mail is handled by combining your letter with
  a suitable header, and sending it (using a form of the jnet SEND/FILE
  command or equivalent) via BITNET to a 'gateway' node, from where it
  is forwarded to its ultimate destination.
 
  GMAIL is a successor to the SENDGATE.COM procedure which in turn was
  based principally on Paul Kunz's SENDGATE EXEC procedure for VM/CMS
  systems.
 
  What isn't GMAIL?
  ----------------
  GMAIL is NOT fully integrated with VMS MAIL (for instance, in the manner
  of the 'jnet%' protocol supplied by Joiner Associates to support
  BITNET mail within the framework of VMS MAIL).  As a consequence, you
  CANNOT give these 'foreign' addresses to VMS MAIL--either directly or
  indirectly (e.g., as a VMS MAIL forwarding address).  Also, you cannot
  use VMS MAIL directly to REPLY or FORWARD to such a foreign address
  (but GMAIL DOES offer a fairly simple way to REPLY or FORWARD with a
  short series of MAIL and GMAIL commands.)  Since GMAIL is implemented
  with DCL, it is NOT blazingly fast.
 
  Obtaining GMAIL
  ---------------
  In order to obtain GMAIL and make arrangements to receive updates in
  the future a request should be sent to its developer, Ed Miller, at
  the BITNET address GMAIL@SLACTWGM.  Please state whether your address
  is a jnet node, in which case the file will be sent you in VMSDUMP
  format.  If you are not a jnet node, the file will be sent in NETDATA
  format (or PUNCH format if you cannot accept NETDATA format).
----------------------
************************************************************************
DEC VAX/VMS and UNIX - > SOFTWARE TOOLS MAIL SYSTEM <
=====================================================
 
            Introduction to the Software Tools Mail System
 
BACKGROUND
==========
 
    This distribution of the Software Tools Mail System was developed
under the Software Tools Virtual Operating System by Joseph Sventek
of the Lawrence Berkeley Laboratory and ported from Ratfor to C by
Kenneth Adelman and Bob Healey.  The Software Tools Mail System was
developed as a state-of-the-art mailer over five years ago and has
evolved with the internet to remain state-of-the-art mailer.
 
DESIGN ISSUES
=============
 
    Examination of existing mail systems indicates that the most
successful systems (in terms of extensibilty) are those which
partition the mail service into two layers: a delivery layer and an
user-interface layer.  Such an architecture provides for several types
of user-interface paradigms, while providing a constant delivery
service, independent of the user composition utility used.  This
partitioning has been strictly adhered to in this work.
 
    A major design flaw of many systems is the inability of the
delivery system to do anything with the mail other than store it in a
file somewhere.  This failing is due to a very narrow interpretation
of mail delivery.  When one user sends a message to another user, the
message is actually destined for the receiver's delivery agent.  While
typically the delivery agent simply appends the message to the user's
mailbox file, one should be able to specify an alternate delivery
agent which can dispose of the mail in another manner.  Such
capabilities as message forwarding, auto-reply, news services, etc.
are difficult to achieve without this capability.  As a result, this
capability is provided by the delivery system.
 
    Many mail systems fail to observe any standards with respect to
addressing, message format or transport protocol between hosts.  Due
to an absolute requirement for ARPANET compatibility locally, the
appropriate DARPA standards are followed for this system.
 
    As mail systems become more integrated into computing
environments, the adaptability of the software as needs and/or
standards change becomes crucial.  The application of accepted
software engineering techniques (structured design, virtual machine
concepts, etc.) to the system design is one way of assuring the
adaptability and maintainability of the software.
 
    Adaptability is especially important in the area of network
support.  Many prior systems were only concerned with, at most, one
network, and could therefore implement the network support in an ad
hoc manner.  Current and future systems will be required to
communicate over several network backbones (for example, one of the
LBL/CSAM hosts is connected to four different networks), with the
result that the modularity of the network support software will be
paramount in determining the utility of the delivery system.
 
    An important area to explore is the use of the mail system as a
network layer upon which to build high-level services.  The usefulness
of the system in such applications depends upon the degree to which
the pieces of the delivery system on separate hosts conform to
standards, as well as whether the mail service provides the guarantees
necessary to implement realistic high-level services.
 
    As in other areas of computer science, the appearance of
state-of-the-art software in no way guarantees the elimination of
obsolete (but functional) software performing similar services.  Since
communication requirements demand interaction with mail systems not
conforming to the adopted standards, it is necessary to provide
gateway functions between existing systems and any new implementation.
 
REQUIREMENTS
============
 
    The Software Tools Mail System is available for VAX/VMS and UNIX,
and should port readily to any multitasking operating system with a C
compiler.  The single source distribution includes the support for
all operating systems and networks.
 
    The VAX/VMS version requires VAX/VMS V4.4 or later, as well as
VAX/C V2.2 or later and VAX/Fortran.  Recommended, but not required,
is VAX/MMS for any sites doing source development. Both homogeneous
and heterogeneous VAXclusters and LAVC configurations are supported.
 
    The UNIX version requires either System III, System IV, 4.2bsd, or
4.3bsd Unix, but should work on any Unix or Unix derivatives
supporting either named pipes, message queues, or UNIX domain sockets
for interprocess communication. This kit has been tested on the
following varieties of Unix: PC/AT with Microsoft System V Xenix, VAX
4.3bsd, VAX 4.2bsd, Intel 310s with System III Xenix, Elxsi's 4.2bsd
Unix, Elxsi's Enix (System V Unix), and an HP-9000 with HP-UX Unix.
 
    Other requirements include sufficient disk space, memory, and
network interfaces and software as appropriate.
 
NETWORK INTERFACES
==================
 
Supported under VAX/VMS:
 
o   DECnet using VMSmail protocol. Allows gateway of mail to any vanilla
    VMS site. [May port easily to Ultrix.]
 
o   DECnet using SMTP protocol. Used for communication with another
    Software Tools Mail host. [May port easily to Ultrix.]
 
o   TCP/IP using SMTP protocol (either with or without header munging
    appropriate for an ARPAnet gateway). Supports one of MULTINET
    TCP/IP (recommended), The Wollongong Group's TCP/IP, or Excelan's
    EXOS TCP/IP card. The TCP/IP support includes a resolver for
    name-to-address translation and supports T_MX records.
 
o   RSCS using Jnet V3.0 or later. Supports MAILER and BSMTP format
    files inbound and outbound. Can function as a gateway as well as
    talk transparently to other gateways. [This code may port easily
    to Unix/URep].
 
o   MFEnet and SDSCnet using TELL protocol. Supports transfer of mail
    using either TELL protocol over MFE or SDSC protocols, including
    support for inbound ASCII attached files. Also supports use of
    BSMTP over the same transport to allow two Software Tools Mail
    sites to talk without the associated TELL braindamage.
 
Supported under Unix:
 
o   TCP/IP using SMTP protocol (either with or without header munging
    appropriate for an ARPAnet gateway). Supports one of BSD TCP/IP,
    NRC Fusion's TCP/IP (tested only under PC/AT Xenix), and Excelan's
    EXOS TCP/IP (tested only under Intel's Xenix). Where the host
    operating system supports a nameserver/resolver the Software Tools
    support includes an interface to it, and support for T_MX queries.
 
o   UUCP using /bin/rmail. [This code should port readily to VAX/VMS.]
    Also allows BSMTP-like transfer over UUCP circuits for
    communication without braindamage between two adjactent Software
    Tools Mail machines.
 
 
USER INTERFACES
===============
 
    The Software Tools Mail System provides its own user interface, a
Unix-like MSG and SNDMSG program. Additionally, it supports a
system-dependent user interface. Available under VMS are interfaces to
VMSmail, MFE/SDSC TELL, and SRI International's MM (under
development).  Available under Unix is the ability for STmail to write
the mail to the /usr/spool/mail/username file for a one-directional
interface to sendmail.
 
AVAILABILITY
============
 
    The Software Tools Mail System is public domain and available at
no charge.  It may be FTP'd via ARPAnet from host HAMLET.CALTECH.EDU
file ST_SRC:STC.BAK (Backup saveset /BLOCK=2048), COPYed via HEPnet
or SPAN from host HAMLET, or we can send it via BITnet /VMSDUMP
(please send your request to ADELMAN@LBL.BITNET).
 
SUPPORT
=======
 
    As with all other public-domain software from LBL, there is NO
guarantee of performance or support, implied or expressed.  Bug
reports, with or without fixes, are solicited; all reasonable attempts
to incorporate such fixes in future releases will be made.  Phone
calls concerning this software are discouraged, due to the interrupts
caused by such communication.  Every effort has been made to include
adequate documentation such that installation and maintenance will be
straightforward.  Correspondence about the system should be addressed
to me via the following addresses:
 
Kenneth A. Adelman              Adelman@Lbl.Bitnet
                                Adelman@Lbl.Gov
                                Lbl::Adelman [HEPnet]
                                Hamlet::Ken  [SPAN]
************************************************************************
DEC VAX/VMS - > ???? <
======================
 
            A DOMAIN BASED MAIL SYSTEM FOR VAX/VMS/JNET
            -------------------------------------------
 
        Vax/VMS sites on NetNorth (and on the rest of the RSCS network) have
not had decent mail systems in the past. They could not participate in the
domain based addressing scheme made possible with the Crosswell mailer on
VM/CMS. Many people have pointed out that PMDF is (or might be) adequate to
the task. There may be better solutions too.
 
        We would like to solicit participation in a mail system that we've
developed at Western which does conform to the protocols required of the
Crosswell mailer.  We have an effective tool for constructing the
administrative structure required by the domain naming structure. In Canada
CA registration is now under way.
 
        A brief description of what we've done follows.
 
        At Western we've developed a mail system for Vax/VMS in a Decnet
environment which takes advantage of a single JNET system as a bridge into
the RSCS world. We are working, at the moment, to integrate the system into
the cmu-tek tcp/ip environment.
 
         Mail systems which have attempted to preserve VAX/VMS mail are
limited by problems with VAX/VMS mail. If you've discovered already
the limitations of VAX/VMS mail and are looking for something better
perhaps we can help. (If you'd like to know more about "what's wrong with
Vax/VMS mail" let me know -- we have documented where the problems are.)
We decided a long time ago that VAX/VMS mail would not do what we want --
it's no where near RFC822. Further the "hook" methods of integrating into VMS
mail aren't at all simple or even promised as a continuing feature. Most of
the RFC822 functionality is missing (eg. Reply-to:, Sender:/From: distinction,
etc.)
 
Here's the organization of our present system. All code is written in C
and nothing is very difficult -- ie. if there's a simple way to do things
then that's what we've done.
 
The User Agent:
---------------
        Basically this is a BSD Mail derivative. It's a complete rewrite
though so there are (or should be) no licence hassles. We construct only RFC822
addresses, honor RFC822 headers (including From:, Sender:, To:, Cc:, Bcc:,
Reply-to:, Return-Receipt-to:, etc.) and the Resent- variants, implement
a good foldering system, allow for user and system defined aliases, mail is
tailorable with "set" commands, honors UAF information (like you cannot
use mail), allows for autoforwarding when you're away, lets you "record"
what you say, lets you automatically append a "signature" file, allows full
access to DCL, lets you define your favorite editor (eg. emacs), has a "naive"
setting to help first time users, and many other features. This is a complete
mail system as good as if not much better than the Dec product.
 
        Users have a sys$login:mail.box which is just a plain text file.
Messages are separated from one another by key-word headers that say, for
example:
 
        Contents: 4 pages, 20 lines, 2458 characters
        ...message text is 4 pages, 20 lines, 2458 characters
        Unread: 1 page 40 lines, 30409 characters
        ...etc.
 
We recognize a distinction between new mail, read mail, and unread mail using
different keywords. These key-word headers break the mail.box into a
sequence of messages. Messages are sucked into VM when you run mail (we
found fseek, etc. tooooo slow on vax's) unlike BSD mail. New mail is auto-
matically encorporated into your sessions as it arrives. Switching folders
during a session is trivial.
 
        User Agent communicates to the Message Transfer Agent by writing
BSMTP messages into SYS$MAIL:MAIL.BSMTP and waking the sleeping daemon who
is just known as "MAIL-DAEMON". This works nicely with JNET because that's
how they want to implement the function for mail coming in off the net --
write a file and wake a daemon. The communication between MTA and UA is
obvious -- the MTA appends the appropriate text to sys$login:mail.box
 
The Message Transfer Agent:
---------------------------
        The mail daemon is modelled after the Crosswell mailer on VM/CMS.
The daemon runs as a detached job waiting to be awakened and processes
the "que" of SYS$MAIL:MAIL.BSMTP files (using version numbers we get a
stack, but that's ok). You can see that we needed to develope a "BSMTP"
parser -- that was stage one, we're now doing SMTP parsing over Decnet
sockets. The daemon is configured at startup by a configuration file
detailing some time-out values, sleep values, etc. and a set of
"delivery" rules. This is exactly like the Crosswell mailer.
 
        The daemon is table driven with various exit functions implemented.
Delivery to an address consists of doing a simple pattern match and invoking
the appropriate function. Each function can be passed a string value
argument. For example there's a table entries saying
 
*@uwovax.UWO.CDN        local(NULL)                   !no argument
*@chris.uwo.cdn         decsmtp(chris::"152=")        !host, socket arg.
*@*.BITNET              tomailer(MAILER@UWOCC1)       !argument
etc.
 
So we have several functions for delivering mail:
 
local(NULL):
        local delivery, honors SYS$LOGIN:MAIL.FORWARD file (a bit like
        sendmail's .forward file but looks for entries "name: address"),
        honors UAF information (where's this guys's sys$login? can he receive
        mail? should I beep? etc.) honors "return-receipt-to:" field (like
        sendmail).
 
        for addresses not in the UAF we use a SYS$MAIL:MAIL.FORWARD file
        a bit like the sendmail alias file. This is cached in memory (we
        have a name registry of about 2000 names!) and refreshed as
        required. With this system people mail to name@uwovax.BITNET and
        the mail gets forwarded on to non-BITNET machines (given that
        name is in the mail.forward file).
 
to_mailer(MAILER@MACHINE):
        construct a BSMTP file and do a lib$spawn of
 
                send/file/notruncate file MAILER@MACHINE
 
        this is the BSMTP protocol required of Crosswell mailers on BITNET.
        We get rid of a lot of our mail by this exit punching to our
        mailer on UWOCC1.BITNET (which is our primary BITNET gateway).
        But, using this exit, you can communicate directly with any of
        the BSMTP gateway machines on the network.
 
        For the domain naming system to work you need to have this function.
 
to_user(MACHINE):
        construct the RFC822 message and do a lib$spawn of
 
                send/file/notruncate file "user"@machine
 
        this is for the stupid IBM guys who want the mail punched directly.
        It's also for VMS guys who run vanilla JNET software.
 
dec_smtp(machine::"socket=")
        talks SMTP over decnet to a similar daemon. This is pretty simple
        to do and relies on the ability to do fopen("w+","host::\"socket=\"").
        Any I/O unit managed by stdio.h is a possible smtp socket for us.
        Time outs are implemented (around here 60 seconds seems fine). We are
        using this to talk to other VAX's with this mailer AND to Ultrix 1.2.
 
        One feature here is that we do store-and-forward, if Decnet is down
        we spool the message away in a "defer" queue which the daemon retries
        every half hour (the time can be tailored in the configuration
        file).
 
Adding other functions (and there are ones like "error" that I've not
described) is really simple. We're working to add tcpip SMTP support since
we believe that IP and not Decnet or RSCS will provide the open network
environment.
 
The SMTP daemon:
----------------
        The daemon executable is installed as a decnet object and when
        started up (say by another daemon on the decnet) the daemon
        determines that it's an SMTP daemon (it's running in netmode) and
        talks SMTP over SYS$NET. Error codes are used in the conversation
        when, for example, and address is undeliverable and these are used
        by the partner. The received message is spooled as SYS$MAIL:MAIL.BSMTP
        and the sleeping daemon is awakened to do the delivery.
 
        One sneaky trick I've done here solves a Ultrix 1.2 problem --
        Ultrix 1.2 has data overrun problems on both decnet and on
        tcp/ip. My SMTP daemon recognizes the BSMTP VERB command so I
        can get a stop and wait protocol with VERB ON so each line of
        the message is echoed by "050 OK", this shouldn't be required
        but works given the Ultrix bug.
 
Solicitation:
-------------
        We're looking for sites who'd like to try using this system and seek
very little in return. We'll give out full sources so that you can tailor
things to your liking (this really shouldn't be necessary) but we require that
you communicate your enhancements back to us. Ownership of the system remains
with us but you are free to distribute the system further provided that the
ownership issue remain clear.
 
If you are interested in getting a copy of our work, please contact me as
---
Telephone:    (519) 661 2151 x6026 (a real person and not a machine)
Canada:       reggers@UWO.CDN (soon to be UWO.CA)
BITNET:       reggers@uwovax.BITNET (for the ethnocentric)
UUCP:         reggers@julian.UUCP (...!watmath!julian..)
************************************************************************
DEC VAX/VMS - > PMDF <
======================
 
                  INFORMATION ABOUT PMDF-822 V2.3
 
                             Ned Freed
                            27-Oct-1986
 
The Pascal Memo Distribution Facility (PMDF)  is  a  general-purpose
system  for delivering computer-based mail.  PMDF provides a uniform
distribution environment that can be  interfaced  to  multiple  user
interfaces  and  transport  mechanisms.   This  version  of PMDF for
VAX/VMS, called PMDF-822 V2.3, uses the standard VMS  MAIL  facility
as  its  user  interface  and  provides  support  for  the  PhoneNet
asynchronous dialup protocol as its primary transport mechanism.
 
PMDF-822 V2.3 also  supports  DECnet,  DECnet-based  MAIL,  JNET  (a
product  of Joiner Associates Inc., this is an implementation of the
IBM RSCS networking system for VAX/VMS),  SMTP  over  TCP/IP  (using
either the Tektronix or the Wollongong implementations for VAX/VMS),
SMTP over  an  arbitrary  I/O  channel,  and  PSIMail  as  transport
mechanisms.
 
PMDF-822 is used to perform the PhoneNet function of NSF's CSNET  on
VAX/VMS  systems.  PMDF's interface to JNET provides a powerful MAIL
interface to the RCSC-based BITNET network.
 
PMDF is a subset of the  Multi-channel  Memo  Distribution  Facility
(MMDF), developed by the Department of Electrical Engineering at the
University of Delaware.   MMDF  is  available  on  all  4.3BSD  UNIX
systems,  so  PMDF can be used to transfer messages from VMS systems
to UNIX systems over arbitrary terminal line connections.
 
PMDF is fully compliant  with  the  address  conventions  of  RFC822
('domains'),  the standard for the format of Internet text messages.
SMTP support in PMDF complies  with  RFC821  (Simple  Mail  Transfer
Protocol).
 
PMDF was developed by Ira Winston of the Department of Computer  and
Information  Science at the University of Pennsylvania, Ned Freed of
the Department of Mathematics at  Oklahoma  State  University,  Mark
Vasoll  of  the  Department  of Computer and Information Sciences at
Oklahoma State University, John Carosso of Harvey Mudd College,  and
Kevin  Carosso  of  the  Space  and  Communications  Group of Hughes
Aircraft.
 
PMDF is distributed by CSNET to its members.  Organizations who  are
not  members  of  CSNET  can  obtain  copies  of PMDF for a $50 (US)
distribution fee from:
 
                    Ned Freed (ned@ymir.bitnet)
                    The PMDF Project
                    Computing Services
                    Harvey Mudd College
                    Claremont, CA 91711
                    (714) 621-8006
 
Please make checks payable to PMDF  Project,  Harvey  Mudd  College.
 
 
 
 
 
 
 
 
 
                                                                Page 2
 
 
The  standard  distribution  contains  a  tape  (a  9-track 1600 BPI
magtape written in VMS BACKUP format) and about 100 pages of printed
documentation.   Please  indicate  if  your site is using Wollongong
TCP/IP; support  for  Wollongong  TCP/IP  can  only  be  shipped  to
properly licensed sites.
 
The distribution includes the complete Pascal source and executables
for  PMDF,  PhoneNet  and  the  various interfaces to other tranport
mechanisms.  It does not include code for the  transport  facilities
themselves  such  as  JNET,  DECnet  or  TCP/IP;  these are separate
licensed software products available from other vendors.
 
PMDF may be installed on as many systems  as  desired  at  a  single
site.   Redistribution  of  PMDF to other sites is prohibited.  PMDF
will not be distributed and is not  available  via  network  FTP  or
Internet MAIL.
 
There is a PMDF mailing list to be used for  discussing  PMDF  bugs,
features  and  futures.   Simple  bug  fixes  and  enhancements  are
distributed via the list.  Please send requests to be placed on  the
list  to  rpmdf@ymir.bitnet.   Submissions  to  the  list  should be
directed to ipmdf@ymir.bitnet.  Queries for information  about  PMDF
should be directed to qpmdf@ymir.bitnet.