rsalz@uunet.UU.NET (Rich Salz) (09/23/87)
Submitted-by: Larry Auton <clyde.ATT.COM!lda>
Posting-number: Volume 11, Issue 69
Archive-name: smail3/Part01
[ Smail is the "official" mailer of the UUCP Project, the people who
bring you the monthly UUCP maps and domain names to UUCP-only
organizations. Putting it quite shortly, this turns any UUCP
site into a "smart" mailer. The documentation is extensive. --r$ ]
# This is a shell archive. Remove anything before this line, then
# unpack it by saving it in a file and typing "sh file". (Files
# unpacked will be owned by you and have default permissions.)
#
# This archive contains:
# Contacts Domains Flow.Diagram Install Read.Me aliases.8 lcasep.8 mkfnames.8 nptx.8 pathproc.8 paths.8 smail.8
echo x - Contacts
cat > "Contacts" << '//E*O*F Contacts//'
Contact Information
We strongly encourage electronic mail for queries, updates, and
applications. This cuts down on our costs, and we can pass those
savings along to you. We currently do not have a telephone number
for queries, although we hope to have one in the near future. If
you are unable to send and receive electronic mail, you will have
to wait until we are prepared for telephone calls or postal mail.
For queries: uucp-query@Stargate.COM cbosgd!stargate!uucp-query
For updates: uucpmap@Stargate.COM cbosgd!stargate!uucpmap
For problems: uucp-problem@Stargate.COM cbosgd!stargate!uucp-problem
To register: registry@Stargate.COM cbosgd!stargate!registry
#
#@(#)Contacts 2.5 (smail) 9/15/87
#
//E*O*F Contacts//
echo x - Domains
cat > "Domains" << '//E*O*F Domains//'
WHAT YOU NEED TO KNOW ABOUT PATHALIAS
AND WHAT PATHALIAS NEEDS TO KNOW ABOUT YOU
or
HOW PATHALIAS MAKES DOMAINS
Christopher Seiwald
This note describes the host connectivity data and domain data
needed to effect UUCP domain-style address routing. This
describes mostly the domain data, but also discusses how to
distribute connectivity data. Look elsewhere for a discussion of
domains.
Briefly, the connectivity data (what's in mod.map) connects
all hosts in the UUCP network into one big directed graph, and
the domain data superimposes a domain tree onto that graph.
Pathalias converts these two sets of data into a routing database
which smail/rmail, a UUCP mail routing program, uses.
1. Domains and Gateways for UUCP
For domains in the UUCP zone, the top of a subdomain is all
gateway hosts for that domain; the top of the UUCP zone will
probably be nearly a hundred hosts. As a transition aid, we
also consider an individual host at the bottom of the domain tree a
subdomain "host.UUCP", with one gateway and no further subdomains.
(We expect to phase this out eventually.)
A gateway host for a domain must do four things:
I) Pass mail bound for that domain to the
appropriate host.
II) Pass mail bound for outside that domain to a
gateway in the parent domain.
III) Pass mail bound for a subdomain to a gateway of
that subdomain.
IV) Recognise the domain!user address syntax.
smail/rmail already provides (IV). With the data described here,
pushed through pathalias, smail/rmail can then provide (I)-(III).
2. The Zone Registry
For any sizeable zone, one gateway host supports the zone registry.
For other zones, such as BITNET, CSNET, DDN, etc., registries are
supported, using conventions appropriate to those zones. Contact
electronic mail addresses are supported for queries, and updates to
configuration information may also be handled via mail. In the UUCP
zone, the id's "uucpmap@cbosgd.ATT.COM" and "domains@cbosgd.ATT.COM"
serve to collect the connectivity and domain data, respectively, for
that zone.
The registry for a zone speaks for that zone, communicating
chiefly with its peers, the registry of the parent domain, and
the registries of the subdomains.
3. Functions of Domain Data
Each gateway for a domain must map the domain-style names into
the UUCP host names for all hosts of the domain. This host name
mapping provides (I) above.
Each gateway for a domain knows a) at least one gateway for each
immediate subdomain, and b) at least one gateway host of the
parent domain. This provides (II) and (III) above.
For consistency across the gateways of a domain, each gateway for
the domain should know a) ALL gateways for each immediate
subdomain; and b) ALL gateways for the parent domain. Pathalias
will pick the closest. In this way, one single database can
describe the domain structure for all gateways on a domain,
without variations for each gateway.
In order to aid routing and avoid overloading the parent gateway,
gateways should also know most gateways for peer level domains.
This information is also provided by the map and used by pathalias.
When a new peer domain is created, traffic can be routed through the
parent (which must be updated immediately) until information about
the peer can be propagated.
Additionally, a gateway could know about domains more than one
level above or below it so that mail doesn't stop for address
resolution at every gateway along its path.
4. Format of Domain Data
4.1 Host Name List
The host name list aliases the domain style address of a host to
the UUCP host name. The pathalias input format is:
uucp-name .domain-name[, ...]
The .UUCP suffix is implicit in the uucp-name (smail/rmail does
this), and is not needed.
Upper/lower case doesn't matter in a dotted domain name.
Examples:
ihnp4 = .ATT.COM
ucbvax = .Berkeley.EDU
cbosgd = .osgd.cb.att.com, .cbosgd.att.com
Might produce from pathalias:
ihnp4 mtxinu!ihnp4!%s
.ihnp4.ATT.COM mtxinu!ihnp4!%s
ucbvax ucbvax!%s
.Berkeley.EDU ucbvax!%s
cbosgd cbosgd!%s
.osgd.cb.att.com cbosgd!%s
.cbosgd.att.com cbosgd!%s
A single host may have more than one domain style address; in
fact, a host may be in several domains at once. However, each
host must have a single primary location in the domain tree,
and other addresses should be viewed as transition aids. For
example, cbosgd might be known as cbosgd, cbosgd.UUCP,
cbosgd.ATT.UUCP, cbosgd.btl.csnet, and cbosgd.ATT.COM, but
the primary name is the one in the organizational domain (COM)
which applies to all networks, and the others are temporary
names for upward compatibility only.
4.2 Domain Gateway List
The domain gateway list aliases the domain style address of a
domain to the UUCP host name of the closest gateway of that
domain. This involves a trick in pathalias, and employs a
extra network name domain-gw. The pathalias input format is:
domain-gw .domain-name
Again, the .UUCP suffix is implicit in the uucp-name, and is
not needed.
Examples:
decwrl .DEC.COM
decuac .DEC.COM
cbosgd .ATT.COM
clyde .ATT.COM
Might generate from pathalias:
.DEC.COM seismo!decuac!%s
.ATT.COM cbosgd!%s
Note that pathalias chooses the closest host from inside the {}'s.
The (DEAD)'s prevent pathalias from following along the mock network
called "domain-gw".
5. Distribution of Domain Data
A zone registry maintains a Host Name List (in the format of 4.1
above) of all hosts within its domain and a Domain Gateway List
(in the format of 4.2 above) of all gateways of the domain.
Up: A registry collects the Domain Gateway List from the registry
of each of its subdomains, and transmits to the registry of its
parent domain its own Domain Gateway List and, if it chooses, the
Domain Gateway Lists of some or all of its subdomains. Whether
it includes lists from its subdomains depends on how important it
considers them to the parent domain.
Down: Similarly, a registry collects the Domain Gateway List from
the registry of its parent domain, and transmits to the registry
of each of its subdomains its Domain Gateway List and the Domain
Gateway List of its parent domain. Note that the Domain Gateway
List of the parent domain may include lists from the parent's
other subdomains.
A registry may decide not to use the parent domain's Domain
Gateway List or not to transmit it to its subdomains' registries.
(This should be done only with the consent of the subdomains.) In
this case, the registry must introduce a domain gateway alias for
all top level domains, to ensure that all the mail gets delivered.
Across: a registry transmits to each of the gateways of its
domain its Host Name List, its Domain Gateway List, and collected
Domain Gateway Lists. The registry also transmits to each normal
host (one gateway, no subdomains) of its domain its Domain
Gateway List.
Together, "up," "down," and "across" insure that each gateway has
the Host Name List for its domain, and the Domain Gateway List of
its own domain and at least its parent domain and subdomains.
"Up" and "across" will probably take place on demand by mail.
"Down" will probably be broadcast via netnews on a regular
schedule. In particular, the second level information for the UUCP
zone (one entry per organization) and the complete top level domain
information make up the postings to mod.map.
6. Distribution of Connectivity Data
The distribution of connectivity data will probably follow the
path of domain data: registries passing connectivity data up,
down, and across the domain tree, with the exception that the
connectivity within a third (or lower) level domain will be
discouraged from leaving the domain, so the data the UUCP zone
registry distributes will include only the first and second
level gateways. Local information about internal subdomains and
machines of organizations should not be included in globally
published information, but rather distributed locally as needed.
7. Various Notes
The following are examples of data that should be joined together
as input to pathalias.
Parent Domain Gateway List
Parent Connectivity Data
This Level Domain Gateway List
This Level Host Name List
This Level Connectivity Data
Collected Subdomains' Domain Gateway Lists
Collected Subdomains' Connectivity Data
Private Additions
Alias for "this host"
This note does not describe the inclusion of private additions to
the domain or connectivity data.
Because domain names intermix with host names (and the .UUCP
suffix is implicit), you can address hosts known at your gateway
as "uucp-host.UUCP". We discourage this, because the address is
then particular to the sender's location.
/+\
5/1/85 +\ chris@cbosgd.att.com
\+/
[Updated 5/9/86 by Mark Horton.]
#
#@(#)Domains 2.5 (smail) 9/15/87
#
//E*O*F Domains//
echo x - Flow.Diagram
cat > "Flow.Diagram" << '//E*O*F Flow.Diagram//'
vanilla 4.2BSD mail flow
LOCAL /bin/mail ---- -- /bin/mail -- LOCAL
\ /
----------- sendmail --
/ / \
LOCAL Mail --------- / -- uux -------- REMOTE
/
REMOTE /bin/rmail ------------
==========================
smail 4.2BSD mail flow
LOCAL /bin/mail -- /bin/mail -- LOCAL
\ /
------------ sendmail --
/ / \
LOCAL Mail --- / -- /bin/smail -
/ (non-bang) \
REMOTE /bin/rmail ------ \
\ (bang) \
------------------------------------- uux REMOTE
==========================
vanilla SVR2 mail flow
mail is "/usr/src/cmd/mail.c"
rmail is linked to mail
LOCAL mail ------------\ /--------------------- LOCAL
\ /
LOCAL mailx ----> mail ---+----------+
/ \
REMOTE rmail ------------/ \-- uux -------------- REMOTE
==========================
Modified SVR2 mail flow using SENDMAIL
Definitions of changed/renamed programs
mail is "svbinmail.c"
lmail is "/usr/src/cmd/mail.c"
rmail is linked to smail
LOCAL mail ------------\ /-- lmail ---------- LOCAL
\ /
+--sendmail--+
/ \
LOCAL mailx --- mail ---/ \-- smail -- uux --- REMOTE
/-- lmail ------ LOCAL
/
/--sendmail--+
/ \
/ \- smail - uux - REMOTE
/ (domain | LOCAL)
REMOTE rmail --------------+
\ (bang)
\
\------------------ uux -------- REMOTE
==========================
Modified SVR2 mail flow without SENDMAIL
LOCAL mail ------------\ /-- lmail ---------- LOCAL
\ /
+-- rmail ---+
/ / \
LOCAL mailx --- mail ---/ / \-- uux ----------- REMOTE
/
/
REMOTE --------------------+
#
# @(#)Flow.Diagram 2.5 (smail) 9/15/87
#
//E*O*F Flow.Diagram//
echo x - Install
cat > "Install" << '//E*O*F Install//'
There are three system types on which smail can be installed.
(1) Berkeley with sendmail
(2) System V with sendmail
(3) System V without sendmail
Note: if you have a System III or V7 derived system, you
can probably treat it like (3). We have not tested smail
on such a system.
The installation will vary slightly for each system type.
For all systems you first have to create a 'paths' database.
See paths(8) for details on the file's format. Then
copy it to /usr/lib/uucp/paths.
Next, edit "defs.h" to configure smail to suit your situation.
Here are step by step installation instructions for each system type.
(1) For a berkeley system with sendmail, the steps are:
$ make
$ cp smail /bin/smail
$ sh make.cf.sh
<answer the questions it asks>
$ mv /usr/lib/sendmail.cf /usr/lib/OLDsendmail.cf
$ cp sendmail.cf /usr/lib/sendmail.cf
$ /usr/lib/sendmail -bz
$ mv /bin/rmail /bin/OLDrmail
$ ln /bin/smail /bin/rmail
(2) For a System V system with sendmail, the steps are:
$ make
$ cp smail /bin/smail
$ ln /bin/mail /bin/lmail
$ sh make.cf.sh
<answer the questions it asks>
$ mv /usr/lib/sendmail.cf /usr/lib/OLDsendmail.cf
$ cp sendmail.cf /usr/lib/sendmail.cf
$ /usr/lib/sendmail -bz
$ rm /bin/mail # (Remember, you still have it in /bin/lmail.)
$ mv svbinmail /bin/mail
$ mv /bin/rmail /bin/OLDrmail
$ ln /bin/smail /bin/rmail
Note: some implementations of sendmail don't work when the 'U'
flag is set in the definition of the local mailer (a line that
begins with "Mlocal" in the generated sendmail.cf). If you try
to send mail from a local user to a local user, a message comes
out that says "No '!' in UUCP! (user)" - and the mail fails.
If this happens take the 'U' flag out of the sendmail.cf.
[ the >'s are secondary prompts from the shell,
and ^M is 'carat' 'M', not 'control-M' ]
$ ed sendmail.cf <<!
> /^Mlocal/s/SU/S/
> w
> q
> !
(3) For a System V system without sendmail, the steps are:
$ make
$ cp smail /bin/smail
$ mv /bin/mail /bin/lmail
$ mv svbinmail /bin/mail
$ mv /bin/rmail /bin/OLDrmail
$ ln /bin/smail /bin/rmail
You're done.
#
# @(#)Install 2.5 (smail) 9/15/87
#
//E*O*F Install//
echo x - Read.Me
cat > "Read.Me" << '//E*O*F Read.Me//'
Read.Me - Updated 9/15/87
What smail does:
smail is capable of handling UUCP syntax (bang paths, bang
domains, and at domains are supported) mail transportation
over UUCP/uux/rmail channels. It will support machines that
only have UUCP connections, and machines with UUCP links to
the outside world plus a small number of local machines that
are reached via SMTP. The domain intelligence is embedded
in the smail database (e.g. the pathalias output), not the
sendmail.cf file, so if you have a fancier domain structure
that involves SMTP or anything other than uux in the domain
structure, you'll want to modify the sendmail.cf file here or
merge pieces of the enclosed sendmail.cf into your own.
smail runs under 4.2BSD and System V, as a back end to sendmail;
and under System V without sendmail. It also replaces rmail, which
becomes a link to smail. In a sendmail environment, smail depends on
sendmail to crack the headers, as smail just deals with the envelope.
smail makes your host capable of using the INTERNET definition in the
Usenet software.
Features of smail include:
(1) Using pathalias data to choose the best route to your destination.
(2) Handling of user@domain, domain!user, and host!user syntax.
(3) Generation of domain!user syntax to be forwarded by other systems.
(4) Logging of traffic through your machine, by sender, recipient, and
size of message, so you can, track use and detect abuse of your
machine.
(5) Mail being forwarded through your machine to another uux link is
passed from rmail directly to uux, so there's less overhead on
your machine (sendmail stays out of the loop.)
(6) Sendmail-like alias capability for hosts without sendmail.
(7) Generation of RFC822 required headers for locally generated mail.
(8) Robust delivery scheme that reroutes only if stated path is inaccessible.
(8) Mail that is undeliverable is returned to sender.
(9) Simplicity.
Prerequisites:
A copy of a recent posting of pathalias. (The one posted
by Peter Honeyman in January 1986 is recommended.)
A current copy of the UUCP map, or at least a copy of the
appropriate part of it that you're interested in.
A properly registered domain name for your organization, such
as ATT.COM. (It is possible to run smail using a domain name
under .UUCP, but since this can't be officially registered,
it is appropriate only for testing.)
You can get pathalias from the mod.sources Usenet archive
(contact sources-request@uunet.uu.net or uunet!sources-request)
You can get a UUCP map each month from Usenet newsgroup mod.map.
The UUCP map is quite large (currently about 2MB) so please don't ask
to have a copy mailed to you - get a copy from a nearby Usenet site.
You can get a domain name by joining the UUCP Zone. There are
low membership dues for this, and a registration process that
will take 2-8 weeks. This Read.Me file may be out of date by
the time you read it, so we ask you to contact us for current
dues rates and procedures. Contact uucp-query@Stargate.COM or
cbosgd!stargate!uucp-query and ask for the UUCP Zone information
packet. (If you already belong to a network such as CSNET, DDN,
or BITNET, your organization may already have a domain name. If
you are also on UUCP, it is recommended that you also join the
UUCP Zone at the lower rate for organizations whose primary
affiliation is with another network. See the file "Registry"
for more information.
Overall structure:
smail is installed in /bin/smail with a link in /bin/rmail. Uuxqt
calls rmail, which either forwards the message on to the next hop
directly or, on a sysetm with sendmail, calls sendmail. sendmail
may decide the message should be delivered by UUCP, and invoke smail,
which will look up a route and invoke uux. (Note that the choice
about when to invoke sendmail and when to process a message directly
can be configured in smail.)
smail uses a database which is generated from pathalias. You take the
current UUCP map, add some local information and topology data (to tell
it about the domain tree) and run pathalias. The result is sorted and
installed in /usr/lib/uucp/paths. There is no hashing done on this
file - when smail looks up a name it uses a binary search.
Configuration considerations:
You'll note two configuration options in defs.h: HANDLE and ROUTING.
These control which sorts of addresses smail/rmail will handle, and
which type of routing they will do. The HANDLE define only affects
rmail, since smail sets it implicitly. In any case, we recommend
that you leave HANDLE alone, unless you are making major changes.
ROUTING has three choices: JUSTDOMAIN, ALWAYS, and REROUTE. rmail
will run as JUSTDOMAIN, the defs.h default. This means rmail will
only apply routing if it sees "rmail user@domain", and will just call
uux if it sees "rmail host!user". (If the uux fails, it will call
smail -r, which will apply ALWAYS routing to try to get the mail
there anyway. If the ALWAYS routing fails, then REROUTE routing is
applied. This has the advantage of being low overhead on your
system, not second guessing a route someone else asked for, and still
recovering nicely from the mistakes of another system. Your host
becomes a "smart host" that can get mail anywhere.)
Many people will note huge paths going through their machine. These
paths are generated by replies to netnews messages, and tend to be 10
or 20 hops long - far longer than necessary. If you are a bit aggressive,
you can change -r to -R, which will cause such failed mail to be rerouted,
thus, mail to a!b!c!d!e!f!g!user will look up a route to g, and send the
mail to route!g!user. (If it can't find g, it will try f, then e, and
so on until it finds someone it recognizes.) If you are REALLY aggressive,
you can change ROUTING to REROUTE in defs.h, to get the same effect for
ALL rmail being passed through your machine. This may help cut phone
bills, but it has some disadvantages. It can lengthen a path sometimes,
e.g. mail to tektronix!user might turn into ihnp4!tektronix!user if your
routing database says mail to tektronix goes through ihnp4. It makes it
hard to route around a dead host, or to redirect traffic from a mailing
list to several different directions. It may also make mail go a different
path than what your user thought it was, and it affects other hosts that
route mail through you if you set ROUTING to REROUTE in defs.h. So only
do this if you know what you are doing, and are willing to live with the
disadvantages.
#
#@(#)Read.Me 2.5 (smail) 9/15/87
#
//E*O*F Read.Me//
echo x - aliases.8
cat > "aliases.8" << '//E*O*F aliases.8//'
.TH ALIASES 8
.tr ~
.SH NAME
aliases \- alias file for smail
.SH DESCRIPTION
This file is used by
.I smail
only if
.I SENDMAIL
is
.I not defined.
If
.I SENDMAIL
is defined, then
.I sendmail
does all of the aliasing for the host.
.PP
This file contains a list of aliases for
local users or mailing lists.
The format of each alias is
.sp
.ce
alias_name~recip_name1~recip_name2~...
.sp
An attempt has been made to remain compatible with
.I sendmail
alias file format, though the syntax is much more format free than
.I sendmail.
As distributed,
.I case differences are ignored
when comparing names to aliases.
Only alias names which resolve to the local host are recognized, and are
stored in their local form.
Lines which start with a white~space are continuation lines.
Parenthesised strings are taken as comments (no nesting),
as is anything after a '#' (as in
.IR /bin/sh ).
Here are some examples:
.sp
.nf
# this whole line is a comment
#
# These are equivalent definitions
alias_name recip1 recip2 recip3
alias_name: recip1, recip2 , recip3
alias_name recip1 recip2
recip3
alias_name recip1 # Recip1's name
recip2 # Recip2's name
recip3 # Recip3's name
alias_name recip1 (Recp1's name) recip2 (Recp2's name)
recip3 (Recp3's name)
alias_name@thishost recip1 recip2 recip3
alias_name@thisdomain recip1 recip2 recip3
thishost!alias_name recip1 recip2 recip3
thisdomain!alias_name recip1 recip2 recip3
.fi
.PP
Mailing lists are easily handled by two forms of file inclusion.
The first form is the same as is supported by
.I sendmail
.sp
.ce
mylist :include:/usr/lib/ml/mylist
.sp
In this example, each entry in
.I /usr/lib/ml/mylist
would be added to the alias for
.I mylist.
The second form is unique to
.I smail.
It allows the
.I aliases
file to include other
.I aliases
files.
.sp
.ce
:include:/usr/lib/ml/more-aliases
.sp
This would include the file
.I /usr/lib/ml/more-aliases
as a regular alias file.
This makes it easier to maintain groups of aliases that
change frequently, such as the list of netnews moderators.
.PP
All aliases are recursive, so care
must be taken in their definition.
.I smail
aliasing attempts to prevent infinite loops, and to
do what was intended by the user. For example, the alias:
.sp
.ce
mylogin~mypc!mylogin~mylogin
.sp
Expands to
.sp
.ce
mypc!mylogin mylogin
.sp
even though the second occurrence of
.I mylogin
matches the alias name.
.sp
Both forms of file inclusion are recursive, too,
so watch out for nesting include files. They
may lead to infinite loops.
.PP
While the cost of parsing an alias file is usually negligible,
it's wise to take savings anywhere savings
can be found. Therefore, it's worth mentioning
.IR smail 's
parsing strategy.
.I smail
will try to get by with doing as little work
as possible when aliasing. If on a particular
invocation of
.I smail,
none of the recipent addresses are local,
(i.e., not potential aliases)
then the
.I aliases
file won't even be read. Similarly,
when an
.I aliases
file is read, it does not expand any of the :include: files
until they are referenced. Thus, in the alias (above) for
.I mylist,
the file
.I :include:/usr/lib/ml/mylist
would not be opened and read (parsed) unless
mail was sent to
.I mylist.
Wise use of :include: files can greatly
increase the efficiency of the alias utility.
It's not clear exactly where the
.I break-even
point is when deciding to use an :include: file in an alias,
versus having all of the recipents listed on the line;
but if a mailing list is large (whatever that means)
it is wise to use the :include: feature to save on
parsing costs. Note that this discussion only applies to the
first form of file inclusion, since reading an
.I aliases
file constitutes a reference to :include: files of the second form.
.PP
There is another form of aliasing which works with the alias capability.
This is called
.I per user forwarding.
For a given user name, if there is no alias for the user
then, if the file
.I ~user/.forward
exists, then its contents will be treated as an alias for
the user. The syntax is the same as that of the
recipient lists in the alias file described above.
.PP
One difference between
.I smail
and
.I sendmail
is that
.I smail
doesn't handle stuff like mail to files
or command execution.
.SH SEE ALSO
smail(8), paths(8), pathproc(8)
.SH VERSION
@(#)aliases.8 2.5 (smail) 9/15/87
//E*O*F aliases.8//
echo x - lcasep.8
cat > "lcasep.8" << '//E*O*F lcasep.8//'
.TH LCASEP 8
.tr ~
.SH NAME
lcasep \- convert first field to lower case
.SH SYNOPSIS
.B lcasep
[ -f infile ] [ -o outfile ]
.SH DESCRIPTION
.I Lcasep
converts all upper case characters
in the first field of each input line to lower case
and writes the line to its output. By default,
.I lcasep
reads from the standard input and writes to the standard output.
Fields are delimited by a tab (ascii~0x9) character.
It is used in preparation for sorting
.IR smail "'s"
.I paths
database. There is a bug in
.I sort -f
that causes non-alphanumeric keys to be sorted incorrectly.
Conversion before sorting avoids this bug.
.SH SEE ALSO
pathalias - by Peter Honeyman
.br
smail(8), paths(8), pathproc(8)
.SH VERSION
@(#)lcasep.8 2.5 (smail) 9/15/87
//E*O*F lcasep.8//
echo x - mkfnames.8
cat > "mkfnames.8" << '//E*O*F mkfnames.8//'
.TH MKFNAMES 8
.tr ~
.SH NAME
mkfnames \- create full name database
.SH SYNOPSIS
.B mkfnames [ file ...]
.SH DESCRIPTION
.I mkfnames
uses the named
.I files
as input and writes a sorted database suitable for
use as the full name database for
.IR smail (8)
on the standard output.
The format of an input line is defined by
.IR nptx (8).
If no
.I files
are specified, then the password file is
used to parsed and an attempt is made to
munge it into the format needed by
.I nptx. No guarantees on this, since
there are so many bizarre password file
formats.
.SH SEE ALSO
smail(8), paths(8), nptx(8)
.SH VERSION
@(#)mkfnames.8 2.5 (smail) 9/15/87
//E*O*F mkfnames.8//
echo x - nptx.8
cat > "nptx.8" << '//E*O*F nptx.8//'
.TH NPTX 8
.tr ~
.SH NAME
nptx \- full name permutations
.SH SYNOPSIS
.B nptx
.SH DESCRIPTION
.I nptx
reads a list of address name pairs on the standard
input and prints name permutations and the address
pairs on the standard output.
nptx is generally used in generation of a full name
database for
.IR smail (8).
The format of an input line is
.sp
.ce
address name
.sp
The address field can contain any address, it is terminated by
a TAB char (ascii 0x9). No translation is done on the field.
The name field consists of whitespace separated names or initials
with an optional nickname given in parentheses, it is terminated
by either a newline ascii (0xA) or a ',' (ascii 0x). All permutations
of the names and initials are printed. The only restriction is
that the last name will appear in each permutation. The permutations
are not necesarily unique.
.SH EXAMPLES
.nf
.in +5
$ echo "gpb@ECH.gatech.edu\tWrecker Burdell(George P.)"|nptx
Burdell gpb@ECH.gatech.edu
W.Burdell gpb@ECH.gatech.edu
Wrecker.Burdell gpb@ECH.gatech.edu
Burdell gpb@ECH.gatech.edu
G.Burdell gpb@ECH.gatech.edu
George.Burdell gpb@ECH.gatech.edu
P.Burdell gpb@ECH.gatech.edu
P.Burdell gpb@ECH.gatech.edu
G.P.Burdell gpb@ECH.gatech.edu
George.P.Burdell gpb@ECH.gatech.edu
G.P.Burdell gpb@ECH.gatech.edu
George.P.Burdell gpb@ECH.gatech.edu
$
.in
.SH SEE ALSO
smail(8), paths(8), mkfnames(8)
.SH VERSION
@(#)nptx.8 2.5 (smail) 9/15/87
//E*O*F nptx.8//
echo x - pathproc.8
cat > "pathproc.8" << '//E*O*F pathproc.8//'
.TH PATHPROC 8
.SH NAME
pathproc \- pathalias post\-processor for smail routing database
.SH DESCRIPTION
.I Pathproc
takes lines of the form
.sp
.ce
\fIfirst_hop_cost key route\fP
.sp
as produced by
.I pathalias -f
and converts it to the form
.sp
.ce
\fI key route cost\fP
.sp
as described in
.IR paths (8).
On the input, the
.I route_cost
is
.IR pathalias "'s"
total cost for the route.
On the output, the
.I cost
is the cost for the
.I first segment
of the route.
This represents the cost, to the local host,
of passing the mail to its neighbor.
.PP
The output is sorted by
.I key
in ascending order.
.SH EXAMPLE
Here's an example of how you might use
.I pathproc:
.sp
.in+3
pathalias -f \fImap_files\fP | pathproc > newpaths
.br
mv newpaths /usr/lib/uucp/paths
.in
.sp
.SH SEE ALSO
pathalias - by Peter Honeyman
.br
smail(8), lcasep(8), paths(8)
.SH VERSION
@(#)pathproc.8 2.5 (smail) 9/15/87
//E*O*F pathproc.8//
echo x - paths.8
cat > "paths.8" << '//E*O*F paths.8//'
.TH PATHS 8
.tr ~
.SH NAME
paths \- smail routing database
.SH DESCRIPTION
The
.I paths
file is the routing database for
.IR smail .
Each line of the file provides routing information
to either a host or to a domain. Each line should
have either two or three tab (ascii~0x9) separated fields.
The format of each line in the paths file is:
.tr ~
.sp
.ce
\fIkey~~route~~~[cost]\fP
.sp
The
.I key
field is the key on which searches are performed.
Typically this is either a UUCP host name or a domain name.
.I smail
uses a binary search algorithm when searching the database,
so the keys must be sorted in ascending order.
Case is ignored when searching, so the keys should be converted
to lower case before sorting (see
.IR lcase (8)
and
.IR pathproc (8)).
.B Warning:
There is a bug in
.I sort -f,
so don't use it. Convert the keys to lower case, and then sort.
.PP
The
.I route
field is a "printf" string that details the route that mail to the
.I key
should take.
See
.I pathalias
documentation for details.
.PP
The optional
.I cost
field is used by
.I smail
to determine whether to simply queue outbound
UUCP mail, or to attempt immediate delivery
(usually by invoking
.IR uucico ).
If the cost field is present, and the value is at or below
.IR smail "'s"
.I queueing threshold
then the mail will be queued and an attempt at immediate delivery
will be made. This will speed mail delivery between hosts who
enjoy a cheap uucp link, like a hardwired line or some other
low cost transport medium, while allowing mail sent over more
expensive media to accumulate before transmission.
If the field is absent, the cost defaults to a value
above the
.I queueing threshold.
The default value for the queueing threshold is equal to the pathalias
cost DEDICATED+LOW. Thus, direct links with cost DEDICATED+LOW or less
will see immediate delivery, while the others are queued for later delivery.
.SH EXAMPLE
Here's a sample paths file for a small host, like a pc, that doesn't
want to maintain complete routing information. It illustrates
most of the aspect of the
.I paths
file. Assme that the pc's name is
.I mypc,
and that it's in domain
.I .mydomain.
Also, assume that it has a dedicated link to
a smart host named
.I bighub,
and that
.IR bighub 's
administrator has given
.I mypc
.B permission
to use
.I bighub
as a mail relay.
Lastly, assume that
.I mypc
has a dialed on demand link to another computer named
.I friend.
.nf
.sp
.in +5
\fIpathalias\fP input
.sp
mypc = .mypc.mydomain
mypc friend(DEMAND), bighub(DEDICATED)
smart-host = bighub
.sp
\fIpaths\fP file produced by \fIpathalias -f inputfile|pathproc\fP
.sp
.mypc.mydomain %s 0
bighub bighub!%s 95
friend friend!%s 300
mypc %s 0
smart-host bighub!%s 95
.in
.sp
.fi
.SH SEE ALSO
pathalias - by Peter Honeyman
.br
smail(8), lcasep(8), pathproc(8)
.SH VERSION
@(#)paths.8 2.5 (smail) 9/15/87
//E*O*F paths.8//
echo x - smail.8
cat > "smail.8" << '//E*O*F smail.8//'
.TH SMAIL 8
.SH NAME
smail, rmail \- UUCP mailer with routing
.SH SYNOPSIS
.B smail
[ options ] address ...
.br
.B rmail
[ options ] address ...
.SH DESCRIPTION
The
.I smail/rmail
program replaces
.IR /bin/rmail (1)
to become the UUCP mail transport mechanism.
They are links to the same executable.
.I rmail
receives mail from UUCP,
.I smail
introduces mail into UUCP.
.PP
.I smail/rmail
can work with or without
.IR sendmail (8),
or another intelligent mail system.
For hosts with just
.IR /bin/mail (1),
.I smail/rmail
subsumes some of the functions of
.I sendmail,
and hands only local mail to
.I /bin/mail.
For hosts with
.I sendmail,
.I smail/rmail
can act as UUCP front and back ends to
.I sendmail,
allowing
.I sendmail
to process all mail through the host.
As distributed, 'bang' mail that is not bound for a local
recipient will be passed directly to
.I uux
without calling
.I sendmail.
.PP
To varying degrees,
.I smail/rmail
automatically routes the addresses it processes.
.I smail/rmail
most often routes domain style addresses (i.e. user@domain), producing
a UUCP path (i.e. host!address) or a local address (i.e. user), but it can
also reroute explicit UUCP paths.
.SH OPTIONS
.TP
.B \-A
Print the resolved addresses. Don't collect a message or invoke a mailer.
.TP
.B \-d
Be verbose and don't invoke other mailers.
.TP
.B \-v
Be verbose, but still invoke other mailers.
.TP
.BI \-h " hostname"
Set hostname. The default is configuration dependent, but usually provided
by a system call such as
.IR gethostname (2)
or
.IR uname (2).
.TP
.BI \-H " hostdomain"
set hostdomain. The default is configuration dependent.
.TP
.BI \-F " address"
use
.I address
on the From: line in locally generated mail.
.TP
.BI \-p " pathfile"
Set path database file name if not /usr/lib/uucp/paths.
.TP
.BI \-a " aliasfile"
For sites without sendmail, set alias database file name if not in
the place defined at compile time (see ALIASES in defs.h).
This is usually
.I /usr/lib/aliases
.TP
.BI \-n " namelist"
.I smail
supports another type of aliasing intended for full name resolution
using a sorted file,
.I namelist,
of name/address pairs.
This allows mail to George.P.Burdell@gatech.edu to be delivered
appropriately. These aliases are by their nature very simple
since they are not composed of long lists of recipients for each alias.
They are also numerous, since mail to George.P.Burdell may be addressed
to Burdell, G.Burdell, George.Burdell, P.Burdell, G.P.Burdell, or
George.P.Burdell. This simpler form of aliasing uses the same
fast searching algorithm that is used for the paths file, so
it keeps resolution time manageable.
.TP
.BI \-q " number"
Take
.I number
as the queueing threshold.
When routing mail (
.I -r, -R,
or domain addressed mail
) to a given host, if the cost listed in the
.I paths
file is less than the queueing threshold, then the mail
will be sent immediately. This overrides the default threshold
(see QUEUECOST in defs.h) of DEDICATED+LOW.
.TP
.BI \-m " number"
At most
.I number
jobs will be handed to uux for immediate delivery
by a single invocation of
.I smail
(see MAXNOQUEUE in defs.h).
.TP
.BI \-u " uuxflags"
Use
.I uuxflags
as the flags passed to uux for remote mail.
This overrides any of the default values and other queueing strategies.
.TP
.B -c
Consult the paths file for the cost of the path even when not routing
the mail. This makes it possible to use the cost information when
sending pure UUCP path mail without rerouting it.
.TP
.B \-r
Route the first component of a UUCP path (host!address) in addition to routing
domain addresses (user@domain).
.TP
.B \-R
Reroute UUCP paths, trying successively larger righthand substrings
of a path until a component is recognized.
.TP
.B \-l
Instead of routing a domain address, send it to the local mailer for
processing. Normally, only local addresses go to the local mailer.
.TP
.B \-L
Send all addresses to the local mailer for processing, including UUCP paths.
.PP
Most of the flags are also compile time options, since
.I uux
does not normally invoke
.I rmail
with the desired flags.
.I smail
resets any preset
.B -l
or
.B -L
flags.
.B -l
flag causes
.B rmail
to send all domain addresses through the local mailer,
to process addresses for non UUCP domains.
The
.B -L
flag causes
.B rmail
to send even explicit UUCP paths through the local mailer,
presumably to make use of other transport mechanisms.
In both cases, rmail defers any routing until smail gets hold it.
.SH ADDRESSES
.I smail/rmail
understands "user@domain" to be a domain address, "host!address" to be a
UUCP path, and anything else to be a local address.
.PP
Because hostile
.I rmail's
unpredictably interpret mixed UUCP/domain addresses,
.I smail/rmail
understands "domain!user" to be a domain address, and generates
"path!domain!user" when mailing to a cognate
.I smail/rmail
host.
To distinguish domain "domain!user" from UUCP "host!address", "domain"
contains at least one (1) period.
Unlike the old
.I /bin/rmail,
.I smail/rmail
gives precedence to @ over ! when parsing mixed addresses,
thus a!b@c is parsed as (a!b)@c, rather than a!(b@c).
.SH ROUTING
Because
.I smail/rmail
is the UUCP transport mechanism, it can only effect delivery on UUCP paths
and local addresses; domain addresses require resolution into UUCP paths or
local addresses.
To resolve a domain address,
.I smail/rmail
finds a route to the most specific part of the domain specification listed
in the routing table.
Two degrees of resolution can occur:
.RS
.PP
Full resolution:
.I smail/rmail
finds a route for the entire domain specification, and tacks the user
specification onto the end of the UUCP path.
The address can also fully resolve to a local address (the UUCP path is null).
.PP
Partial resolution:
.I smail/rmail
finds a route for only righthand part of the domain specification, so it
tacks the complete address (in the form domain!user) onto the end of the
UUCP path.
Since this syntax is not widely understood, UUCP gateways listed in
the path database must install new UUCP software, either
.I smail/rmail
or new
.I sendmail
configuration files (or both).
.RE
.PP
It is an error if a partially resolved address routes to the local host
(a null UUCP path), since according to the routing table, the local
host is responsible for resolving the address more fully.
.PP
The
.B -r
flag causes
.I smail/rmail
to attempt to route the first component of a UUCP path, probably so it
can impress people with how many UUCP hosts it knows.
If this fails, it passes the unrouted address to
.I uux,
in case the path database is not complete.
The
.B -R
flag causes
.I smail/rmail
to take a UUCP path and route the rightmost component of the path (save
the user name) possible.
This is mostly for hosts that have very up-to-date routing tables.
.PP
If a route cannot be discerned from the available routing database,
then one more attempt to route the mail is made by searching for an
entry in the database for a route to a
.I smart-host.
If this entry exists, then the mail will be forwarded along that route
to be delivered. This allows a host to depend on another, presumably
better informed, host for delivering its mail.
This kind of arrangement should be worked out,
.I in advance,
with the
.IR smart-host 's
administrator.
.PP
After
.I smail/rmail
resolves an address, it reparses it to see if it is now a UUCP path or
local address. If the new address turns out to be another
domain address, smail complains because we don't like to resolve more than once.
This error occurs when an address partially resolves the local host.
.PP
By default,
.I smail
will not alter the explicit bang path routing of any mail message.
If the stated path is unuseable, (i.e., the next hop host is unknown)
then smail will apply ALWAYS routing, and attempt to deliver the mail
to the potentially new address. If this fails too, then REROUTE routing
will be applied to the address, and another attempt to deliver is made.
Lastly, an attempt to find a path to a better informed host
.I smart-host
will be made and the mail passed to that host.
.SH FROMMING
.I smail/rmail
collapses From_ and >From_ lines to generate a simple from argument, which
it can pass to
.I sendmail
or use to create its own "From" line.
The rule for fromming is: concatenate each "remote from" host (separating
them by !'s), and tack on the address on the last From_ line; if that address
is in user@domain format, rewrite it as domain!user; ignore host or
domain if either is simply the local hostname. It also removes redundant
information from the From_ line. For instance:
.sp
.ce
...!myhost!myhost.mydomain!...
.sp
becomes
.sp
.ce
...!myhost!...
.sp
Leading occurrences of the local host name are elided as well.
.PP
.I smail/rmail
generates it own From_ line, unless it is feeding
.I sendmail,
which is happy with the
.BI -f from
argument.
For UUCP bound mail,
.I smail/rmail
generates a "remote from hostname", where hostname is the UUCP hostname
(not the domain name), so that From_ can indicate a valid UUCP path, leaving
the sender's domain address in From:.
.SH HEADERS
Certain headers, To:, From:, Date, etc., are required by RFC822.
If these headers are absent in locally generated mail, they will
be inserted by smail. Also, a line of trace information, called
a Received: line, will be inserted at the top of each message.
.SH UNDELIVERABLE MAIL"
Although nobody likes to have a mail message fail to reach its
intended destination, it somtimes happens that way.
Mail that is found to be undeliverable
(i.e., unknown user or unknown host)
will be returned to the sender.
.SH FILES
/usr/lib/uucp/paths ascii path database
.br
/usr/lib/aliases ascii alias database
.br
/usr/spool/uucp/mail.log log of mail
.br
/tmp/mail.log record of mail
.SH SUPPORT
Enhancements, enhancement requests, trouble reports, etc.,
should be sent to
.sp
.ce
uucp-problem@Stargate.COM.
.sp
.SH "SEE ALSO"
.IR uux (1),
.IR paths (8),
.IR aliases (8)
.br
.IR sendmail (8)
.br
.IR binmail (1)
on BSD systems only
.br
.IR mail (1)
on System V systems
.SH VERSION
@(#)smail.8 2.5 (smail) 9/15/87
//E*O*F smail.8//
exit 0