Annotation of 43BSDReno/share/doc/ucs/mmdf/p9, revision 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.