Annotation of 43BSDReno/share/doc/usd/08.mh/mh-mts.me, revision 1.1.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.