Return to p4 CVS log

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

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

1.1     ! root        1: .SH
        !             2: Submit
        !             3: .PP
        !             4: For all the changes to its internals, the external interface of
        !             5: \fBsubmit\fR has changed remarkably little since MMDFI.
        !             6: The only notable external changes to \fBsubmit\fR are that it now
        !             7: processes domain-style addresses (both forward and reverse!)
        !             8: and both RFC822
        !             9: and RFC733 format addresses.
        !            10: .FN
        !            11: D. Crocker, J. Vittal, K. Pogran, D. Henderson, ``RFC733 - Standard
        !            12: for the Format of ARPA Network Text Message'',
        !            13: Network Information Center, SRI International, November 1977.
        !            14: 
        !            15: D. Crocker, ``RFC822 - Standard
        !            16: for the Format of ARPA Network Text Message'',
        !            17: Network Information Center, SRI International, August 1982.
        !            18: .FE
        !            19: A couple of new options have been added to \fBsubmit\fR to give some
        !            20: control over the handling of returned mail in the event that a message
        !            21: cannot be delivered.  This is
        !            22: useful if the user is a program and does not care if
        !            23: the message is undeliverable!
        !            24: It is also now possible to feed a bare message to \fBsubmit\fR and tell
        !            25: \fBsubmit\fR to find all the addresses and show them and their validity
        !            26: on a one-by-one basis.  This makes it convenient
        !            27: to feed mail to \fBsubmit\fR from a smart mail composer that doesn't want to
        !            28: know how to parse addresses (a major task these days!).
        !            29: .PP
        !            30: The \fBsubmit\fR program can operate in one of two modes.
        !            31: In \fIprotocol\fR mode, \fBsubmit\fR accepts options, a return address,
        !            32: and optionally a list of addresses for each message, followed by the
        !            33: message text.  Multiple messages can be submitted
        !            34: one after another without reinvoking the \fBsubmit\fR process.
        !            35: Each address is individually acknowledged.  If there is an error,
        !            36: the submission of that letter is aborted and a new submission
        !            37: may be made.
        !            38: In \fIone-shot\fR mode a single message is submitted on the standard
        !            39: input.
        !            40: As in \fIprotocol\fR mode, it can be preceded by options and addresses,
        !            41: or the options can be given on the command line and the addresses taken
        !            42: from the message text.
        !            43: .PP
        !            44: The internal address verification process of \fBsubmit\fR has changed
        !            45: greatly since MMDFI.  Most of the changes
        !            46: have been made to properly support domain style addresses.
        !            47: Additional changes were made to support per-channel
        !            48: and per-user access
        !            49: controls.
        !            50: While \fBsubmit\fR is checking each address, regardless
        !            51: of origin, it is also compiling the address
        !            52: list for the message.
        !            53: Each address list entry contains the destination domain,
        !            54: .FN
        !            55: By ``domain'' we mean the full domain specification of a host, e.g.
        !            56: VAX1.UDEL.ARPA.
        !            57: .FE
        !            58: the destination mailbox,
        !            59: and the channel in whose channel table \fBsubmit\fR first found the destination
        !            60: host.
        !            61: The lookup is somewhat complicated.
        !            62: The destination domain is looked up in the domain tables;
        !            63: the first entry found is used.
        !            64: Each domain table entry has associated with it the routing to be used to reach
        !            65: that domain/host.  Normally this is just the name of the host itself
        !            66: if the host is directly accessible, but it can be a sequence of hosts if the
        !            67: destination is not directly accessible.
        !            68: This ``routing host'' is then looked up in the channel tables
        !            69: to find a channel which can reach it.  The routing host specifications
        !            70: and the entries in the channel tables are always full domain specifications,
        !            71: so as to be unambiguous.
        !            72: .PP
        !            73: Authorization is checked after a valid channel for a host is found.
        !            74: Access to send via a given channel
        !            75: depends on the originating channel and/or the submitting user.
        !            76: If access to a given channel is denied, \fBsubmit\fR will continue to look
        !            77: at subsequent channels to see if some other channel has access to the
        !            78: same host and is authorized.  This mechanism is commonly used
        !            79: to restrict access to expensive transport systems or to restrict
        !            80: message transfer between channels representing private and public
        !            81: data networks.
        !            82: It can also be used to restrict relaying of messages between two
        !            83: "controlled-access" networks.

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