|
|
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.