home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / mmdf / mmdf-IIb.43 / doc / review / p9 < prev    next >
Encoding:
Text File  |  1986-02-01  |  3.7 KB  |  85 lines
  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.
  85.