Annotation of 43BSDReno/share/doc/ucs/mmdf/p9, revision 1.1.1.1

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.

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.