reggers@julian.UUCP (12/01/87)
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..)
--
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..)