Annotation of 43BSDReno/share/doc/usd/08.mh/mh-mts.me, revision 1.1

1.1     ! root        1: .\"    This file is automatically generated.  Do not edit!
        !             2: .SC MH\-MTS 8
        !             3: .NA
        !             4: mh\-mts \- the MH interface to the message transport system
        !             5: .SY
        !             6: SendMail
        !             7: 
        !             8: .ti .5i
        !             9: MMDF (any release)
        !            10: 
        !            11: .ti .5i
        !            12: stand\-alone
        !            13: .DE
        !            14: \fIMH\fR can use a wide range of message transport systems to deliver mail.
        !            15: Although the \fIMH\fR administrator usually doesn't get to choose which MTS
        !            16: to use (since it's already in place),
        !            17: this document briefly describes the interfaces.
        !            18: 
        !            19: When communicating with \fISendMail\fR,
        !            20: \fIMH\fR always uses the SMTP to post mail.
        !            21: Depending on the \fIMH\fR configuration,
        !            22: \fISendMail\fR may be invoked directly (via a \fIfork\fR and an \fIexec\fR),
        !            23: or \fIMH\fR may open a TCP/IP connection to the SMTP server on the localhost.
        !            24: 
        !            25: When communicating with \fIMMDF\fR,
        !            26: normally \fIMH\fR uses the \*(lqmm\(ru\*(rq routines to post mail.
        !            27: However, depending on the \fIMH\fR configuration,
        !            28: \fIMH\fR instead may open a TCP/IP connection to the SMTP server on the
        !            29: localhost.
        !            30: 
        !            31: When using the stand\-alone system (\fBNOT\fR recommended),
        !            32: \fIMH\fR delivers local mail itself and queues \fIUUCP\fR and network mail.
        !            33: The network mail portion will probably have to be modified to reflect the
        !            34: local host's tastes, since there is no well\-known practice in this area for
        !            35: non\-4.2BSD hosts.
        !            36: 
        !            37: If you are running a 4.2BSD UNIX system,
        !            38: then it is felt that the best interface is achieved by using either
        !            39: \fISendMail\fR or \fIMMDF\fR with the SMTP option.
        !            40: This gives greater flexibility.
        !            41: To enable this option you append the /smtp suffix to the mts option in the
        !            42: \fIMH\fR configuration.
        !            43: This yields two primary advantages:
        !            44: First,
        !            45: you don't have to know where \fIsubmit\fR or \fISendMail\fR live.
        !            46: This means that \fIMH\fR binaries (e.g., \fIpost\fR\0)
        !            47: don't have to have this information hard\-coded,
        !            48: or can run different programs altogether;
        !            49: and,
        !            50: second, you can post mail with the server on different systems, so you don't
        !            51: need either \fIMMDF\fR or \fISendMail\fR on your local host.
        !            52: Big win in conserving cycles and disk space.
        !            53: Since \fIMH\fR supports the notion of a server search\-list in this respect,
        !            54: this approach can be tolerant of faults.
        !            55: 
        !            56: There are four disadvantages to using the SMTP option:
        !            57: First, only 4.2BSD UNIX is supported.
        !            58: Second, you need to have an SMTP server running somewhere on any network your
        !            59: local host can reach.
        !            60: Third, this bypasses any authentication mechanisms in \fIMMDF\fR
        !            61: or \fISendMail\fR.
        !            62: Fourth,
        !            63: the file \fB/etc/hosts\fR is used for hostname lookups
        !            64: (although there is an exception file).
        !            65: In response to these disadvantages though:
        !            66: First, 4.2BSD UNIX is the best UNIX around for networking.
        !            67: When other UNIXes get TCP/IP and real networking,
        !            68: \fIMH\fR can be modified.
        !            69: Second, there's got to be an SMTP server somewhere around if you're in the
        !            70: Internet or have a local network.
        !            71: Since the server search\-list is very general,
        !            72: a wide\-range of options are possible.
        !            73: Third,
        !            74: SMTP should be fixed to have authentication mechanisms in it, like POP.
        !            75: Fourth,
        !            76: \fIMH\fR won't choke on mail to hosts whose official names it can't verify,
        !            77: it'll just plug along
        !            78: (and besides
        !            79: if you enable the BERK or DUMB configuration options,
        !            80: \fIMH\fR ignores the hosts file altogether).
        !            81: .Fi
        !            82: ^/usr/new/lib/mh/mtstailor~^tailor file
        !            83: .Pr
        !            84: None
        !            85: .Sa
        !            86: \fIMMDF\-II: A Technical Review\fR,
        !            87: Proceedings, Usenix Summer '84 Conference
        !            88: .br
        !            89: \fISENDMAIL \-\- An Internetwork Mail Router\fR
        !            90: .br
        !            91: mh\-tailor(8), post(8)
        !            92: .De
        !            93: None
        !            94: .Co
        !            95: None
        !            96: .Bu
        !            97: The /usr/new/lib/mh/mtstailor file ignores the information in the \fIMMDF\-II\fR
        !            98: tailoring file.
        !            99: It should not.
        !           100: .En

unix.superglobalmegacorp.com

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