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

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.