|
|
1.1 root 1: .SH
2: Using Domain Name Servers
3: .PP
4: The use of domain name servers
5: will have some interesting effects
6: on the address verification aspects of mail submission.
7: In the current system, all the information
8: necessary for verification of addresses is in a local
9: data base.
10: When we are using name servers, we can no longer be guaranteed
11: that all the needed information will be locally cached.
12: In addition, we are not guaranteed that we will be able to
13: reach all the necessary name servers at submission time (although
14: duplicate name servers will make this possibility small).
15: The \fBsubmit\fR program will call the local domain resolver to
16: verify each address, and there will be some time limit in which to
17: complete this task.
18: The resolver will be expected to first
19: consult the local cache of domain data
20: and, if the information is not found,
21: contact as many servers as
22: necessary to resolve the address.
23: .PP
24: The possible lack of information will force us to provide a
25: contingent submission queue for those messages that
26: cannot be verified at submission time.
27: This does not imply that there will we be no verification.
28: We will verify that we at least know the top level domain
29: of each address and verify each sub-domain when possible.
30: If some sub-domain of the full address is known to be bogus, the
31: address can be flushed.
32: Knowing that we have authoritative information that a domain
33: does not exist is just as important as knowing that it does exist.
34: .PP
35: A new channel, much like the list channel, will be used to process
36: the partially-accepted address for a message.
37: This channel will continually try to verify the address until
38: it is known to be good or bad. It will have the message
39: returned to the sender, with an explanation, if one or more addresses
40: is bad.
41: Most systems will run with a fairly rich cache of host information.
42: For those systems which cannot afford to keep this information
43: around, the submission time verification might be a considerable
44: delay which would be unacceptable for a user interface.
45: On these systems it will possible to force all message to be accepted for
46: background verification (via the "verification" channel).
47: .SH
48: Conclusion
49: .PP
50: MMDFII had some early problems and as a result may have gotten
51: some initial bad press, but MMDFII has shown that it is
52: a capable mail system which is both robust and able to handle
53: very large mail loads.
54: There now exist a growing number of tools to analyze and manage
55: large flows of mail in a MMDF system. These tools include status
56: programs, sophisticated logging, and log analysis programs.
57: Because of the separation of mail into separate queues,
58: multiprocessing of the mail queues is not only possible, but
59: routinely used to both increase throughput and decrease
60: delays.
61: MMDF is also a flexible system.
62: Runtime reconfiguration is simple, generally easy to understand,
63: and can be done at any time.
64: Since the MMDF core software is free of channel specific or
65: network specific information, one can easily add additional channels
66: for new networks or protocols without affecting the existing
67: software.
68: MMDFII represents a stable, production mail system,
69: providing a strong base for the development of
70: new network interconnections and mail handling environments
71: which are essential in today's distributed computing environment.
72: .sp 2
73: .PP
74: The MMDFII software is available under license,
75: free of charge
76: (with the possible exception of a tape copy fee),
77: for internal use only as follows:
78: to U.S. Government agencies through the Ballistic Research Labs,
79: to CSNET sites through the CSNET Coordination and Information Center at BBN,
80: and to others through Prof. David Farber at the University
81: of Delaware, Electrical Engineering and
82: Computer Science Department.
83: Commercial concerns interested in MMDF for other than internal
84: use should contact Prof. Farber.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.