![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to Read.Me CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [MW Coherent from dump] / coherent / d / bin / mail / smail / docs|
Return to Read.Me CVS log | Up to [MW Coherent from dump] / coherent / d / bin / mail / smail / docs |
1.1 root 1: Read.Me - Updated 9/15/87
2:
3: What smail does:
4:
5: smail is capable of handling UUCP syntax (bang paths, bang
6: domains, and at domains are supported) mail transportation
7: over UUCP/uux/rmail channels. It will support machines that
8: only have UUCP connections, and machines with UUCP links to
9: the outside world plus a small number of local machines that
10: are reached via SMTP. The domain intelligence is embedded
11: in the smail database (e.g. the pathalias output), not the
12: sendmail.cf file, so if you have a fancier domain structure
13: that involves SMTP or anything other than uux in the domain
14: structure, you'll want to modify the sendmail.cf file here or
15: merge pieces of the enclosed sendmail.cf into your own.
16:
17: smail runs under 4.2BSD and System V, as a back end to sendmail;
18: and under System V without sendmail. It also replaces rmail, which
19: becomes a link to smail. In a sendmail environment, smail depends on
20: sendmail to crack the headers, as smail just deals with the envelope.
21: smail makes your host capable of using the INTERNET definition in the
22: Usenet software.
23:
24: Features of smail include:
25:
26: (1) Using pathalias data to choose the best route to your destination.
27: (2) Handling of user@domain, domain!user, and host!user syntax.
28: (3) Generation of domain!user syntax to be forwarded by other systems.
29: (4) Logging of traffic through your machine, by sender, recipient, and
30: size of message, so you can, track use and detect abuse of your
31: machine.
32: (5) Mail being forwarded through your machine to another uux link is
33: passed from rmail directly to uux, so there's less overhead on
34: your machine (sendmail stays out of the loop.)
35: (6) Sendmail-like alias capability for hosts without sendmail.
36: (7) Generation of RFC822 required headers for locally generated mail.
37: (8) Robust delivery scheme that reroutes only if stated path is inaccessible.
38: (8) Mail that is undeliverable is returned to sender.
39: (9) Simplicity.
40:
41: Prerequisites:
42:
43: A copy of a recent posting of pathalias. (The one posted
44: by Peter Honeyman in January 1986 is recommended.)
45:
46: A current copy of the UUCP map, or at least a copy of the
47: appropriate part of it that you're interested in.
48:
49: A properly registered domain name for your organization, such
50: as ATT.COM. (It is possible to run smail using a domain name
51: under .UUCP, but since this can't be officially registered,
52: it is appropriate only for testing.)
53:
54: You can get pathalias from the mod.sources Usenet archive
55: (contact [email protected] or uunet!sources-request)
56:
57: You can get a UUCP map each month from Usenet newsgroup mod.map.
58: The UUCP map is quite large (currently about 2MB) so please don't ask
59: to have a copy mailed to you - get a copy from a nearby Usenet site.
60:
61: You can get a domain name by joining the UUCP Zone. There are
62: low membership dues for this, and a registration process that
63: will take 2-8 weeks. This Read.Me file may be out of date by
64: the time you read it, so we ask you to contact us for current
65: dues rates and procedures. Contact [email protected] or
66: cbosgd!stargate!uucp-query and ask for the UUCP Zone information
67: packet. (If you already belong to a network such as CSNET, DDN,
68: or BITNET, your organization may already have a domain name. If
69: you are also on UUCP, it is recommended that you also join the
70: UUCP Zone at the lower rate for organizations whose primary
71: affiliation is with another network. See the file "Registry"
72: for more information.
73:
74: Overall structure:
75:
76: smail is installed in /bin/smail with a link in /bin/rmail. Uuxqt
77: calls rmail, which either forwards the message on to the next hop
78: directly or, on a sysetm with sendmail, calls sendmail. sendmail
79: may decide the message should be delivered by UUCP, and invoke smail,
80: which will look up a route and invoke uux. (Note that the choice
81: about when to invoke sendmail and when to process a message directly
82: can be configured in smail.)
83:
84: smail uses a database which is generated from pathalias. You take the
85: current UUCP map, add some local information and topology data (to tell
86: it about the domain tree) and run pathalias. The result is sorted and
87: installed in /usr/lib/uucp/paths. There is no hashing done on this
88: file - when smail looks up a name it uses a binary search.
89:
90: Configuration considerations:
91:
92: You'll note two configuration options in defs.h: HANDLE and ROUTING.
93: These control which sorts of addresses smail/rmail will handle, and
94: which type of routing they will do. The HANDLE define only affects
95: rmail, since smail sets it implicitly. In any case, we recommend
96: that you leave HANDLE alone, unless you are making major changes.
97:
98: ROUTING has three choices: JUSTDOMAIN, ALWAYS, and REROUTE. rmail
99: will run as JUSTDOMAIN, the defs.h default. This means rmail will
100: only apply routing if it sees "rmail user@domain", and will just call
101: uux if it sees "rmail host!user". (If the uux fails, it will call
102: smail -r, which will apply ALWAYS routing to try to get the mail
103: there anyway. If the ALWAYS routing fails, then REROUTE routing is
104: applied. This has the advantage of being low overhead on your
105: system, not second guessing a route someone else asked for, and still
106: recovering nicely from the mistakes of another system. Your host
107: becomes a "smart host" that can get mail anywhere.)
108:
109: Many people will note huge paths going through their machine. These
110: paths are generated by replies to netnews messages, and tend to be 10
111: or 20 hops long - far longer than necessary. If you are a bit aggressive,
112: you can change -r to -R, which will cause such failed mail to be rerouted,
113: thus, mail to a!b!c!d!e!f!g!user will look up a route to g, and send the
114: mail to route!g!user. (If it can't find g, it will try f, then e, and
115: so on until it finds someone it recognizes.) If you are REALLY aggressive,
116: you can change ROUTING to REROUTE in defs.h, to get the same effect for
117: ALL rmail being passed through your machine. This may help cut phone
118: bills, but it has some disadvantages. It can lengthen a path sometimes,
119: e.g. mail to tektronix!user might turn into ihnp4!tektronix!user if your
120: routing database says mail to tektronix goes through ihnp4. It makes it
121: hard to route around a dead host, or to redirect traffic from a mailing
122: list to several different directions. It may also make mail go a different
123: path than what your user thought it was, and it affects other hosts that
124: route mail through you if you set ROUTING to REROUTE in defs.h. So only
125: do this if you know what you are doing, and are willing to live with the
126: disadvantages.
127:
128: #
129: #@(#)Read.Me 2.5 (smail) 9/15/87
130: #
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.