|
|
1.1 root 1: .TH SMAIL 8
2: .SH NAME
3: smail, rmail \- UUCP mailer with routing
4: .SH SYNOPSIS
5: .B smail
6: [ options ] address ...
7: .br
8: .B rmail
9: [ options ] address ...
10: .SH DESCRIPTION
11: The
12: .I smail/rmail
13: program replaces
14: .IR /bin/rmail (1)
15: to become the UUCP mail transport mechanism.
16: They are links to the same executable.
17: .I rmail
18: receives mail from UUCP,
19: .I smail
20: introduces mail into UUCP.
21: .PP
22: .I smail/rmail
23: can work with or without
24: .IR sendmail (8),
25: or another intelligent mail system.
26: For hosts with just
27: .IR /bin/mail (1),
28: .I smail/rmail
29: subsumes some of the functions of
30: .I sendmail,
31: and hands only local mail to
32: .I /bin/mail.
33: For hosts with
34: .I sendmail,
35: .I smail/rmail
36: can act as UUCP front and back ends to
37: .I sendmail,
38: allowing
39: .I sendmail
40: to process all mail through the host.
41: As distributed, 'bang' mail that is not bound for a local
42: recipient will be passed directly to
43: .I uux
44: without calling
45: .I sendmail.
46: .PP
47: To varying degrees,
48: .I smail/rmail
49: automatically routes the addresses it processes.
50: .I smail/rmail
51: most often routes domain style addresses (i.e. user@domain), producing
52: a UUCP path (i.e. host!address) or a local address (i.e. user), but it can
53: also reroute explicit UUCP paths.
54: .SH OPTIONS
55: .TP
56: .B \-A
57: Print the resolved addresses. Don't collect a message or invoke a mailer.
58: .TP
59: .B \-d
60: Be verbose and don't invoke other mailers.
61: .TP
62: .B \-v
63: Be verbose, but still invoke other mailers.
64: .TP
65: .BI \-h " hostname"
66: Set hostname. The default is configuration dependent, but usually provided
67: by a system call such as
68: .IR gethostname (2)
69: or
70: .IR uname (2).
71: .TP
72: .BI \-H " hostdomain"
73: set hostdomain. The default is configuration dependent.
74: .TP
75: .BI \-F " address"
76: use
77: .I address
78: on the From: line in locally generated mail.
79: .TP
80: .BI \-p " pathfile"
81: Set path database file name if not /usr/lib/uucp/paths.
82: .TP
83: .BI \-a " aliasfile"
84: For sites without sendmail, set alias database file name if not in
85: the place defined at compile time (see ALIASES in defs.h).
86: This is usually
87: .I /usr/lib/aliases
88: .TP
89: .BI \-n " namelist"
90: .I smail
91: supports another type of aliasing intended for full name resolution
92: using a sorted file,
93: .I namelist,
94: of name/address pairs.
95: This allows mail to [email protected] to be delivered
96: appropriately. These aliases are by their nature very simple
97: since they are not composed of long lists of recipients for each alias.
98: They are also numerous, since mail to George.P.Burdell may be addressed
99: to Burdell, G.Burdell, George.Burdell, P.Burdell, G.P.Burdell, or
100: George.P.Burdell. This simpler form of aliasing uses the same
101: fast searching algorithm that is used for the paths file, so
102: it keeps resolution time manageable.
103: .TP
104: .BI \-q " number"
105: Take
106: .I number
107: as the queueing threshold.
108: When routing mail (
109: .I -r, -R,
110: or domain addressed mail
111: ) to a given host, if the cost listed in the
112: .I paths
113: file is less than the queueing threshold, then the mail
114: will be sent immediately. This overrides the default threshold
115: (see QUEUECOST in defs.h) of DEDICATED+LOW.
116: .TP
117: .BI \-m " number"
118: At most
119: .I number
120: jobs will be handed to uux for immediate delivery
121: by a single invocation of
122: .I smail
123: (see MAXNOQUEUE in defs.h).
124: .TP
125: .BI \-u " uuxflags"
126: Use
127: .I uuxflags
128: as the flags passed to uux for remote mail.
129: This overrides any of the default values and other queueing strategies.
130: .TP
131: .B -c
132: Consult the paths file for the cost of the path even when not routing
133: the mail. This makes it possible to use the cost information when
134: sending pure UUCP path mail without rerouting it.
135: .TP
136: .B \-r
137: Route the first component of a UUCP path (host!address) in addition to routing
138: domain addresses (user@domain).
139: .TP
140: .B \-R
141: Reroute UUCP paths, trying successively larger righthand substrings
142: of a path until a component is recognized.
143: .TP
144: .B \-l
145: Instead of routing a domain address, send it to the local mailer for
146: processing. Normally, only local addresses go to the local mailer.
147: .TP
148: .B \-L
149: Send all addresses to the local mailer for processing, including UUCP paths.
150: .PP
151: Most of the flags are also compile time options, since
152: .I uux
153: does not normally invoke
154: .I rmail
155: with the desired flags.
156: .I smail
157: resets any preset
158: .B -l
159: or
160: .B -L
161: flags.
162: .B -l
163: flag causes
164: .B rmail
165: to send all domain addresses through the local mailer,
166: to process addresses for non UUCP domains.
167: The
168: .B -L
169: flag causes
170: .B rmail
171: to send even explicit UUCP paths through the local mailer,
172: presumably to make use of other transport mechanisms.
173: In both cases, rmail defers any routing until smail gets hold it.
174: .SH ADDRESSES
175: .I smail/rmail
176: understands "user@domain" to be a domain address, "host!address" to be a
177: UUCP path, and anything else to be a local address.
178: .PP
179: Because hostile
180: .I rmail's
181: unpredictably interpret mixed UUCP/domain addresses,
182: .I smail/rmail
183: understands "domain!user" to be a domain address, and generates
184: "path!domain!user" when mailing to a cognate
185: .I smail/rmail
186: host.
187: To distinguish domain "domain!user" from UUCP "host!address", "domain"
188: contains at least one (1) period.
189: Unlike the old
190: .I /bin/rmail,
191: .I smail/rmail
192: gives precedence to @ over ! when parsing mixed addresses,
193: thus a!b@c is parsed as (a!b)@c, rather than a!(b@c).
194: .SH ROUTING
195: Because
196: .I smail/rmail
197: is the UUCP transport mechanism, it can only effect delivery on UUCP paths
198: and local addresses; domain addresses require resolution into UUCP paths or
199: local addresses.
200: To resolve a domain address,
201: .I smail/rmail
202: finds a route to the most specific part of the domain specification listed
203: in the routing table.
204: Two degrees of resolution can occur:
205: .RS
206: .PP
207: Full resolution:
208: .I smail/rmail
209: finds a route for the entire domain specification, and tacks the user
210: specification onto the end of the UUCP path.
211: The address can also fully resolve to a local address (the UUCP path is null).
212: .PP
213: Partial resolution:
214: .I smail/rmail
215: finds a route for only righthand part of the domain specification, so it
216: tacks the complete address (in the form domain!user) onto the end of the
217: UUCP path.
218: Since this syntax is not widely understood, UUCP gateways listed in
219: the path database must install new UUCP software, either
220: .I smail/rmail
221: or new
222: .I sendmail
223: configuration files (or both).
224: .RE
225: .PP
226: It is an error if a partially resolved address routes to the local host
227: (a null UUCP path), since according to the routing table, the local
228: host is responsible for resolving the address more fully.
229: .PP
230: The
231: .B -r
232: flag causes
233: .I smail/rmail
234: to attempt to route the first component of a UUCP path, probably so it
235: can impress people with how many UUCP hosts it knows.
236: If this fails, it passes the unrouted address to
237: .I uux,
238: in case the path database is not complete.
239: The
240: .B -R
241: flag causes
242: .I smail/rmail
243: to take a UUCP path and route the rightmost component of the path (save
244: the user name) possible.
245: This is mostly for hosts that have very up-to-date routing tables.
246: .PP
247: If a route cannot be discerned from the available routing database,
248: then one more attempt to route the mail is made by searching for an
249: entry in the database for a route to a
250: .I smart-host.
251: If this entry exists, then the mail will be forwarded along that route
252: to be delivered. This allows a host to depend on another, presumably
253: better informed, host for delivering its mail.
254: This kind of arrangement should be worked out,
255: .I in advance,
256: with the
257: .IR smart-host 's
258: administrator.
259: .PP
260: After
261: .I smail/rmail
262: resolves an address, it reparses it to see if it is now a UUCP path or
263: local address. If the new address turns out to be another
264: domain address, smail complains because we don't like to resolve more than once.
265: This error occurs when an address partially resolves the local host.
266: .PP
267: By default,
268: .I smail
269: will not alter the explicit bang path routing of any mail message.
270: If the stated path is unuseable, (i.e., the next hop host is unknown)
271: then smail will apply ALWAYS routing, and attempt to deliver the mail
272: to the potentially new address. If this fails too, then REROUTE routing
273: will be applied to the address, and another attempt to deliver is made.
274: Lastly, an attempt to find a path to a better informed host
275: .I smart-host
276: will be made and the mail passed to that host.
277: .SH FROMMING
278: .I smail/rmail
279: collapses From_ and >From_ lines to generate a simple from argument, which
280: it can pass to
281: .I sendmail
282: or use to create its own "From" line.
283: The rule for fromming is: concatenate each "remote from" host (separating
284: them by !'s), and tack on the address on the last From_ line; if that address
285: is in user@domain format, rewrite it as domain!user; ignore host or
286: domain if either is simply the local hostname. It also removes redundant
287: information from the From_ line. For instance:
288: .sp
289: .ce
290: ...!myhost!myhost.mydomain!...
291: .sp
292: becomes
293: .sp
294: .ce
295: ...!myhost!...
296: .sp
297: Leading occurrences of the local host name are elided as well.
298: .PP
299: .I smail/rmail
300: generates it own From_ line, unless it is feeding
301: .I sendmail,
302: which is happy with the
303: .BI -f from
304: argument.
305: For UUCP bound mail,
306: .I smail/rmail
307: generates a "remote from hostname", where hostname is the UUCP hostname
308: (not the domain name), so that From_ can indicate a valid UUCP path, leaving
309: the sender's domain address in From:.
310: .SH HEADERS
311: Certain headers, To:, From:, Date, etc., are required by RFC822.
312: If these headers are absent in locally generated mail, they will
313: be inserted by smail. Also, a line of trace information, called
314: a Received: line, will be inserted at the top of each message.
315: .SH UNDELIVERABLE MAIL"
316: Although nobody likes to have a mail message fail to reach its
317: intended destination, it somtimes happens that way.
318: Mail that is found to be undeliverable
319: (i.e., unknown user or unknown host)
320: will be returned to the sender.
321: .SH FILES
322: /usr/lib/uucp/paths ascii path database
323: .br
324: /usr/lib/aliases ascii alias database
325: .br
326: /usr/spool/uucp/mail.log log of mail
327: .br
328: /tmp/mail.log record of mail
329: .SH SUPPORT
330: Enhancements, enhancement requests, trouble reports, etc.,
331: should be sent to
332: .sp
333: .ce
334: [email protected].
335: .sp
336: .SH "SEE ALSO"
337: .IR uux (1),
338: .IR paths (8),
339: .IR aliases (8)
340: .br
341: .IR sendmail (8)
342: .br
343: .IR binmail (1)
344: on BSD systems only
345: .br
346: .IR mail (1)
347: on System V systems
348: .SH VERSION
349: @(#)smail.8 2.5 (smail) 9/15/87
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.