sources-request@mirror.UUCP (08/28/86)
Submitted by: Mark Horton <mark@cbosgd.ATT.COM>
Mod.sources: Volume 7, Issue 9
Archive-name: smail/Part01
[ Do not confuse this with the "Smail" written by Steven List of
Benetics that was published in Volume 1. --r$ ]
# To unpack the enclosed files, please use this file as input to the
# Bourne (sh) shell. This can be most easily done by the command;
# sh < thisfilename
# This archive contains;
# INFO.CHANGES INFO.DOCS INFO.DOMAINS INFO.FLOW_DIAG
# INFO.INSTALL INFO.README INFO.REGISTRY INFO.SENDMAIL
# INFO.SMAIL.8 INFO.TODO INFO.TROUBLE
# ---------- file INFO.CHANGES ----------
filename="INFO.CHANGES"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.CHANGES...
fi
cat << 'END-OF-FILE' > $filename
86/07/08:
Various minor bugs fixed before 1.0 distribution.
Gateway code checks for $- instead of $*, so you can mail to
subdomains of other nodes in your gateway (e.g. so cbosgd.ATT.COM
can mail to bonnie.clyde.ATT.COM)
Fixed rmail so that if the uux fails, it calls sendmail, which calls
smail -r (or -R) to route to the host, yet rmail's exit status is 0.
Fixed a bug preventing mail looped to yourself from being parsed right.
86/05/09:
Documentation polished for distribution.
86/03/30 resolve.c:
added code to route() to try leading dot first
86/03/30 resolve.c:
took out qualifydomain, since it turned x.UUCP into x.UUCP.COM
85/11/14 resolve.c:
Changes from rti.
Sun Oct 13 19:10:08 PDT 1985
Changes from several weeks ago:
General:
new, active sccs headers (not frozen politik ones)
Sendmail.cf:
ether and uucp preemption:
F and U classes to siphon off mail to neighboring ether
and uucp hosts, before kicking to default disposition
(usally smail). Other classes possible.
selection of default disposition:
either smail, ethernet relay, or uucp relay
support for route-addrs:
Rewrites <@hosta,rest-of-address> into hosta!rest-of-address
for safe passage to hosta via smail.
extensible construction:
ether and uucp classes model preemption
symmetrical code for similar operations
only one interface to UUCP (smail via dom)
pleasing to the eye
Smail:
program a little more robust:
checks for bad returns from index
passes lint better (not altogether)
hostname and hostdomain easier to define
getpath() without a path file is not fatal
-k (kludge) flag changed to -r (act like rmail) flag
support for route-addrs:
rmail recognises @domain... and parses to local for sendmail.
manual page:
SMAIL rewritten as smail.8. Unlike previous attempts by
others, this is a man page.
fashionable:
follows the trendiest advice on program readability.
Path.dom:
no more greipa.
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 1932 ]
then
echo $filename changed - should be 1932 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.DOCS ----------
filename="INFO.DOCS"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.DOCS...
fi
cat << 'END-OF-FILE' > $filename
This is a list of various documents that exist and may be helpful.
UUCP Project Documents
What You Need to Know About Pathalias and What Pathalias Needs to
Know About You, or How Pathalias Makes Domains; Christopher Seiwald;
(part of distribution in file INFO.DOMAINS.)
ARPA RFC 976: UUCP Mail Transmission Format Standard; Mark Horton; March 1986
What is a Domain?; Mark Horton; June 1984
Pathalias Documents
pathalias(1) manual page; Peter Honeyman
(It is assumed you have the Jan 1986 or later version of pathalias.)
ARPA Documents
RFC822: Standard for the Format of ARPA Internet Text Messages
RFC920: Domain Requirements
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 638 ]
then
echo $filename changed - should be 638 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.DOMAINS ----------
filename="INFO.DOMAINS"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.DOMAINS...
fi
cat << 'END-OF-FILE' > $filename
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. The dots protect quotes in names.
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"[, ...]
domain-gw = { gateway1[, ...] }(DEAD)
Again, the .UUCP suffix is implicit in the uucp-name, and is
not needed, and the quotes protect any dots in domain names.
Examples:
dec-gw = ".DEC.COM"
dec-gw = { decwrl, decuac }(DEAD)
att-gw = ".ATT.COM"
att-gw = { cbosgd, ihnp4 }(DEAD)
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.]
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 8979 ]
then
echo $filename changed - should be 8979 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.FLOW_DIAG ----------
filename="INFO.FLOW_DIAG"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.FLOW_DIAG...
fi
cat << 'END-OF-FILE' > $filename
vanilla 4.2BSD mail flow
(local src) /bin/mail - /bin/mail - -- /bin/mail
/ \ / (local dest)
(local src) mailx --/ ------------ sendmail --
/ / \ (remote dest)
(local src) Mail --------- / -- uux
/
(remote src) /bin/rmail ------------
==========================
smail 4.2BSD mail flow
(local src) /bin/mail - /bin/mail - -- /bin/mail
/ \ / (local dest)
(local src) mailx --/ ------------ sendmail --
/ / \ (remote dest)
(local src) Mail --------- / -- /bin/smail -
/ (non-bang) \
(remote src) /bin/rmail ------------ \
\ (bang) \
------------------------------------- uux
==========================
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 "binmail.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 --------------------+
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 2779 ]
then
echo $filename changed - should be 2779 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.INSTALL ----------
filename="INFO.INSTALL"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.INSTALL...
fi
cat << 'END-OF-FILE' > $filename
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), or possibly like Berkeley
without sendmail. We have not tested smail on such a system.
The installation will vary slightly for each system type.
(1) For a berkeley system with sendmail, the steps are:
create a pathalias database by any means available
and copy it to a file named "/usr/lib/uucp/paths"
$ sort -f /usr/lib/uucp/paths -o /usr/lib/uucp/paths
$ make
$ cp smail /bin/smail
$ sh smail.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:
create a pathalias database by any means available
and copy it to a file named "/usr/lib/uucp/paths"
$ sort -f /usr/lib/uucp/paths -o /usr/lib/uucp/paths
edit defs.h
$ make
$ cp smail /bin/smail
$ ln /bin/mail /bin/lmail
$ sh smail.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
(This step is optional. If strangeness results, you
can undo it by removing /usr/lib/sendmail.fc. This
step improves performance significantly, but otherwise
has no effect.)
$ rm /bin/mail
(You still have it in /bin/lmail.)
$ mv binmail /bin/mail
$ mv /bin/rmail /bin/OLDrmail
$ ln /bin/smail /bin/rmail
(3) For a System V system without sendmail, the steps are:
create a pathalias database by any means available
and copy it to a file named "/usr/lib/uucp/paths"
$ sort -f /usr/lib/uucp/paths -o /usr/lib/uucp/paths
edit defs.h
$ make
$ cp smail /bin/smail
$ mv /bin/mail /bin/lmail
$ mv binmail /bin/mail
$ mv /bin/rmail /bin/OLDrmail
$ ln /bin/smail /bin/rmail
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 2035 ]
then
echo $filename changed - should be 2035 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.README ----------
filename="INFO.README"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.README...
fi
cat << 'END-OF-FILE' > $filename
Brief installation instructions for version 1.0 of smail.
What it 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. If you don't have sendmail, smail will not add or generate
any of the required RFC822 headers (Date:, From:, Message-ID:, Received:)
but your old system didn't generate these either, so you don't lose
anything you already had.
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 detect abuses 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) Simiplicity.
Prerequisites:
You need a copy of a recent posting of pathalias. (The one posted
by Peter Honeyman in January 1986 is recommended.) You'll also
need a current copy of the UUCP map, or at least a copy of the
appropriate part of it that you're interested in. You can get pathalias
from the mod.sources Usenet archive (contact sources-request@mirror.UUCP)
and you can get a UUCP map each month from Usenet newsgroup mod.map.
The UUCP map is quite large (currently about 1.6MB) so please don't ask
to have a copy mailed to you - get a copy from a nearby Usenet site.
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 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.
Installation Instructions:
See the file INFO.INSTALL for step by step instructions.
If you are cbosgd.ATT.COM, you would set
DDATT.COM
If you are a one-machine organization named WIDGET, you might set
DDWIDGET.COM
If you are a PC at the fourth level, named cbpavo.cbosgd.ATT.COM,
sending all your mail to the outside through cbosgd.ATT.COM, set
DDcbosgd.ATT.COM
Of course, the top level might not be COM, other possibilities
include EDU, GOV, or the ISO 3166 2 letter name for your country.
If you want to do any hacking up of sendmail.cf, put the resulting
sendmail.cf in the current directory so it will be copied to /usr/lib.
Save your /bin/rmail and /usr/lib/sendmail.cf somewhere safe, in case
of disaster. If you already have a /bin/smail or /usr/lib/uucp/paths,
you might want to save them too.
Generate /usr/lib/uucp/paths. To do this, edit the Makefile to point
to the directory in which you keep your UUCP map, and type "make paths."
You may want to make local changes first by creating a new "u.Path.*" file
or files. All the u.Path.* and $(UUMAP) files are basically appended
(the order doesn't matter) so you can divide them up into local pieces
of information maintained by different places. Be sure you have the
files u.Path.top and u.Path.uucp in your $(UUMAP) directory.
Compile smail. To do this, type "make".
If you have the logging turned on, you should arrange that something
out of crontab erases the logs regularly, or your disk may overflow.
One line per message is created in /usr/lib/uucp/mail.log. If you
log full messages, they get put in /tmp/mail.log. (Note that full
message logging is considered anti-social if you use it to snoop;
it is recommended that this feature only be used if you are running
software that you don't completely trust, so you can reproduce any
problem that might turn up.)
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 is set by the first executable code, or by the
option from sendmail.cf. 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 latter fails, it will call
sendmail, which will in turn call smail -r, which will apply ALWAYS
routing to get the mail there anyway. 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.)
smail is only called from sendmail, which will call it with the -r
option (see smail.cf.form.) This changes ROUTING to ALWAYS, so that
mail to host!user will look up the best path to host. This is considered
a good, conservative strategy.
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.
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 7752 ]
then
echo $filename changed - should be 7752 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.REGISTRY ----------
filename="INFO.REGISTRY"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.REGISTRY...
fi
cat << 'END-OF-FILE' > $filename
UUCP Zone Registry
7/17/86
To use smail, or other software supporting domain addresses, you
need to have a domain name registered in the domain tree. This
name must be unique in the world, and must be registered with
the appropriate registry.
The exact structure of the domain tree is evolving. In 1984, the top
levels were network names (ARPA, CSNET, BITNET, UUCP, and so on) and
the second levels were hosts. The problem with this structure is that
machines connected to several networks have several names, and it's
difficult for users to predict the address of someone without knowing
their network connections.
In 1986, the domain tree in the USA has three top level domains: COM
for companies, EDU for educational institutions, and GOV for government
entities. Certain other top level names exist: MIL, NET, ORG, but
are somewhat specialized. For the most part, countries other than the USA
are using the ISO 3166 2 letter abbreviation for their country as a top level.
Examples include US for USA, CA for Canada, AU for Australia, JP for
Japan, NL for Netherlands, and UK for the United Kingdom. Some feel
that these abbreviations are cryptic or easily confused with US state
abbreviations, and the UK did get an exception, since their ISO
abbreviation is GB, but the current climate seems to be that no other
exceptions will be made.
One way of looking at the domain tree is that the top level is always
the country, where COM, EDU, and GOV are three pretend "countries" all
located in the USA.
The second level is generally the name of the organization, using the
shortest possible abbreviation that is clear and unique, thus ATT, DEC,
IBM, HP, etc. The choice of exact name is up to the organization, and
longer names, such as Berkeley.EDU or Tektronix.COM are perfectly
acceptable. Just remember that people must type the name, as well as
see it displayed.
Not all countries use the second level for the organization. In
particular, Australia and Britain have set up second level domains
AC.UK and OZ.AU for their academic communities, and put the
organization at the third level.
The third and subsequent levels, if used, should be organizational
units within the organization. Try to keep the number of levels to a
minimum, since people have to type the names. More than four total
levels (country, org, ou1, and ou2) should rarely be needed. The actual
organizational units to be used are up to you, for example, they might
be departments, or they might be machine names. For example, AT&T
is using names like cbpavo.cbosgd.ATT.COM, where COM means AT&T is a
company, ATT is the organization, cbosgd is a machine that is well
known within the company, and cbpavo is a personal computer connected
to cbosgd.
A "zone" is a registry of domains kept by a particular organization. A
zone registry is "authoritative", that is, the master copy of the
registry is kept by the zone organization, and this copy is, by
definition, always up-to-date. Copies of this registry may be
distributed to other places and kept in caches, but these caches are
not authoritative because they may be out of date. An authoritative
answer is required for certain decisions, such as "this mail cannot be
delivered because there is no such domain", or "the name you have
chosen is available and is now assigned uniquely to you."
In the USA, there are currently four zones: DDN (formerly called the
ARPANET), CSNET, BITNET, and UUCP. These zones all share the top level
domains COM, EDU, GOV, etc. The top level domains are administered by
the DDN (Defense Data Network) NIC (Network Information Center) at SRI
(SRI, Inc, formerly Stanford Research Institute, in Menlo Park, CA.)
The CSNET, BITNET, and UUCP registries serve as a go-between to avoid
swamping the NIC with individual registrations. It is possible for an
organization to be members of more than one of these networks, in which
case they register with each network, using the same name on all
networks.
The UUCP Project keeps a registry of members of the UUCP Zone. This
registry is different than the UUCP map, although the registry is
posted as part of this map. The UUCP Zone registry consists only of
organizations which are members of UUCP. To become a member, it is
necessary to explicitly join, just as one joins CSNET or BITNET. Just
being reachable via a bang path does not imply membership, nor does
appearance in the UUCP map.
To join, it is necessary to fill out the application form and send it
to the UUCP Zone registry. The details of joining are not clear at the
time this is being written. Contact us and we'll tell you how to register.
After October 1, 1986, it is likely there will be some sort of fee
to cover administrative overhead of registering a domain name. There
may also eventually be continuing membership dues or a service fee
associated with membership.
See the "Contact Information" below for instructions to contact us;
please use the "query" address for the initial query.
A preliminary application form can be found at the end of this document.
Organizational Registry
If you are registering your organization in the UUCP zone, you are in
effect creating another zone registry for your organization. Any
subdomains of your organizational domain must be registered with you.
(You need not keep us informed of all your subdomains, just the gateways.)
For the time being, unless you are ready to start organizing the machines
in your organization, don't worry about this. You can just set things up
to handle your one machine (or more if you like). Just keep in mind that
your machine is but one machine in your organization, so you should be
planning to have an address like fred@compsci.BigCorp.COM (where "fred" is
a login name on machine "compsci" owned by organization "BigCorp") rather
than fred@BigCorp.COM.
For example, if you are the first host in the University of North Dakota to
join, you are creating a subdomain UND.EDU (for example.) Your host might
have a name like undvax.UND.EDU. When other machines are joined in later,
they will also register under UND.EDU, for example, cs3b20.UND.EDU.
All subdomains of UND (this may mean all hosts in the UND domain) are
registered with the UND.EDU registry. Unless you create a campus organiztion
specifically to run this registry, this means you are the UND.EDU registry.
It is your job to keep track of everybody in the registry, hand out names
for subdomains, make sure there are no duplicates (you have to make sure there
aren't two machines called cs3b2.UND.EDU, for example) and know who to
contact if a problem arises. You have created the UND Zone, which is
similar to the UUCP Zone, but one level further down in the heirarchy.
At some point, you may decide that you want more layers of subdomains in
your zone. For example, if the CS, Math, and Stat departments at UND all
want to manage their own zones, you might use names like vax.CS.UND.EDU,
3b20.Math.UND.EDU, and so on. The UND Zone has delegated its naming
authority to the CS Zone, the Math Zone, and so on. The root delegates
to COM, COM delegates to UUCP, UUCP delegates to UND, UND delegates to CS.
Note that the names are given in upper or mixed case, but the exact
case doesn't matter, since the software ignores it. We recommend that
you choose your capitalization to look nice when printed.
Note also that "vax", "3b20", and the like are terrible host names,
because sooner or later you'll have more than one vax, or more than
one 3b20, and the names will be confusing. We recommend organizational
names, based on the department or project the machine is used for.
Of course, in order to keep the names reasonably short and to avoid
duplicating names in the heirarchy, some compromise will be needed.
For example, csvax.CS.UND.EDU is redundant, but RISC.CS.UND.EDU might
be a good name for the computer used by the RISC project in the CS
department.
Notes:
Organizations are encouraged to eventually support two kinds of electronic
mail addresses:
(1) Login name on machine: a string which is understood on a particular
machine, combined with a fully qualified domain name of a machine.
The string is often, although not always, a login name.
Example:
mrh@cbosgd.ATT.COM
(2) Personal name in organization: a string which is the name of a person,
understood by all gateway machines.
Example:
Mark.R.Horton@ATT.COM
This allows mail to be sent without knowing the full address
of the recipient, only their name and company. Implementations
should be as forgiving as possible of errors in the personal name.
For example, if possible, as many of the following as possible
should be accepted:
mark.r.horton@att.com (ignore case)
m.r.horton@ATT.COM (accept initials)
mark.horton@ATT.COM (don't require initials)
mark.randolph.horton@ATT.COM
m.horton@ATT.COM (if not ambiguous)
horton@ATT.COM (if not ambiguous)
mark.horton.sr@ATT.COM (allow generational qualifier)
However, it's perfectly fine to just support just one style.
Since style (1) is easy to support, you may prefer to just handle
that one, especially at first. Style (1) is by far the most commonly
used method as this is written.
Please note that you should support both RFC 976 and the documents
it refers to, in particular RFC 822 and RFC 920. This means, for
example:
(a) The name "postmaster" on all machines visible to the outside
should be forwarded to the technical contact. This can be
easily done with an alias in /usr/lib/aliases, if your site
runs sendmail. Please be sure to also support Postmaster,
PostMaster, and POSTMASTER.
(b) Your machine should not alter valid RFC 822 headers, such as
From:, of mail it generates or forwards. Many machines running
sendmail have a bug which adds uucpname! to the front of such
addresses. Installing smail will fix the bug, because mail
passed through the machine is not passed through sendmail.
We hope to make a fix to sendmail available, also, at a
later date.
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 better organized.
For queries: uucp-query@cbatt.ATT.COM cbatt!uucp-query
For updates: uucpmap@cbatt.ATT.COM cbatt!uucpmap
For problems: uucp-problem@cbatt.ATT.COM cbatt!uucp-problem
To register: registry@cbatt.ATT.COM cbatt!registry
(Note: as of August 1986, these addresses are on cbatt and cbosgd.
The gateway and aliases are expected to be moved to cbatt shortly.
If you can't get to cbatt, try cbosgd.)
UUCP Zone Membership Application
Please provide the following information to the UUCP Domain Registrar
(registry@cbatt.ATT.COM):
Note: The key people must have computer mail mailboxes and
NIC "Handles", unique NIC database identifiers. If they do not
at present, indicate <NEW> and we'll register them. A NIC Handle may
also be established by contacting REGISTRAR@SRI-NIC.ARPA.
Lines marked with "-->" are the ones you should fill in.
1) The name of the top level domain to join. In the USA, possibilities
are EDU, COM, GOV, and MIL.
--> For example: EDU
Type of Organization (commercial, educational, or government):
--> For example: Ph.D. granting university
--> For example: For Profit Corporation
--> For example: Non-profit Corporation
2) The name, title, mailing address, phone number, and organization
of the administrative head of the organization. This is the contact
point for administrative and policy questions about the domain. In
the case of a research project, this should be the Principal
Investigator. The online mailbox and NIC Handle of this person should
also be included.
For example:
Administrator
--> Organization Alpha Beta University
--> Name John Smith
--> Title Department Head
--> Mail Address Dept of Computer Science
--> 1234 Main St.
--> Hoople, ND. 90292-6695
--> Phone Number 213-555-1511
--> Net Mailbox smith@ALPHA-BETA.EDU, smith@abu.uucp
--> NIC Handle <NEW>
3) The name, title, mailing address, phone number, and organization
of two domain technical contacts. The online mailbox and NIC Handle of
the domain technical contact should also be included. This is the
contact point for problems with the domain and for updating
information about the domain. Also, the domain technical contact may
be responsible for hosts in this domain.
For example:
Technical Contact
--> Organization Alpha Beta University
--> Name Jean Smith
--> Title Researcher
--> Mail Address Dept of Computer Science
--> 1234 Main St.
--> Hoople, ND. 90292-6695
--> Phone Number 213-555-1511
--> Net Mailbox jean@ALPHA-BETA.EDU, jean@abu.uucp
--> NIC Handle <NEW>
Alternate Technical Contact
--> Organization Alpha Beta University
--> Name Fred Rogers
--> Title Computing Staff
--> Mail Address Dept of Computer Science
--> 1234 Main St.
--> Hoople, ND. 90292-6695
--> Phone Number 213-555-1511
--> Net Mailbox rogers@ALPHA-BETA.EDU, rogers@abu.uucp
--> NIC Handle <NEW>
4) The name, title, mailing address, phone number, and organization
of the zone technical contact is the same as the domain technical contact.
(If different, give that information here.)
5) The name of the domain (up to 12 characters). This is the name
that will be used in tables and lists associating the domain and the
domain server addresses. [While technically domain names can be
quite long (programmers beware), shorter names are easier for people
to cope with.]
--> For example: ALPHA-BETA
6) A description of the servers that provides the domain service for
translating name to address for hosts in this domain, and the date
they will be operational. If you prefer to have your Internet mail
forwarded via a gateway other than the default, please change the
entry below. (If there is another RFC 976 compatible gateway nearer
you, you are encouraged to make arrangements with them for forwarding.)
A good way to answer this question is to say "Our server is
supplied by person or company X and does whatever their standard
issue server does".
Our servers are the UUCP nameservers, currently on
SEISMO.CSS.GOV, HARVARD.EDU, and BRL.ARPA. Our preferred
--> mail forwarder is SEISMO.CSS.GOV.
7) Domains should provide at least two independent servers for the
domain. A description of the server machine and its back-up, including:
[LEAVE THIS UNEDITED, UNLESS YOU INTEND TO PROVIDE YOUR OWN ARPANET
NAMESERVERS.]
(a) hardware and software (using keywords from the Assigned
Numbers)
(b) host domain name and net addresses (what host on what net for
each connected net)
(a) hardware and software
VAX-11/780 and UNIX
(b) host domain name and net address
SEISMO.CSS.GOV 10.0.0.25 ARPANET
BRL-AOS.ARPA 192.5.25.82 MILNET
Harvard.EDU 10.0.0.9 ARPANET
8) Gateway machines. Give the UUCP name and domain name of all machines
you intend to make general purpose gateways. This is the machine that
will be running RFC 976 compatible software, such as smail, or other
appropriate software, through which mail should be sent from the
outside. At first, one gateway is probably all you'll need.
For example:
--> abu CS.ALPHA-BETA.EDU
9) Neighbors of gateway machines. List several machines with good solid
UUCP connections to each of your gateways. This will be used to form
pathalias connection information for your host entry on the UUCP map,
although since this information changes often, we encourage you to
send us regular updates. If you can format this for pathalias, please do
so, instead of giving the version not formatted for pathalias.
For example (not formatted for pathalias):
--> abu ihnp4, ucbvax, dgu
For example (formatted for pathalias):
--> abu ihnp4(DEMAND), ucbvax(DAILY), dgu(DIRECT)
10) Name (and Title, Postal Address, Electronic Address, Telephone, and
NIC Handle, where different from above) of technical contact person for
each gateway.
--> abu, Jean Smith
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 16854 ]
then
echo $filename changed - should be 16854 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.SENDMAIL ----------
filename="INFO.SENDMAIL"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.SENDMAIL...
fi
cat << 'END-OF-FILE' > $filename
SMAIL MODIFICATIONS FOR SENDMAIL.CF FILE
Note: most sites should be able to use the standard UUCP sendmail.cf
file included with this distribution. This information is presented
for those who need to strike out on their own.
For UUCP Zone Addressing, there are 5 major changes to the standard
sendmail.cf file:
[1] Prevent butchering of UUCP addresses. The sendmail.cf internal
notation of host!user becomes user@host.UUX instead of user@host.UUCP.
We now interpret user@host.UUCP to imply routing and user@host.UUX
to imply a direct neighbor. These are the new lines:
(ruleset S4)
# UUX must always be presented in old form
R$+@$-.UUX $2!$1 u@h.UUX => h!u
(ruleset S3)
# convert old-style addresses to a domain-based address
R$+%$+ $@$>6$1<@$2> user%host
R$+^$+ $1!$2 convert ^ to !
R$-!$+ $@$>6$2<@$1.UUX> resolve uucp names
R$+!$+ $@$>6$2<@$1> domain!host
[2] In resolution part of ruleset 0, resolve UUX addresses and domain
addresses as follows:
# resolve names we can handle locally
R<@$+.UUX>:$+ $#uux$@$:$1!$2 @host.uux:user
R$+<@$+.UUX> $#uux$@$:$2!$1 host!user
R$*<@$*>$* $#dom$@$:$1@$2$3 user@anywhere
[3] Change the UUCP mailer definition to the following:
Muux, P=/bin/smail, F=sDFMhum, S=13, R=23, M=100000,
A=smail -vkH$j $u
Mdom, P=/bin/smail, F=sDFMhum, S=13, R=23, M=100000,
A=smail -vH$j $u
S13
R$+<@$-.UUX> $@$2!$1 u@host.UUX => host!u
R$*<$*.$=S>$* $@$1<$2.$3.$D>$4 externalize
R$*<$*>$* $@$1<$2>$3 already ok
R$+ $@$1<@$j> tack on our name
S23
[4] Recognise local host names using the =D class instead of an explicit
list:
(at local definitions)
# domain
DDUUCP
CDUUCP LOCAL UUX
(in zerobase)
# now delete the local info
R$*<$*$=w.$=D>$* $1<$2>$5 thishost.topdom
R$*<$*$=w.$D>$* $1<$2>$4 thishost.domain
R$*<$*$=w>$* $1<$2>$4 thishost
R$*<$*.>$* $1<$2>$3 drop trailing dot
R<@>:$* $@$>0$1 retry after route strip
R$*<@> $@$>0$1 strip null trash & retry
[5] Put something in the version number so we know who's converted.
This version looks like this:
DV1.00.UUCP-MOD.8-11-85
---
/+\
8/11/85 +\ chris@cbosgd.att.uucp
\+/
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 2138 ]
then
echo $filename changed - should be 2138 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.SMAIL.8 ----------
filename="INFO.SMAIL.8"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.SMAIL.8...
fi
cat << 'END-OF-FILE' > $filename
.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 two links to the same program.
.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 only hands 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.
.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 \-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 \-p " pathfile"
Set path database file name if not /usr/lib/uucp/paths.
.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 reconised.
.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
The above four 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.
.SH MAIL FLOW
To
.I smail/rmail
there are two types of mail: UUCP mail handled by
.IR uux (and
.IR uuxqt ),
and local mail handled by the local mailer (e.g.
.IR sendmail " or"
.IR /bin/mail ),
like this:
.sp
uux -> rmail -> local mailer
.br
-> uux
.sp
local mailer -> smail -> local mailer
.br
-> uux
.PP
There is a possible path "uux -> rmail -> local mailer -> smail -> uux".
The
.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 machanisms.
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 intepret 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 1 period.
Like the old
.I /bin/rmail,
.I smail/rmail
gives precedence to ! over @ when parsing mixed addresses.
.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 degress 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
Sometimes a domain specification is not complete, so
.I smail/rmail
matches it against the local domain name, appending the implied part.
If nothing matches, it appends the last component (top level) of the
local domain. Examples help. If the local domain is "osgd.cb.att.uucp":
.PP
ucbvax.uucp -> ucbvax.uucp (already complete)
.br
p4.ihn.att -> p4.ihn.att.uucp (att matched)
.br
pavo.cb -> pavo.cb.att.uucp (cb matched)
.br
politik -> politik.uucp (nothing mached)
.PP
Notice that all the completed domain specifications end in the top
level "uucp".
.I Smail/rmail
separates this top level name from the rest of the string, so that entries
in the routing table needn't include it.
When partial resolution fails,
.I smail/rmail
finally tries routing to the top level name, in this case "uucp".
.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
After
.I smail/rmail
resolves an address, it reparses it to see if it is now a UUCP path or
local address, complaining if somehow the route turns out to be another
domain address, because we don't like to resolve more than once.
This error occurs when an address partially resolves the local 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.
.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 FILES
/usr/lib/uucp/paths ascii path database
.br
/usr/lib/uucp/paths.pag,.dir dbm(3) path database
.br
/usr/spool/uucp/mail.log log of mail
.br
/tmp/mail.log record of mail
.SH AUTHOR
Christopher Seiwald
.br
chris@cbosgd.att.uucp
.SH VERSION
@(#)smail.8 1.3 (UUCP-Project/CS) 11/14/85
.SH "SEE ALSO"
.IR uux (1)
.br
.IR sendmail (8)
.br
.IR binmail (1)
.SH BUGS
Should handle wild addresses such as "user@host@localhost", instead of
punting after not being able to resolve in one pass.
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 7659 ]
then
echo $filename changed - should be 7659 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.TODO ----------
filename="INFO.TODO"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.TODO...
fi
cat << 'END-OF-FILE' > $filename
8/11/85
This software has been running on cbosgd since June 1985, and is
considered very stable. It has also run on politik, greipa and
other machines as beta test sites. While it seems to be stable, it's
really just the beginning. We expect to find more problems as more
of the UUCP world becomes able to support domains.
You will no doubt find problems, and hopefully solve some of them.
Please let us know about any fixes or improvements you make, we
want to include them.
There are no doubt still many things to be done. Here are some
that come to mind.
(software)
It would be useful if incoming UUCP mail in the ! notation
were usefully converted into true domain information. Right
now, we get mail from foo!bar!mumble!bletch!user and it just
gets turned into bar!mumble!bletch!user@foo.UUCP. It would
be nice if it got turned into user@bletch.dom.UUCP instead.
(This may matter less and less as this software catches on.)
It would be nice to have something to examine the logs smail
creates and generate some summary statistics.
It might be useful to have a hook to selectively turn off
forwarding of mail for certain (senders, destinations, users,
machines, whatever) so if your machine is being abused, you
can force the abusers to route mail some other way.
Porting to other environments is always needed. Especially
of interest would be a port to an environment with no sendmail.
You would have to address the issue of mail headers, which smail
doesn't look at.
The issue of whether this will work decently in a world made
up of .COR, .EDU, .GOV, and .country domains (no explicit .UUCP or
.ARPA top level domain) will require some evolution. While it
has been running on cbosgd.ATT.COM (with only UUCP connections)
for 3 months, and appears to work well, it's in an environment
where most of the rest of the world calls itself .UUCP. As the
world evolves there may be adjustments needed.
(administrative)
The UUCP map needs to be more widely available. Right now you
can get it from any of the machines that are advertising that
they have a copy on line, often in ~/uumap/*. Such machines
include usenix (the master copy), cbosgd, and seismo. A cleaned
up version is posted monthly to Usenet newsgroup mod.map.
Sites not on Usenet may have trouble getting the map.
The UUCP map needs to be cleaner. Currently there are quite
a few duplicate machines, and sometimes a few syntax errors
or other major semantic errors creep into the ~/uumap copies.
The map is being cleaned up as the available manpower permits.
The map needs to be partitioned into reasonable pieces that
correspond to the domain tree structure. This can't happen
until the tree structure exists.
(documentation)
As always, there is plenty of work to do here.
We have a draft document that tells what the domain data
is all about, but this is rather vague (given the fact
that the domain tree itself is rather vague) and it
can no doubt be improved.
(other)
Related tools are always useful. We have modifications for MH,
from Larry Auton, to handle domains. We don't have similar
mods to Mail, although I'm not currently convinced they are
needed.
Perhaps sendmail.cf should be factored into the various pieces
that 4.2BSD comes in, that is, the various include files, so
that people can modify one and generate the whole thing.
A simple modification to sendmail.cf that those other sites
out there that add myname! to the From: line (in violation
of RFC822) would be most appreciated. Upgrading to smail
from 4.2BSD is a big enough undertaking that it would be nice
if people could fix their bug that bothers us without them having
to take the plunge all at once.
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 3734 ]
then
echo $filename changed - should be 3734 bytes, not $size bytes
fi
chmod 644 $filename
fi
# ---------- file INFO.TROUBLE ----------
filename="INFO.TROUBLE"
if [ -f $filename ]
then
echo File \"$filename\" already exists\! Skipping...
filename=/dev/null # throw it away
else
echo extracting file INFO.TROUBLE...
fi
cat << 'END-OF-FILE' > $filename
Common Problems and Recommended Solutions
Updated 6/29/86
(1) The configuration shell script smail.cf.sh insists that
I give it another domain that I'm authorative for, but we
don't have anything to give it.
This is a common problem for small companies that only
have one machine, or for organizations that are originally
registering in COM/EDU/GOV and were never known in UUCP.
The shell script is somewhat simple - it really should let
you just hit RETURN here. But you can go ahead and follow
the examples anyway, and it shouldn't hurt anything.
For example, if you're FOOBAR.COM:
Enter This Host's Name:
foobar
Enter This Host's Official Domain:
COM
Enter Any Equivalent Domain Classes:
foobar
Enter Any Domains For Which This Host Is An Authority:
foobar.UUCP
The first two lines mean that you are user@foobar.COM (the two
entries strung together.) The second one means you also
undersatnd what to do with user@foobar, which isn't really
legal but may tend to drop up from time to time. The last
means you also understand user@foobar.UUCP, which is important
for upward compatibility since that's commonly generated by
other systems, by netnews software, and the like.
(2) I can send mail to others OK, but sometimes when they send mail
to me or I send mail to others on my machine, it doesn't work.
It says "couldn't resolve myhost.mydom!user".
This is probably a configuration problem. Look in defs.h to see
how you have MYDOM set. It comes distributed as ".UUCP", but
you probably want to change this to the answer to the "Enter This
Host's Official Domain" question above. If you don't run sendmail,
this is the only way smail has of knowing your host name.
(We really should have smail read this in from a file, for future
3rd party binary distributions, but so far we haven't.)
(3) Mail isn't getting through sometimes, and since I just installed
this new software, I suspect it. Or, I see munged header lines, and
I don't know who is doing it.
If you aren't sure where the mail is getting dropped (remember, UUCP
is an unreliable transport mechanism, so lots of things could be going
wrong) here's a trick we sometimes use to find out what's going on.
mv /bin/rmail /bin/realrmail
cat > /bin/rmail
#! /bin/sh
umask 0
LF=/usr/spool/uucp/rmail.log
cat > /tmp/rm$$
echo " " >> $LF
date >> $LF
echo rmail $* >> $LF
cat /tmp/rm$$ >> $LF
realrmail $* < /tmp/rm$$
st=$?
rm /tmp/rm$$
exit $st
^D
chmod 755 /bin/rmail
This will keep a very verbose log of all incoming traffic into your
machine in LF, including the text as it arrived on your machine, and
the arguments to rmail. You can tell whether it was broken when it
arrived or if you broke it, and you can reproduce the mail by editing
out the message (into, say, /tmp/msg) and running
realrmail args < /tmp/msg
using the args as they appear in the file.
Some words of warning. (a) These files can get big very fast if you
process much traffic through your machine, so be sure to clean them
out often. (b) This saves everything, including the message body.
It is unethical to browse such logs unless a specific problem has
arisen which requires you to check the log. This is one reason why
it's kept in /usr/spool/uucp, if you have a hidden directory on your
system that's even better. (c) This extra set of file copies adds
overhead to your machine, so don't run this unless you suspect you
have a problem, and then take it out when you trust things again.
There is a RECORD option in the code which is similar, but this
option saves the mail at a later stage, so you lose some information
about how it arrived on your machine.
(4) I don't understand how to set up subdomain of my domain.
There are two ways to do this. The easiest is just by recognizing
the subdomain host by their UUCP name. If you are the gateway for
domain FOO.COM, then any mail through your sendmail to bar.FOO.COM
or to bar.myname.FOO.COM (where "myname" is your hosts's name) will
be treated as if it were bar.UUCP, so if the name "bar" is in your
path file, you're all set. The disadvantage to this is that if you
want to create a subdomain whose name conflicts with a public name,
it won't work. If you want to disable this code, look for "mydom"
in the sendmail.cf.
A perhaps cleaner way is to explicitly put the subdomains into the
pathalias database. Thus, if you have a.FOO.COM, b.FOO.COM, p.b.FOO.COM,
x.myname.FOO.COM, and y.myname.FOO.COM, you could include this in
your local pathalias input:
aname .a.FOO.COM
bname .b.FOO.COM
pname .p.b.FOO.COM
xname .x.myname.FOO.COM
yname .y.myname.FOO.COM
In each case, "aname" is the UUCP name for host "a", etc. This
sort of says "aname and a.FOO.COM are the same host." This
description says that you have subdomains x and y under your host,
that there are peer subdomains a and b, and that you know about
a subdomain of b called p. Other subdomains of a and b that
are not mentioned here will be routed through aname or bname as
gateways. The only reason to mention p here would be if we have
a direct link and want to avoid routing through bname. If you
do this, you have less strict requirements about name uniqueness:
aname, bname, pname, xname, and yname must still be unique, and
a.FOO.COM, b.FOO.COM, p.b.FOO.COM, x.myname.FOO.COM, and
y.myname.FOO.COM must also be unique (ignoring case, so that
two different hosts a.foo.com and A.FOO.COM conflict.) In
particular, this means that if you have a local host with a name
that isn't unique, say "bilbo", you can safele create a subdomain
"bilbo.myname.FOO.COM", but you'll still have a problem if the
UUCP name of the host is "bilbo". You may be able to make this
partly work using the pathalias "private" notation, but we advise
you to change the UUCP name to something unique.
(5) When another host in my domain sends mail to a third host in my
domain, it seems to get routed through the gateway even though
my host knows how to route directly.
For example, suppose you have gateway cbosgd.att.com, and other
machines foo.att.com and bar.att.com. Smail is installed on all
three machines. But when a user on foo sends to user@bar.att.com,
the mail is routed via cbosgd. Sometimes, you may even see this
happen for mail on foo to foo.
There are two solutions. The first is to make sure that foo knows
that bar.att.com is the same as bar (where "bar" is the uucp name.)
Include lines in the local pathalias input files like
foo .foo.att.com
bar .bar.att.com
cbosgd .cbosgd.att.com
The second solution is to declare foo to be a gateway for your
subdomain, e.g.
foo .att.com
This will handle all mail to att.com locally on foo instead of
routing it through cbosgd. (It also means you'd better be sure
to keep the routing tables on foo as up to date as on cbosgd.)
The first method is strongly recommended for everyone. The second
is appropriate only for well maintained and supported hosts.
Either should handle the problem.
(6) Mail to some domains isn't working. For example, if I type
smail -d USER@LLL-MFE.ARPA
It says:
parse address 'USER@LLL-MFE.ARPA' = USER @ LLL-MFE.ARPA (2)
getpath 'LLL-MFE.ARPA' failed
USER@LLL-MFE.ARPA...couldn't resolve LLL-MFE.ARPA.
resolve 'USER@LLL-MFE.ARPA' = USER @ LLL-MFE.ARPA (0)
There is a .arpa line in the pathalias database that looks like:
.arpa ihnp4!akgua!gatech!seismo!%s
Chances are the pathalias database is out of order. Remember
to run it through "sort -f" before storing it.
(7) People on the ARPANET are complaining about us sending them mail
from FOO.COM when we aren't on the ARPANET.
Tell them to upgrade their mail system to support MX records.
If you have a COM, EDU, or GOV name confirmed by the UUCP Zone,
you have an oficially allocated name which you are entitled to
use. However, the old way of handling things on the ARPANET was
to open a connection directly to the destination host and send
the mail via SMTP. Many hosts assume that a name ending in ARPA,
COM, etc implies being on the ARPANET, and handle mail this way.
(4.3BSD still does this.) An RFC approved in January 1986 says
that mailers are supposed to check for an MX record, which says
that mail for one domain should be delivered to a different host
to be forwarded. As of August, 1986, very few ARPANET hosts have
mailers that understand MX, and the standard UNIX and TOPS 20
mailers don't support it. So politely urge them to find whoever
supports their mailer and get it upgraded to support MX. (Berkeley
has a version of sendmail that supports it, but it isn't in 4.3BSD.
The latest MMDF also supports it.) In the meantime, tell whoever
is trying to send you mail that mail to user@foo.COM (for example)
can be sent to foo.COM!user@seismo.CSS.GOV.
END-OF-FILE
if [ "$filename" != "/dev/null" ]
then
size=`wc -c < $filename`
if [ $size != 9205 ]
then
echo $filename changed - should be 9205 bytes, not $size bytes
fi
chmod 644 $filename
fi
echo done
exit 0