![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to p2 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 p2 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ucs / mmdf |
1.1 root 1: .SH
2: The MMDF Design
3: .PP
4: The MMDF system design has not changed fundamentally
5: from the original design proposed and implemented for MMDFI.
6: The design of MMDFI is covered in detail in the paper
7: ``An Internetwork Memo Distribution Capability''.
8: .FN
9: D. Crocker, E. Szurkowski, and D. Farber,
10: ``An Internetwork Memo Distribution Capability'', Datacom Conference,
11: September 1979.
12: .FE
13: In this chapter, I will summarize the basic design and discuss
14: those changes that have been made in MMDFII.
15: .PP
16: Mail software is normally classed into one of two groups.
17: A user agent (UA) is a program
18: that is responsible for providing a ``user friendly'' interface
19: for reading or writing mail and converting to the canonical
20: interface of the mail transfer agent as necessary.
21: A mail transfer agent (MTA) is a program or system
22: to which you or your user agent entrusts a message for delivery
23: to someone else's user agent.
24: There has been a great deal of confusion caused by people who
25: fail to realize the difference between a mail transfer agent and
26: a user agent, or even that a difference exists!
27: There is a wide variety of user agents which can be used with
28: MMDF, and it is the responsibility of the use agent to provide a user interface.
29: This separation of the functions of user agent and mail transfer
30: agent has many advantages, not the least of which is that MMDF
31: can support many different user interfaces with ease.
32: Currently, there are at least five different interfaces available
33: including the Rand MH system, V6 style mail, Berkeley's Mail (cap-mail),
34: the Tenex-style Send and Msg programs, and Rmail (for UUCP).
35: MMDF is a mail transfer agent.
36: MMDF does not have, nor does it claim to have, a good ``user interface'';
37: instead it has a good program (MTA-UA) interface.
38: MMDF accepts messages for delivery either locally or to a remote
39: site. It attempts to verify the validity of the addresses at submission
40: time to the extent possible given only a host table and a list of
41: local addresses. If accepted, it will continually try to resend the
42: message until the retry time is exhausted at which time
43: the message is returned to the sender.
44: .PP
45: The MMDF system can be thought of as two subsystems, responsible
46: for mail submission and mail delivery, respectively.
47: Between these two halves is the mail queue.
48: The mail queue will be discussed later, but basically it stores each
49: message as two files, an address list with some control information, and
50: a separate file containing only the message text (header and body).
51: .PP
52: The submission half of the system consists mainly of one program,
53: called ``\fBsubmit\fR'', which is responsible for enqueuing mail to be
54: delivered. As much verification as possible is performed on the
55: message at
56: submission time.
57: For mail destined for the local machine, this means making sure the
58: destination account exists, and that any local mailing list or aliases
59: expand properly.
60: For mail that has a non-local host specification, the \fBsubmit\fR
61: process checks to see if it knows how to reach the specified host.
62: Mail which for any reason is known to be undeliverable, is not accepted
63: for delivery.
64: \fBSubmit\fR is called by two types of processes. The first group includes
65: user agents such as the \fBsend\fR program. The second group
66: comprises channel
67: programs such as \fBrmail\fR
68: .FN
69: The \fBrmail\fR program (/bin/rmail) is
70: invoked by uucp when delivering mail
71: on your system.
72: .FE
73: which are interfacing to remote mail transfer agents.
74: .PP
75: The delivery portion of MMDF is represented by two main elements: the
76: \fBdeliver\fR program which manages the queue, and
77: the channel programs which handle the details of
78: delivery to a specific network, host, or mail system.
79: The \fBdeliver\fR program takes each message which is eligible to
80: be delivered, and opens the appropriate address list. For each address
81: in the list, \fBdeliver\fR ensures that it is running the appropriate channel
82: program and then passes the envelope information
83: .FN
84: The MMDF envelope information consists of the the
85: return address, the destination addresses, some delivery options and
86: a reference to the message text file.
87: .FE
88: to the channel. A reference to the file containing the actual
89: message text is passed to the
90: channel program. The channel decides how
91: to deliver the message and sees to any necessary message reformatting
92: that may be necessary (e.g. ``header munging'').
93: .PP
94: There is currently a variety of channels and the number is growing.
95: The local channel handles delivery of messages to local addresses.
96: The list channel is a special, somewhat incestuous, channel which acts
97: the role of channel, receiving user agent, and sending user agent all
98: in one. The list channel resubmits mail back into the mail system
99: by calling \fBsubmit\fR.
100: This has several benefits that will be discussed later.
101: .FN
102: See the section on the list channel.
103: .FE
104: The SMTP channel delivers mail via TCP/IP connections using the SMTP
105: protocol.
106: .FN
107: J. Postel, ``RFC821 - Simple Mail Transfer Protocol'', Network Information
108: Center, SRI International, August 1982.
109: .FE
110: The phone channel uses the PhoneNet link-level protocol software
111: developed at the University of Delaware for sending mail over
112: dialup or hard-wired terminal lines.
113: The NIFTP channel queues mail as files to be transferred using the
114: NIFTP protocol used in the British research community.
115: The UUCP channel is used to queue requests for transfer using UUCP.
116: .PP
117: Development of MMDFII was started about the same time that the Sendmail
118: mail transfer agent was being
119: written by Eric Allman at Berkeley.
120: Dave Crocker met with Eric on a number of occasions and was impressed
121: by his work.
122: Some elements of the Berkeley software were so useful that
123: they inspired the development of similar facilities in MMDFII.
124: Not the least of these was the runtime configuration file.
125: It is now possible to configure the MMDF software totally from a
126: single, ASCII-text-based configuration file.
127: Unlike Sendmail's terse configuration syntax, MMDF uses much more
128: verbose keyword/value pairing for configuration information.
129: MMDFII can be configured either from compiled-in values, for fast startup,
130: or totally from the text configuration file, or from any combination of the
131: two.
132: As a result of the fact that many values can be compiled-in, the usual
133: MMDF tailoring file is one-tenth the size of
134: a Sendmail tailoring file, and can be even smaller, even on a large relay site.
135: The runtime configuration file is one of the most useful additions
136: in MMDFII, especially for sites supporting more than one host,
137: since one can now run the same binaries on all machines of the same type.
138: Another Berkeley-inspired facility was the ability to have an alias
139: file entry that forces a delivery to a file or pipe.
140: While initially insecure, this facility has been made
141: reliable by adding code to /fBsubmit/fR that knows when you are
142: processing an alias file entry and when you are processing some
143: other type of address.
144: Simple ownership of the file containing the address was not considered
145: sufficient protection since there are too many
146: files left writable to the world that are owned by root or other
147: privileged users.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.