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