Return to p2 CVS log

Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ucs / mmdf

Annotation of 43BSDReno/share/doc/ucs/mmdf/p2, revision 1.1

1.1     ! root        1: .SH
        !             2: The MMDF Design
        !             3: .PP
        !             4: The MMDF system design has not changed fundamentally
        !             5: from the original design proposed and implemented for MMDFI.
        !             6: The design of MMDFI is covered in detail in the paper
        !             7: ``An Internetwork Memo Distribution Capability''.
        !             8: .FN
        !             9: D. Crocker, E. Szurkowski, and D. Farber,
        !            10: ``An Internetwork Memo Distribution Capability'', Datacom Conference,
        !            11: September 1979.
        !            12: .FE
        !            13: In this chapter, I will summarize the basic design and discuss
        !            14: those changes that have been made in MMDFII.
        !            15: .PP
        !            16: Mail software is normally classed into one of two groups.
        !            17: A user agent (UA) is a program
        !            18: that is responsible for providing a ``user friendly'' interface
        !            19: for reading or writing mail and converting to the canonical
        !            20: interface of the mail transfer agent as necessary.
        !            21: A mail transfer agent (MTA) is a program or system
        !            22: to which you or your user agent entrusts a message for delivery
        !            23: to someone else's user agent.
        !            24: There has been a great deal of confusion caused by people who
        !            25: fail to realize the difference between a mail transfer agent and 
        !            26: a user agent, or even that a difference exists!
        !            27: There is a wide variety of user agents which can be used with
        !            28: MMDF, and it is the responsibility of the use agent to provide a user interface.
        !            29: This separation of the functions of user agent and mail transfer
        !            30: agent has many advantages, not the least of which is that MMDF
        !            31: can support many different user interfaces with ease.
        !            32: Currently, there are at least five different interfaces available
        !            33: including the Rand MH system, V6 style mail, Berkeley's Mail (cap-mail),
        !            34: the Tenex-style Send and Msg programs, and Rmail (for UUCP).
        !            35: MMDF is a mail transfer agent.
        !            36: MMDF does not have, nor does it claim to have, a good ``user interface'';
        !            37: instead it has a good program (MTA-UA) interface.
        !            38: MMDF accepts messages for delivery either locally or to a remote
        !            39: site.  It attempts to verify the validity of the addresses at submission
        !            40: time to the extent possible given only a host table and a list of
        !            41: local addresses.  If accepted, it will continually try to resend the
        !            42: message until the retry time is exhausted at which time
        !            43: the message is returned to the sender.
        !            44: .PP
        !            45: The MMDF system can be thought of as two subsystems, responsible
        !            46: for mail submission and mail delivery, respectively.
        !            47: Between these two halves is the mail queue.
        !            48: The mail queue will be discussed later, but basically it stores each
        !            49: message as two files, an address list with some control information, and
        !            50: a separate file containing only the message text (header and body).
        !            51: .PP
        !            52: The submission half of the system consists mainly of one program,
        !            53: called ``\fBsubmit\fR'', which is responsible for enqueuing mail to be
        !            54: delivered.  As much verification as possible is performed on the
        !            55: message at
        !            56: submission time.
        !            57: For mail destined for the local machine, this means making sure the
        !            58: destination account exists, and that any local mailing list or aliases
        !            59: expand properly.
        !            60: For mail that has a non-local host specification, the \fBsubmit\fR
        !            61: process checks to see if it knows how to reach the specified host.
        !            62: Mail which for any reason is known to be undeliverable, is not accepted
        !            63: for delivery.
        !            64: \fBSubmit\fR is called by two types of processes.  The first group includes
        !            65: user agents such as the \fBsend\fR program.  The second group 
        !            66: comprises channel
        !            67: programs such as \fBrmail\fR
        !            68: .FN
        !            69: The \fBrmail\fR program (/bin/rmail) is
        !            70: invoked by uucp when delivering mail
        !            71: on your system.
        !            72: .FE
        !            73: which are interfacing to remote mail transfer agents.
        !            74: .PP
        !            75: The delivery portion of MMDF is represented by two main elements: the
        !            76: \fBdeliver\fR program which manages the queue, and
        !            77: the channel programs which handle the details of
        !            78: delivery to a specific network, host, or mail system.
        !            79: The \fBdeliver\fR program takes each message which is eligible to
        !            80: be delivered, and opens the appropriate address list.  For each address
        !            81: in the list, \fBdeliver\fR ensures that it is running the appropriate channel
        !            82: program and then passes the envelope information
        !            83: .FN
        !            84: The MMDF envelope information consists of the the
        !            85: return address, the destination addresses, some delivery options and
        !            86: a reference to the message text file.
        !            87: .FE
        !            88: to the channel.  A reference to the file containing the actual
        !            89: message text is passed to the
        !            90: channel program.  The channel decides how
        !            91: to deliver the message and sees to any necessary message reformatting
        !            92: that may be necessary (e.g. ``header munging'').
        !            93: .PP
        !            94: There is currently a variety of channels and the number is growing.
        !            95: The local channel handles delivery of messages to local addresses.
        !            96: The list channel is a special, somewhat incestuous, channel which acts
        !            97: the role of channel, receiving user agent, and sending user agent all
        !            98: in one.  The list channel resubmits mail back into the mail system
        !            99: by calling \fBsubmit\fR.
        !           100: This has several benefits that will be discussed later.
        !           101: .FN
        !           102: See the section on the list channel.
        !           103: .FE
        !           104: The SMTP channel delivers mail via TCP/IP connections using the SMTP
        !           105: protocol.
        !           106: .FN
        !           107: J. Postel, ``RFC821 - Simple Mail Transfer Protocol'', Network Information
        !           108: Center, SRI International, August 1982.
        !           109: .FE
        !           110: The phone channel uses the PhoneNet link-level protocol software
        !           111: developed at the University of Delaware for sending mail over
        !           112: dialup or hard-wired terminal lines.
        !           113: The NIFTP channel queues mail as files to be transferred using the
        !           114: NIFTP protocol used in the British research community.
        !           115: The UUCP channel is used to queue requests for transfer using UUCP.
        !           116: .PP
        !           117: Development of MMDFII was started about the same time that the Sendmail 
        !           118: mail transfer agent was being
        !           119: written by Eric Allman at Berkeley.
        !           120: Dave Crocker met with Eric on a number of occasions and was impressed
        !           121: by his work.
        !           122: Some elements of the Berkeley software were so useful that
        !           123: they inspired the development of similar facilities in MMDFII.
        !           124: Not the least of these was the runtime configuration file.
        !           125: It is now possible to configure the MMDF software totally from a
        !           126: single, ASCII-text-based configuration file.
        !           127: Unlike Sendmail's terse configuration syntax, MMDF uses much more
        !           128: verbose keyword/value pairing for configuration information.
        !           129: MMDFII can be configured either from compiled-in values, for fast startup,
        !           130: or totally from the text configuration file, or from any combination of the
        !           131: two.
        !           132: As a result of the fact that many values can be compiled-in, the usual
        !           133: MMDF tailoring file is one-tenth the size of
        !           134: a Sendmail tailoring file, and can be even smaller, even on a large relay site.
        !           135: The runtime configuration file is one of the most useful additions
        !           136: in MMDFII, especially for sites supporting more than one host,
        !           137: since one can now run the same binaries on all machines of the same type.
        !           138: Another Berkeley-inspired facility was the ability to have an alias
        !           139: file entry that forces a delivery to a file or pipe.
        !           140: While initially insecure, this facility has been made
        !           141: reliable by adding code to /fBsubmit/fR that knows when you are
        !           142: processing an alias file entry and when you are processing some
        !           143: other type of address.
        !           144: Simple ownership of the file containing the address was not considered
        !           145: sufficient protection since there are too many
        !           146: files left writable to the world that are owned by root or other
        !           147: privileged users.

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