.SH
The BBOARDS Channel
.PP
Sites that run the MH message system, version mh.5, may install
a \fIbboards\fR channel which delivers messages 
from interest-group mailing lists to a special ``bboards'' directory  .
The bboards software,
which is compatible with the MH message system, keeps track of which
messages have been seen by individual users, and allows designated bboards
managers to control the size and access for different bboards.
.FN
See the \fIman\fR entry mh-gen.8 in the MH distribution.
It is important to note that the choice to install ``bboards'' 
must be made when MMDF is generated.  The ``news'' facility mentioned
in the MH documentation is not supported by CSNET.
.FE
.SH
The UUCP Channel
.PP
The task of integrating UUCP mail into MMDF was a prime
goal for BRL.
Our users would not tolerate having to use
two radically different mail interfaces for two different
kinds of mail connections.
We decided to write a channel to interface to the UUCP
mail world that would take care of the necessary format
conversions to allow mail to traverse the two mail worlds.
The channel has two parts.  The input portion of the channel
is the program \fB/bin/rmail\fR which is executed by the UUCP
program \fBuuxqt\fR when mail is being delivered.
The output portion is a standard channel that invokes the UUCP
system after reformatting the message.
.PP
The \fBrmail\fR
program has been totally rewritten to interface to MMDF.
\fBRmail\fR's primary task is to collect and reformat the
address strings in the message.
To reformat each address, \fBrmail\fR uses the UUCP channel table
to determine what hosts are known to this host and shortens
an host!host!host! string down to the single most distant host we know
about and any subsequent hosts we do not know.  For example
knownA!knownB!knownC!unknown1!unknown2!user would become
knownC!unknown1!unknown2!user.
It then converts this to an RFC822 style address by putting the unknown
hosts and the user in the local part and putting the known host with
a domain in the domain portion, e.g. unknown1!unknown2!user@knownC.UUCP.
If all the hosts are known, then only the user
is left in the local part, and the address winds up being user@known.UUCP.
Since you always know the hosts you talk to, you can build any arbitrary
UUCP path by simply saying arbitrary-host-path@neighbor.UUCP.
.PP
\fBRmail\fR is prepared to accept destination addresses in two forms.
If the addressee is just another UUCP host addressed using host!host!...
notation, then \fBrmail\fR forwards the letter via UUCP without header munging
since the destination host may not support RFC822 style mail.
An addressee of the form user@domain will
cause the message to be fed to \fBsubmit\fR and into MMDF proper
where the message can be delivered to another UUCP site or any other site
accessible via MMDF.
\fBRmail\fR will reformat the message header in the latter case to conform
as much as possible with the RFC822 specifications.
.PP
The outbound portion of the UUCP channel is a MMDF channel program called
``uucp'' which is invoked by \fBdeliver\fR.
The job of this program is much
easier since all it must do is reformat the ``From:'' line to be compatible
with UUCP mail.
The outbound channel must also reformat the destination addresses
which become arguments to \fBuux\fR.
The outbound channel uses the same channel table that
\fBrmail\fR used but performs the reverse action on the address so,
for example, root@mcnc.UUCP becomes unc!duke!mcnc!root and this is
then further divided to form the uux command
``uux unc!rmail duke!mcnc!root'' (assuming the channel table maps
mcnc.UUCP into duke!unc!mcnc).
.PP
The UUCP channel would have to be classed as the only ``flakey''
portion of MMDF since some of these address transformation really need
an advanced AI system to make an intelligent transformation.
In general, though, the channel does a very good job and has little trouble
with ``normal'' UUCP addresses.