![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to p8 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ucs / mmdf|
Return to p8 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ucs / mmdf |
1.1 root 1: .SH
2: The BBOARDS Channel
3: .PP
4: Sites that run the MH message system, version mh.5, may install
5: a \fIbboards\fR channel which delivers messages
6: from interest-group mailing lists to a special ``bboards'' directory .
7: The bboards software,
8: which is compatible with the MH message system, keeps track of which
9: messages have been seen by individual users, and allows designated bboards
10: managers to control the size and access for different bboards.
11: .FN
12: See the \fIman\fR entry mh-gen.8 in the MH distribution.
13: It is important to note that the choice to install ``bboards''
14: must be made when MMDF is generated. The ``news'' facility mentioned
15: in the MH documentation is not supported by CSNET.
16: .FE
17: .SH
18: The UUCP Channel
19: .PP
20: The task of integrating UUCP mail into MMDF was a prime
21: goal for BRL.
22: Our users would not tolerate having to use
23: two radically different mail interfaces for two different
24: kinds of mail connections.
25: We decided to write a channel to interface to the UUCP
26: mail world that would take care of the necessary format
27: conversions to allow mail to traverse the two mail worlds.
28: The channel has two parts. The input portion of the channel
29: is the program \fB/bin/rmail\fR which is executed by the UUCP
30: program \fBuuxqt\fR when mail is being delivered.
31: The output portion is a standard channel that invokes the UUCP
32: system after reformatting the message.
33: .PP
34: The \fBrmail\fR
35: program has been totally rewritten to interface to MMDF.
36: \fBRmail\fR's primary task is to collect and reformat the
37: address strings in the message.
38: To reformat each address, \fBrmail\fR uses the UUCP channel table
39: to determine what hosts are known to this host and shortens
40: an host!host!host! string down to the single most distant host we know
41: about and any subsequent hosts we do not know. For example
42: knownA!knownB!knownC!unknown1!unknown2!user would become
43: knownC!unknown1!unknown2!user.
44: It then converts this to an RFC822 style address by putting the unknown
45: hosts and the user in the local part and putting the known host with
46: a domain in the domain portion, e.g. [email protected].
47: If all the hosts are known, then only the user
48: is left in the local part, and the address winds up being [email protected].
49: Since you always know the hosts you talk to, you can build any arbitrary
50: UUCP path by simply saying [email protected].
51: .PP
52: \fBRmail\fR is prepared to accept destination addresses in two forms.
53: If the addressee is just another UUCP host addressed using host!host!...
54: notation, then \fBrmail\fR forwards the letter via UUCP without header munging
55: since the destination host may not support RFC822 style mail.
56: An addressee of the form user@domain will
57: cause the message to be fed to \fBsubmit\fR and into MMDF proper
58: where the message can be delivered to another UUCP site or any other site
59: accessible via MMDF.
60: \fBRmail\fR will reformat the message header in the latter case to conform
61: as much as possible with the RFC822 specifications.
62: .PP
63: The outbound portion of the UUCP channel is a MMDF channel program called
64: ``uucp'' which is invoked by \fBdeliver\fR.
65: The job of this program is much
66: easier since all it must do is reformat the ``From:'' line to be compatible
67: with UUCP mail.
68: The outbound channel must also reformat the destination addresses
69: which become arguments to \fBuux\fR.
70: The outbound channel uses the same channel table that
71: \fBrmail\fR used but performs the reverse action on the address so,
72: for example, [email protected] becomes unc!duke!mcnc!root and this is
73: then further divided to form the uux command
74: ``uux unc!rmail duke!mcnc!root'' (assuming the channel table maps
75: mcnc.UUCP into duke!unc!mcnc).
76: .PP
77: The UUCP channel would have to be classed as the only ``flakey''
78: portion of MMDF since some of these address transformation really need
79: an advanced AI system to make an intelligent transformation.
80: In general, though, the channel does a very good job and has little trouble
81: with ``normal'' UUCP addresses.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.