home *** CD-ROM | disk | FTP | other *** search
- .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.
-