1) Register a domain name.  Even on UUCP, where <machine>.UUCP is often
   used as a kludge, it is MUCH preferred that you obtain a real
   domain address.  If you are directly connecting to the Internet,
   you will get one as part of your registration with the NIC.

   If you aren't connecting directly to the Internet, obtaining a
   registration will usually require you finding a nearby friendly
   Internet site willing to act as a mail forwarder to you from
   the Internet - the site that will set up a "MX record" for you.
   Many sites will do this for you for free, and several of the
   commercial email services (eg: uunet) will do it for you for a
   nominal charge (without requiring you buy the rest of their
   services).

   There are occasions where you can join what is called a "domain
   park".  These are most often small regional groups of systems that
   have gotten one of their number properly registered as a domain,
   and provides forwarding services out to other systems.  For
   example, in my address "ferret.ocunix.on.ca", "ocunix.on.ca"
   is a domain park made up of the Ottawa-Carleton UNIX User's Group,
   one of the other machines in the group provides a gateway between
   our systems and the Internet.

2) If your machine is going to "speak" UUCP to the outside world,
   choose a unique UUCP name.  You can find out whether a name you
   want is taken by consulting the UUCP maps.  Or by asking someone
   else who's using them.

3) Register your machine with the UUCP Mapping Project if you're going
   to use UUCP.  Information on how to do this is included in the
   monthly maps postings in the file "README".  This is usually only
   required when your machine talks UUCP to the outside world, or when
   other machines have to address you by your UUCP name.  If you don't
   do this, somone else may choose the same name, and gross confusion
   will arise when smart routers won't be able to tell whether to send
   a piece of mail to you, or your doppelganger[s].  If you register
   with the UUCP Mapping Project, you have prior use, and people who
   choose the same name afterwards will be told to get a new one.
   
   If you're "behind" an organizational gateway, don't do this.
   (Your organizational gateway is the thing that needs to be
   registered)

   If you do fill in a map, please take the time to fill it in
   carefully, giving contact people and phone numbers.  Just in
   case your machine goes crazy and starts doing something nasty.
   Note expecially the latitude and longitude.  Get it right,
   or omit it.  Brian Reid gets really annoyed with sites that
   are half a world away from where they really are.

4) If you're going to be setting up multiple machines, have only
   one or two connections to the outside world.

5) Install a mail system that understands domain addressing, even
   if you aren't registered.  (In fact, all of the suggested
   configurations in this FAQ do)

6) *Never* use UUCP bang-routing with the MUA if you can possibly
   avoid it - each of the suggested mail configurations provide
   mechanisms where you, the user, do not have to specify routes 
   to the MUA - you can specify domains, and the TA will do the
   routing (possibly bang-routing) for you.

   Important: many mailers that understand UUCP attempt to be
   pedantically "UUCPish" in the construction of headers, such
   as generating "bang routes" in From:/To: etc. lines.  Which,
   given that the whole "mail network" is generally converging on
   more Internet-like standards, and that even UUCP sites are
   using fully domain-capable mailers, is a big mistake.  RFC976
   attempts to codify a "meta standard" that allows the coexistance
   of RFC822 (Internet mail) with UUCP-based networks.  What
   this means is, essentially, that headers are formed in the
   SMTP form, even if the transport will be via UUCP.  Unfortunately,
   however, many mailers insist on "UUCP-izing" perfectly useable
   Internet/domain headers.  "Fixing" them to prevent this is sometimes
   difficult.  Sendmail is almost always a problem in this regard.

7) Find a friendly neighboring SA to help.  A SA who has already
   operating mail in your area will help smooth over the regional
   "gotchas" that are bound to crop-up.  And advise you on the
   right software to use, where to obtain it, and how to install it.

8) Do NOT use "any old" Map unpacking program.  Most available
   map unpacking programs automatically run the shell (or shar)
   to unpack map articles.  Since it is trivially easy to forge
   map articles, using this type of unpacking program can
   easily let very destructive trojan horse or virus programs
   into your machine.

   The two specific map unpackers described in this FAQ are known
   to be secure from such attacks.  Do not run any other unpacker
   unless you are aware of the issues and can inspect the code for
   such vulnerabilities.  [If you know of other "secure" map
   unpackers that are generally available, please let me know]

9) If the people on your site, or small network, receive mailing
   lists, it's often a good idea to gateway them to news:

   Netnews often performs many of the same services as email.
   The primary difference is that messages are centrally stored,
   rather than delivered to individual's mailboxes, and that
   distribution looks more like a broadcast then a set of point-to-point
   communications.  This means usually means that news can handle more
   volume, more efficiently, then email can.

   Because of the differences (and also the similarities) people often
   want to tie news and mail together.  This is known as "gatewaying."
   For example, a small software development site might subscribe to the
   X Windows mailing list.  Rather than have (say) eight copies of each
   mail message sent to their host, they would rather have it stored as a
   local newsgroup that everyone in the company can read, and which can
   be centrally archived.  This is a typical use of a "mail to news"
   gateway.  When a user makes a posting to this local group the article
   should be sent back out to the mailing list; this is a typical use of
   a "news to mail" gateway.

   On a larger scale, the "inet" groups are bi-directional gateways of
   Internet mailing lists.  Within mainstream Usenet, many popular
   groups such as comp.windows.x, comp.protocols.tcp-ip, comp.unix.wizards,
   and so on, are gatewayed to mailing lists and back.

   Many subtle issues often come up when gatewaying mail and news, so
   unless you are experienced you should use one of the already-available
   packages for your local organization.  For example, you probably do not
   want to write a brand-new Perl script and create a new "inet" newsgroup.
   The C News distribution includes some basic gateway tools in the
   contrib/nntpmail directory.  Many people use Rich $alz's "newsgate"
   package that appeared in comp.sources.unix Volume 24; it includes
   discussion of some of the more subtle issues that come up.

   Before starting a mailing list gateway, apart from the technical aspect
   of the job you should also be aware of one important point: mailing-lists
   are considered private, whereas newsgroups are public.
    
   One can know who gets a list, but not who reads the group. It is always
   wise to get the authorization of the mailing-list manager and of the readers
   before creating a mail/news gateway.

10) If you're connecting to the Internet, or are setting up a large local
   internet, you really should get a copy of the DNS and BIND book mentioned
   in the bibliography.