
NAME
	UULIB:Domain

SYNOPSIS
	-

DESCRIPTION

	The UULIB:Domain file holds routing information for addresses
    you send USENET mail to.  This file is normally required ONLY if
    your machine can talk to MORE THAN ONE USENET host.

	For machines that can talk to ONLY ONE USENET host, you need
    only set the 'DefaultNode' entry in UULIB:Config to the name
    of the one host.

	A domain is something like 'CTS.COM' or 'BERKELEY.EDU'.  Lets
    say you have direct USENET connections to UCBVAX.Berkeley.EDU and
    FUBAR.CTS.COM.

	Now, you want to send an email message to CHARLIE.Berkeley.EDU
    and another email message to GALAXY.CTS.COM ... obviously you will
    want the first message to be routed through UCBVAX and the second
    routed through FUBAR.  The appropriate domain entries would be:

    *.berkeley.edu  MF	UU  ucbvax.UUCP
    *.cts.com	    MF	UU  fubar.UUCP

    You will also want a default of some sort ... say you send mail
    to PHOTON.CSNET, you want unknown domains to be routed to somewhere
    that knows how to deal with them.  So you would also have another
    entry in UULIB:Domain:

    *		    MF	UU  ucbvax.UUCP

    That specifies the machine to route mail through to reach an
    unknown address.

    *** NOTE *** UUCP sites that you directly connect to need not be listed
    in UULIB:Domain, the UULIB:L.Sys file is automatically scanned for such
    sites.  For said machines any additional domain information is ignored
    (such as .UUCP).  In case the name of an immediately adjacent UUCP site
    conflicts with another site you can enter that other site into the domain
    list explicitly using the MD Type described below.

			FORMAT OF DOMAIN FILE

    Each line in the domain file may be blank, contain a '#' and then
    a comment, or contain a domain record.  Each domain record is broken
    up into four fields:

    Domain Type Class Address-Info

    Domain = domain in question, you may use '*' instead of a domain
	     name to match ONE OR MORE SUBDOMAINS or the machine name.
	     Case is ignored.

	     For example:   *.COM
			    *.Berkeley.EDU
			    *

    Type   = MF or MD.	MF stands for mail forwarder, MD stands for
	     mail destination.	The difference can be shown with an
	     example:

	ucbvax.berkeley.edu  MD UU  ucbvax.UUCP
	*.berkeley.edu	     MF UU  ucbvax.UUCP

	In the first case the domain is actually a complete machine
	name which we can directly talk to, thus MD is used telling
	the mail system that we REPLACE the address with this address.

	In the second case the machine is what we must go THROUGH to
	reach machines with the given domain (note that more explicitly
	specified domains always have priority of less explicitly
	specified domains).  The mail system will PREPEND the address
	field with the forwarding machine address.

    Class = UU
	Currently only UU, meaning USENET class, is supported.	This
	field is reserved to allow specification of different types
	of low level mailers so the mail system is not necessarily
	limited to using the USENET as the transport layer.

    AddrInfo
	for the UU class AddrInfo contains a ! separated UUCP path
	where the first machine MUST be an immediately adjacent node.
	The remainder of the path is tagged onto the rmail line along
	with the original path specification.

	NOTE:	For any machine in the bang (!) path of the AddrInfo
	field which is directly connected to the previous machine
	(the first machine is always directly connected to your
	machine), the domain is optional.  That is, the machine may
	be listed with or without a domain separated by dots.  The
	examples below show parts of paths both with and without
	domain names.

	when you route through the INTERNET, however, you must be
	more careful.  Only known USENET paths may be addressed
	without worrying about the domain part of the machine name.

			REGISTERED DOMAINS

    We will eventually have our own domain that is registered with the
    network community.	When this occurs we will probably set up an
    automated system that keeps everybody's UULIB:Domain file consistant.
    Each UULIB:Domain file will then have an entry for all machines in
    our domain.  Thus, while UULIB:Domain is not being used so much at
    the moment I expect it will be used in a major way in the future.


ADDRESSES IN A SMALL ISOLATED NETWORK

    Using the UULIB:Domain file in local networks drastically
    simplifies most other parts of the UUCP mail system.  The
    greatest advantage of using a Domain file is that you can
    refer to machines in your local net by name rather than by
    path and can refer to them by name in any groups you might
    have constructed in UULIB:Aliases.	you can also use the Domain
    file to re-route email to machines that may have moved to
    somewhere else in your local network (say a buddy moves back
    east) without bouncing the email.  Which we can't do anyway yet..
    automatic bouncing will be in a future release.

    Lets say you have a group of people all running UUCP connected
    like this:
			       d
			      /   f
			     /	 /
			a---b---c---h
		       /     \	 \
		      /       \   g
		     x	       e

    If your machine is b.UUCP and you want to email to user@h.UUCP,
    then the appropriate path is:

	    To: c!h!user

    If your machine is d.UUCP and you want to email to g.UUCP,
    then the appropriate path is:

	    To: b!c!g!user

    There is another alternative.  You can setup your UULIB:Domain
    file with all of these paths and just say:

	    To: user@g.UUCP

    The Domain file would be different for each node but you have
    removed the complexity one step.  The Domain file for a.UUCP
    would look like this:

	    *	    MF UU   b.UUCP

    This assumes that b.UUCP also implements Domains.  The Domain
    file for b.UUCP would look like this:

	    *	    MF	UU  c.UUCP
	    x.UUCP  MF	UU  a.UUCP

    Because, apart from x.UUCP, the only nodes b.UUCP cannot reach
    directly are reachable via c.UUCP.

    The Domain file for c.UUCP would be:

	    *	    MF	UU  b.UUCP

    Because the only nodes c.UUCP cannot reach go through b.UUCP,
    so we set the default route for unknown nodes to go through
    b.UUCP.  Here we assume that b.UUCP uses UULIB:Domains as
    well and knows how to get to x.UUCP which is not immediately
    adjacent to it.

    The Domain file for c.UUCP assuming the b.UUCP does NOT use
    a Domains file (which is safest actually) is:

	    *	    MF	UU  b.UUCP
	    x.UUCP  MF	UU  b.UUCP!a.UUCP

    Alternately you can use MD (mail destination):

	    *	    MF	UU  b.UUCP
	    x.UUCP  MD	UU  b.UUCP!a.UUCP!x.UUCP

ADDRESSES IN A SMALL NETWORK WITH A SINGLE CONNECTION TO THE OUTSIDE WORLD:

			       d
			      /   f
			     /	 /
			a---b---c---h---ucbvax.berkeley.edu
		       /     \	 \
		      /       \   g
		     x	       e

    This is another possible configuration... one person in your
    little Amiga network has a connection to the outside world.
    In this case everyone in your network should have UULIB:Domain
    entries to properly route email back and forth. Specifically, if
    you are giving somebody your email address and your machine is
    x.UUCP, you want to be able to give them:

	    ucbvax.berkeley.edu!h!x!user

    As your address rather than

	    ucbvax.berkeley.edu!h!c!b!a!x!user

    In otherwords, you want to HIDE your local network from the
    outside world.  This would require h.UUCP to have the
    following UULIB:Domain file:

	    *	    MF	UU  ucbvax.berkeley.edu
	    a.UUCP  MF	UU  c!b
	    b.UUCP  MF	UU  c
	    d.UUCP  MF	UU  c!b
	    e.UUCP  MF	UU  c!b
	    f.UUCP  MF	UU  c
	    g.UUCP  MF	UU  c
	    x.UUCP  MF	UU  c!b!a

    Each of the other nodes in the network would have a similar
    Domain file.  Note that when you have a connection to the
    outside world the default, '*', should point to the outside
    world.  The '*' entry for a.UUCP, for example, would be:

	    *	    MF	UU  b!c!h!ucbvax

    If everyone in your local net implemented '*' properly it
    would suffice to redirect '*' to, say, just b.UUCP, and b.UUCP
    would direct it to c.UUCP, etc...  The cleanest way to deal
    with it is actually to redirect it to the last node in your
    local net that talks to the outside world:

	    *	    MF	UU  b!c!h

    This allows the sysop at h.UUCP the latitude to do further
    routing.  For example, what if h.UUCP was able to connect to
    two machines on the outside world!

			      ucbvax.berkeley.edu
			     /
			----h
			     \
			      pacbell.pacbell.com

    In this case you want to give h.UUCP the latitude to redirect
    email to the .pacbell.com domain to pacbell.pacbell.com
    instead of going the long path through ucbvax.berkeley.edu ...

	    *		    MF	UU  ucbvax
	    *.PacBell.COM   MF	UU  pacbell

    Thus, all the other nodes in your local network should direct
    unknown addresses through h.UUCP rather than bypass h.UUCP's
    domain system by giving an explicit route through it.

