A105@UWOCC1.BITNET (Brent Sterner) (11/03/86)
WOW! I was deluged with requests. Pardon this mailing if you've
already received a direct reply, but I'd like to head this one off at
the pass. I'd rather not spend a lot more time sending out individual
copies. If you would like more information, please contact Reg Quinton
(not me) since he is the primary wizard in this area. Brent.
................................................................
From: Reg Quinton <111_362@uwovax.UWO.CDN>
To: mail_project@uwovax.UWO.CDN
Date: Tue, 28 Oct 86 12:13:43 EST
Subject: VAX/VMS[/DECNET[/JNET]] Mail project at Western
Message-id: <0530885623@uwovax.UWO.CDN>
To all and sundry who replied to me as a362@uwocc1.BITNET regarding Brent
Sterner's cryptic comment to info-vax that we at Western were working on a
project to develop a RFC821/22 Mail system .... you have not been forgotten.
Although it has taken me a very long time to get back to you, sorry.
To the fellow who offered his first born son .... thanks, but I think there
are probably laws against that.
To the people at Weslyan (sp?) and elsewhere who are working on similar
projects, let me know if you think the following is off the mark.
Some brief comments to let you know what we've been up to and where we stand.
We'd like to send out a beta-test distribution (and probably will to a couple
of neighbors) but cannot send out to the many people who responded... Sorry,
perhaps by Jan. '87 we'll be in a better position.
What are we doing? ... In brief we've ported a version of Kurt Shoen's Mail
program (the version we've ported is very far removed from the Berkeley
distribution ...). As well we've implemented a simple MAIL-DAEMON which runs
as a detached job (under an ordinary user account). MAIL-DAEMON's are proxied
together on the DecNET and submit BSMTP messages to one another by writing to
simple tasks which 'suck in the message' and 'wake' the daemon. (Note that this
is considerably different from the VAX/VMS Mail strategy which requires that
you a) have Decnet priviledges (here the daemon needs it but the users doesn't)
and b) that a circuit be established to the remote mail box). Likewise Mail
communicates to the daemon by writing a file and waking the daemon (the
communication here is also via BSMTP messages). So also is the protocol to
JNET -- JNET writes the required file and wakes the daemon. (We communicate
with the RSCS world through MAILER@UWOCC1 although we have enough exits that
we could communicate directly with anyone on the RSCS net... but we'd rather
the interface to Western be at one machine... this machine may replace the IBM
though and we'd have to communicate with everyone directly then).
The MAIL-DAEMON is usually in a hibernate state waiting to be awakened (by
a remote daemon or Mail as noted above) or for an alarm to ring. When the
DAEMON awakens he first spawns an "OFTEN.COM" task --- typically we put in
here resubmission of messages queued because of DECNET down, and (if you want
to support VAX/VMS mail) dequeuing of any VMS/MAIL (more on this latter).
Then the MAIL-DAEMON tries to get rid of any messages that have been queued
for him (by remote daemons, by local Mail, by even JNET). The queue is simply
implemented by VAX/VMS version numbers (so the DAEMON cycles processing a
file called "MAIL.BSMTP" until such time as there are none left). Determining
who a message is for is simple given the BSMTP protocol. The disposition of
messages is table driven (although the table is, at the moment, compiled in
as a seperate file). The table is a lot like Crosswell's (at least in spirit)
consisting of a "pattern" (eg. "*@uwovax.*" with '*' as a wild card), an
exit function (eg. local, jnet-direct, jnet-mailer, bsmtp, vmslocal), and a
string parameter. For example, one might have an table entry saying
"*@*.CDN", jnet-mailer, "MAILER@CANADA01"
to specifiy that mail for the CDN domain should be processed by the "jnet-
mailer" exit, with the string "MAILER@CANADA01" as a parameter. ie. send a
BSMTP message to the indicated MAILER on the RSCS network using JNET. We have
implemented only a very few functions (which meet our needs) but others could
be added with minimal fuss.
We *do not* implement the strategy of MAILING an RFC822 message to a MAILER;
the terrible :mailer.MAILER BITNET exit implemented by the Columbia mailer.
This is a really bad one and I'm afraid that some of the people on the mail
explosion are not going to get this message because they want that kind of
guff...
Everything is written in 'C' (I'm the local Unix wizard and have just gotten
'into' VMS) and ought to be pretty simple to maintain. We don't do any
fork/exec, instead we do system("command") and have implemented this using
LIB$SPAWN. We're also not doing any racy tty stuff (no glossy screens,
reverse-video, etc.) although we do signal trapping. On-line help is
implemented by spawning the help system.
System stuff (where people sometimes get scared)
a) we define some logicals
sys$mail (the daemon's directory)
sys$mail_name (the system name eg. uwovax.UWO.CDN)
b) we install some programs
sys$mail:daemon (This guy needs basically "SYSTEM" priviledges so he
can read the UAF, write to people's directory, change file ownership,
exceed quotas, use Decnet, write to your screen, etc.)
sys$mail:waker (this guy needs to be able to wake the daemon, at the
moment our UA has no priviledges to do this (or much of anything else).
this likely will disappear when we're confident about the UA).
sys$mail:forger (well, if you like to support VMS mail you'll need
this.)
c) we modify the system startup.com to include mail_startup.com which
defines the logicals, installs the programs, and submits a batch job
under the DAEMON user id (at our site it's user MLNET). This job then
shoves the required stuff at loginout.exe to get a detached job going
under user MLNET (hence the batch) with a DCL (hence the loginout.exe)
--- the DCL is required so he can do LIB$SPAWNS. If you trusted this guy
you could avoid installing the daemon.exe by just doing the loginout.exe
and avoid the batch. That would give you user SYSTEM (who has lots of
priv's) as the DAEMON-- but this is dangerous 'cause you proxy them
together.
d) small mod to the JNET source (a one page program) to make sure that
BSMTP messages to the DAEMON get written to the right place and that
the DAEMON gets awakened (if you're using JNET you need to make sure that
your DAEMON is at least in the same group as JNET... this is usually the
SYSTEM group... scary I know!)
Mail Design (the UA)
As noted above this is a port of Kurt Shoen's program so the user from
Unix land sees something very familiar. We rely on the C argument parsing
so when installed as a foreign command (at the moment we call ours
"xmail") you can say..
$xmail help (we'll put the help library into the system when we
formally decomission VAX/VMS mail).
$xmail (to check your mail/read your mail)
$xmail user user ... (to send mail)
$xmail -s subject user user .. (to send mail and set the subject)
$xmail -f (to read your default folder)
$xmail -f foo.bar (to read your foo.bar folder)
There's tons of deviations from the original program, some intended to make
the move from VAX/VMS easier. The major deviations are:
MAIL.BOX resides in the user's login directory formatted as RFC822 messages
seperated by lines saying
Contents: x pages, y lines, z characters
i.e. we don't have the silly "From user date remote from host" format
and don't need to alter any of the contents of the message, in particular
no need for the silly ">From ..." lines.
UAF control -- some users can be refused access to mail in the UAF, we honour
this control. (seems like a nice idea since I occassionally see slanderous
messages.)
MAIL.FORWARD since it's processed by the DAEMON is expected to contain fully
qualified addresses in a syntax
userid: address [,address...]
(The userid is required since different ones can map to the same directory,
eg. I am also the postmaster).
The syntax allows for simple mailing lists... you're getting this note
because of such an expansion on the SYS$MAIL:MAIL.FORWARD file (this is
a bit like the "aliases" of 4.2BSD).
Construct RFC 822 dates, Reply-to, Return-Receipt-to (actually this one is
only recognized by sendmail Unix guys).
The UA constructs fully qualified addresses (since the DAEMON doesn't do any
munging) and makes no assumptions about a network configuration. We
prefer the "comments <address>" construction
The "set" command is used for all sorts of interesting things...
set name="Reg Quinton" !to define my name in the From:
set editor=eve !to define an alternate editor
set pagesize=20 !display is "paged" to user
etc.
Racy terminal stuff to allow one to edit a header line is not implemented.
Since the version of Mail we worked on was a *very* old one (it ran on an
11/34 and came from a 2.8 distribution tape so it's from about 1980). There's
a few commands we haven't implemented ... ignore and folder being the most
important ones. But we'll probably put these in.
The communication between UA and MTA is pretty simple ... no fork, exec but
instead the writting of a file and the waking of a daemon.
VAX/VMS mail....
Well, I'm not too keen about this one but we do provide some minimal support
without getting our hands too dirty... i.e. we didn't want to get into the
infamous "exit%blah.blah.blah" stuff. Instead, we rely on the fact that
VMS/MAIL will let you type..
$MAIL
MAIL> Send
To: USER!blah blah blah
Likewise if you receive using VAX/VMS mail a message saying it was
From: USER!blah blah blah
Typing a reply will construct the same kind of thing that the send did above.
Given this observation we provide a minimal interface to VAX/VMS mail (although
we'll pull this shortly). User MLNET is the "USER" mentioned above and this is
the account the DAEMON runs under.
Getting mail out of VAX/VMS world... people mail to MLNET!address. Daemon, in
the often.com sequence, empties his mail box munging VAX/VMS messages into the
BSMTP queue.
Getting mail into the VAX/VMS world... daemon does a spawn to MAIL a file to
the user and run the forger to modify the header. The spawned task takes care
of any NAKs.
BUT...you have to wait for the daemon to wake up, doesn't handle multiple
recipients, forwarding (given the forger) doesn't work very well (you get
the forwarded message but the forger doesn't get to forge the From:), you
can't forward out of DECNET, you need a silly address syntax, you can't
use the silly address syntax on the DCL line, etc. etc.
Limitations/Problem areas:
1. At the moment the UA runs non-priviledged, to write into the DAEMON spool
area we leave it writable by the world (well we could give the UA priv's
and push them up and down as needed).
2. By RFC821 I really mean BSMTP as implemented on the RSCS net --- i.e.
rather than a synchronous communication as in SMTP we just 'batch' up
an SMTP dialogue and let the recipient DAEMON take care of things. A
DAEMON who receives a BSMTP message is on his own, ... ie. he must deliver
and/or return NAK if required. A BSMTP message which isn't gets flogged to
the local postmaster.
3. By RFC822 I really mean
comment <user@host.domain>
(comment) user@host.domain
ie. I do not implement "routing" of the form <@host,@host:user@host>. Well
one can handle these within the framework implemented but I don't.
4. I don't allow for addresses which 'split' lines,
eg. From: I am not a crook
Nixon@disgrace
5. I'm not too keen about quoted fragments either ...
eg. From: I am not a crook <"Richard Nixon"@disgrace>
well this could easily be handled but since not too many can handle it,
why bother?
6. My UA implements From:, Reply-to:, Bcc:, Cc:, Return-Receipt-to: and
recognizes the Resent- variants. (Note I don't construct any Resent-
and I don't do any Sender: stuff).
7. The DAEMON doesn't honor Return-Receipt-to: when making local delivery...
this is easy to add and will likely be done soon.
8. The JNET exits simply spawn a DCL command... I really need to analyze the
output from the command to make sure that the host was valid. This isn't
a problem (yet) at our site since we interface to the RSCS net by talking
with our MAILER@UWOCC1.BITNET
9. The JNET inbound interface should really do some authorization checks..
ie. is the sender really an authorized mailer?
10. Profs/notes/etc. As far as I'm concerned these aren't mail.. My JNET
interface will pull them in and preface them with a proper mail header.
NOTE I do not munge them! And I never will... these guys should be
discouraged (if not beaten over the head).
11. I need a program to create the table from the NAME(s) files.
12. I'd like to be able to mail to files and processes.
Problems, comments, questions, etc. can be directed to my address (in
the Reg Quinton 'From:').