|
|
1.1 root 1: .SH
2: The MMDF File Hierarchy
3: .PP
4: The MMDFI queue structure consisted of three directories.
5: The ``msg'' directory contained the files containing actual
6: message text.
7: The ``addr'' directory contained the address list file for each
8: message, and the ``tmp'' directory contained the address list
9: while it was being created before moving it to the ``addr''
10: directory.
11: The names of the files in ``msg'' and ``addr'' were identical
12: although the contents differed.
13: This made it easy to find
14: the companion file given either filename.
15: The MMDFII queue structure has changed in one major way from that
16: of MMDFI.
17: There is now one extra directory per channel named q.\fIchannel\fR.
18: If an address list still has any addresses destined to be sent
19: on any channels,
20: then a link will exist from the address list
21: file in ``addr'' to a file with the same name in each queue directory
22: which is referenced.
23: All the above directories usually live in /usr/mmdf/lock/home,
24: although the
25: root name of this tree can be changed.
26: The lock directory is kept in 700 or 770 mode, accessible only to
27: the ``mmdf'' user and possibly a ``systems'' group for
28: ease of maintenance.
29: The ``home'' directory and all the underlying queue directories are
30: kept in 777 mode to allow ease of movement and access for the trusted
31: but unprivileged programs that operate there.
32: In particular, the \fBsubmit\fR process is setuid to ``mmdf''
33: to allow it to
34: enter the tree, but it then restores
35: its UID and GID to those of the invoker.
36: \fBDeliver\fR and the channel programs normally run as the ``mmdf'' user.
37: Only the local channel, which must access the real user's mailbox files,
38: and the TCP/IP network daemons, which must access privileged sockets,
39: need run privileged. There are several other programs that are
40: setuid to ``root'', but only so they can change their UID to ``mmdf''
41: so as to to be a ``trusted submitter'', which allows them to specify
42: an arbitrary From: line.
43: .PP
44: The addition of the separate queuing directories on
45: a per channel basis was a valuable change.
46: UNIX performs poorly with large directories,
47: as any UUCP backbone site can tell you.
48: This new mechanism allows easy
49: partitioning of channel activities into separate directories, since
50: \fBdeliver\fR will never access the copy of the address list in the ``addr''
51: directory until it goes to finally expunge the message from the queues.
52: If one channel or site gets backed up, it does not affect the performance of
53: any of the other channels.
54: .PP
55: The format of the address lists has changed somewhat since MMDFI.
56: The old format was:
57: .in +1i
58: .sp .6
59: S T channel-name host-on-channel address-at-host
60: .in -1i
61: .sp .6
62: where S was either a `\-' indicating unsent or a `+' indicating that
63: only the address but not the text had been sent.
64: The T was either the type of delivery
65: (almost always `m' for mail) or a `*' indicating the message has been
66: completely delivered. The channel-name and host-on-channel should be
67: obvious. The address-at-host parameter was only the local part of an
68: address.
69: The new version differs in two ways. First, the host-on-channel is now
70: the full domain address of the host to deliver to, as specified in the
71: routing information of the domain table.
72: .FN
73: See the manual section on the MMDF database (queue.5) for more information.
74: .FE
75: Second, the address-at-host is now the full address with
76: both the local-part and the domain specifier.
77: .PP
78: In the future, I will probably change the location of the ``message
79: completely delivered'' flag to be in the first position (S), since
80: I feel it was a mistake to not have it there in the past and it is
81: confusing in its current position.
82: This has not been done as of February 1985.
83: .PP
84: The MMDF file hierarchy also has a logging directory. Separate
85: logs are kept here for \fBsubmit\fR and \fBdeliver\fR,
86: the channel programs,
87: and the phone dialing package. This directory is generally
88: accessible although unreadable and the logs are normally write
89: only. This could be made ``mmdf'' access only for some sites, with
90: the only penalty being that some programs would be unable to add
91: entries to the log.
92: A subdirectory of the log directory called ``log/phase'' contains
93: time stamp files whose modification times are changed by \fBsubmit\fR
94: and \fBdeliver\fR to indicate such things as last pickup time, last
95: delivery time, last poll made, and similar information.
96: .PP
97: There are two other directories in the MMDF hierarchy which
98: should be mentioned. The ``chans'' directory contains
99: all of the channel programs invoked by the \fBdeliver\fR program,
100: and other ancillary daemon programs such as the SMTP daemon
101: and the SMTP server. The ``table'' directory contains
102: all files necessary to maintain the MMDF database,
103: including domain tables, host address files, mailbox
104: alias files, dialing scripts, and programs to build these
105: files and incorporate them into the DBM library.
106: .FN
107: The DBM package is a set of simple hashed database access routines
108: that were distributed with V7 Unix and are still widely used.
109: .FE
110: .PP
111: Use of some sort of keyed database system is almost essential for large
112: MMDF systems, since the table lookup overhead is unbearable
113: otherwise. Currently DBM is the only readily available alternative
114: and it does seem to work well, but it is running out of steam,
115: particularly due to its limited record length. A more
116: flexible replacement for
117: this package would be welcome.
118: .PP
119: The top of the MMDF directory tree contains the directories mentioned
120: above, the \fBsubmit\fR and \fBdeliver\fR
121: programs, and a few maintenance programs.
122: If the site is polled for PhoneNet mail then the ``\fBslave\fR''
123: program is normally
124: also located here. The \fBslave\fR
125: program is used as the remote site's login
126: shell and acts much as \fBuucico\fR in managing the
127: link level communications.
128: It in turn calls upon \fBsubmit\fR and \fBdeliver\fR to send and receive mail.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.