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 . * ************************************************************************ 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.