home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / mail / setup / unix / part1 next >
Encoding:
Internet Message Format  |  2002-08-10  |  28.4 KB

  1. Message-ID: <mailfaq.1_1028869201@ferret.ocunix.on.ca>
  2. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!howland.erols.net!torn!qcarhaaa.nortelnetworks.com!bcarh189.ca.nortel.com!zcarh46f.ca.nortel.com!ferret.ocunix.on.ca!not-for-mail
  3. Date: 9 Aug 2002 05:00:02 GMT
  4. Supersedes: <mailfaq.1_1026968401@ferret.ocunix.on.ca>
  5. Expires: 13 Sep 2002 05:00:01 GMT
  6. Subject: NEW! UNIX Email Software Survey FAQ [Part 1 of 3]
  7. From: clewis@ferret.ocunix.on.ca (Chris Lewis)
  8. Newsgroups: news.admin.misc,comp.mail.misc,news.answers,comp.answers
  9. Followup-To: poster
  10. Reply-To: mailfaq@ferret.ocunix.on.ca (Mail FAQ commentary reception)
  11. Summary: How to set up Email on UNIX systems.
  12. Approved: news-answers-request@mit.edu
  13. Keywords: mail software survey UNIX FAQ
  14. Organization: eh?
  15. Lines: 629
  16. Xref: senator-bedfellow.mit.edu news.admin.misc:78490 comp.mail.misc:66487 news.answers:235643 comp.answers:50968
  17.  
  18. Archive-name: mail/setup/unix/part1
  19. Last-modified: Mon Feb 21 09:57:01 EST 2000
  20.  
  21.         UNIX EMail Software - a Survey
  22.                Chris Lewis
  23.         clewis@ferret.ocunix.on.ca
  24.         [and a host of others - thanks]
  25.  
  26.         Copyright 1991-1998, Chris Lewis
  27.  
  28.         Redistribution for profit, or in altered content/format
  29.         prohibited without permission of the author.
  30.         Redistribution via printed book or CDROM expressly
  31.         prohibited without consent of the author.  Any other
  32.         redistribution must include this copyright notice and
  33.         attribution.
  34.  
  35. Note to the patient readers who noticed that nothing has changed in this
  36. FAQ since 1996...
  37.  
  38. Email systems have changed radically over the past few years, and I'm
  39. beginning the daunting task of bringing this FAQ into the new world.
  40.  
  41. I'm planning a lot of changes: 
  42.     - Adding POP/IMAP discussions, and common implementations
  43.     - Extensive coverage of anti-spam measures resources, and
  44.       packages.
  45.     - Updating recommendations to include things like the phase out
  46.       of UUCP, predominance of POP/SMTP/MIME etc., S/Mime, PGP
  47.       etc.
  48.     - Other suggestions?
  49.  
  50. I've started off the ball by mostly changes in the second and third parts:
  51.  
  52.     - updated sendmail
  53.     - dropped IDA sendmail references.
  54.     - dropped EASE references
  55.     - begun the deprecation of obsolete solutions (UUCP, UUCP maps etc)
  56.     - added exim.
  57.     - added qmail.
  58. |    - updated MMDF
  59.  
  60. It would help a lot if anyone wanting to add a section on their favourite
  61. email topic (UNIX please!) could write it and send a copy to me.  I'll also
  62. be dredging through my archives to find previous comments that haven't yet
  63. been added.
  64.  
  65. Changes are marked with a preceding "|".  You can skip to them
  66. by typing g^| in (most) newsreaders.
  67.  
  68. Note: this FAQ has been formatted as a digest.  Many newsreaders
  69. can skip to each of the major subsections by pressing ^G.
  70.  
  71. Please direct comments or questions to mailfaq@ferret.ocunix.on.ca -
  72. note Reply-to: line - automatic if you reply to this article.
  73.  
  74. Many changes made in the second and third parts.
  75.  
  76. ------------------------------
  77. Subject: Introduction
  78.  
  79. Configuring electronic mail systems can be quite a complicated
  80. subject.  Often far more complicated than, say, setting up
  81. a Usenet news feed.  This is because, unlike news, email is
  82. expected to traverse multiple types of networks using their own
  83. protocol, whereas, Usenet news tends to be a single protocol
  84. supported by hook or by crook on different networks.
  85.  
  86. This document is intended for system administrators who need to
  87. know how to set up their UNIX systems for email communication with
  88. the outside world.  It is intended for the email-naive SA
  89. who gets more than a little confused by the acronyms, RFC's and
  90. plethora of software.
  91.  
  92. This is intended to be a general survey of the software available,
  93. so I won't spend too much time on some of the details.  Most of
  94. the available software comes with documentation that can
  95. explain things much better than I can.
  96.  
  97. Additional detail can be obtained from several sources, such as:
  98.  
  99.     Quarterman, John S.: "The Matrix -- Computer Networks
  100.     and Conferencing Systems Worldwide", Digital Press 1990,
  101.     (Order No.  EY-C176E-DP), ISBN 1-55558-033-5.
  102.  
  103.     Adams, Rick and Frey, Donnalyn: !%@:: A Directory of Mail
  104.     Addressing and Networks, 3rd Ed., O'Reilly & Associates 1993,
  105.     Provides a good reference for people seeking information
  106.     on how to access the various email networks.
  107.     ISBN 1-56592-031-7.
  108.  
  109.     Kehoe, Brendan P.: Zen and the Art of the Internet: A
  110.     Beginner's Guide, Second Edition, Prentice Hall 1992,
  111.     ISBN 0-13-010778-6.  Edition 1 is available via FTP on
  112.     cs.widener.edu in the tar file zen-1.0.tar.Z. [I think]
  113.  
  114.     Krol, Ed: The Whole Internet: User's Guide & Catalog.
  115.     First edition, O'Reilly & Associates Sept. 1992.
  116.     ISBN: 1-56592-025-2.  Very good introduction to
  117.     the Internet, history, facilities, uses, services,
  118.     etc.  I learned a lot.
  119.     
  120.     Albitz, Paul & Liu, Cricket: DNS and BIND, First edition,
  121.     O'Reilly & Associates, October 1992.  ISBN: 0-56592-010-4.
  122.     Describes in great detail everything from what a domain
  123.     is, to how to install and configure BIND.  A *MUST* for
  124.     people setting up large networks, or connecting
  125.     machines to the Internet.  It has become mandatory reading
  126.     for network administrators in a large corporation for
  127.     good reason.
  128.  
  129.     Costales, Bryan and Allman, Eric and Rickert, Neil: Sendmail.
  130.     O'Reilly & Associates, Nov (?) 1993. ISBN 1-56592-056-2
  131.     (ISBN from galley proof, which I've had a preview of).
  132.     An absolute necessity for anyone diving into the configuration
  133.     of sendmail.  The material is presented in a very clear
  134.     form, and is quite exhaustive in its coverage.  Perhaps a bit
  135.     too wordy and overlong, but that's a more than welcome contrast
  136.     to previous documentation (or lack thereof) on sendmail.
  137.  
  138. Further, this is primarily oriented towards UNIX email systems.
  139. This is unfortunate, because it would be nice to have a general
  140. document covering email in all of its forms.  However, each
  141. operating system tends to have radically different email mechanisms,
  142. so it would be difficult to do justice to any other environment.
  143. It seems more useful to cover one environment well here, and have
  144. companion documents for other environments.  Speaking of which,
  145. why hasn't anybody else stepped in to do FAQs on other environments?
  146. Like DOS, Mac etc.
  147.  
  148. And finally, this document is not intended to be pedantically
  149. correct.  Knowledgeable readers will know that I'm glossing
  150. over a lot of detail, and absolute precision has been balanced
  151. against readability and effectiveness in helping people get
  152. going.
  153.  
  154. ------------------------------
  155. Subject: Layout
  156.  
  157. This FAQ is laid out in the following sections:
  158.  
  159.     + An overview of how mail systems go together.
  160.  
  161.     + A glossary of the important terms to know.
  162.  
  163.     + A list of general do's and don'ts of mail systems.
  164.  
  165.     + Configuration Issues
  166.  
  167.     + Several suggested mail configurations. 
  168.  
  169.     + General overviews of specific software.
  170.  
  171. ------------------------------
  172. Subject: Electronic mail - A General Overview of Structure
  173.  
  174. Electronic mail generally consists of three basic pieces:
  175.  
  176.     1) The link level transport - which could be
  177.        UUCP, TCP/IP, or a host of others.  We'll call
  178.        this the "transport medium" (TM)
  179.  
  180.     2) the "Mail Transport Agent" (MTA) which is responsible for
  181.        transporting mail from source to destination, possibly
  182.        transforming protocols, addresses, and routing the mail.
  183.  
  184.        The MTA often has several components:
  185.         - Routing mechanisms
  186.         - Local delivery agent (LDA)
  187.         - Remote delivery agent
  188.        Many MTA's have all of these components, but some
  189.        do not.  In other cases, it is possible to replace
  190.        certain components for increased functionality.
  191.  
  192.     3) The "User Agent" (UA) is the user interface -
  193.        the software that the user uses to read his mail,
  194.        sort things around in folders, and send mail.
  195.        Sometimes called "Mail User Agent" (MUA).
  196.  
  197. ------------------------------
  198. Subject: Glossary
  199.  
  200. Rather than alphabetic, this glossary tends to group terms
  201. referring to similar functionality together.
  202.  
  203. Transport Medium:
  204.  
  205.     UUCP (Unix to Unix Copy Program):
  206.     Back in the mists of time, UNIX systems communicated only
  207.     over RS232 serial lines, usually over modems.  UUCP is a
  208.     suite of programs developed back in the early 70's to
  209.     provide this communications link.  All that UUCP does is
  210.     transfer files from one system to another.  There is an
  211.     additional mechanism where one system can direct the
  212.     destination system to run a file through a specific program.
  213.     Electronic mail in UUCP is simply requesting the destination
  214.     machine to run "mail" on a data file.
  215.  
  216.     UUCP communicates by means of "protocols", the most common
  217.     being "g", a method for transmission of data over telephone
  218.     lines and ensuring that the data is not corrupted.  There
  219.     are several other protocols, none universally available,
  220.     and most oriented towards communication media other than
  221.     telephone voice lines (such as dialup X.25, PAD X.25, or
  222.     LAN connects).
  223.  
  224.     UUCP operates over fixed system-to-system links, so sending
  225.     mail from one system to another often has to traverse
  226.     other intermediate systems.
  227.  
  228. |    If you like source, Taylor UUCP is an excellent full-featured
  229. |    implementation of UUCP, with many enhancements to deal with higher
  230. |    modem speeds.  It is FreeWARE.
  231.  
  232. |    UUCP mail protocols (bang paths) are now being deprecated, because
  233. |    DNS and MX etc., are making it wholly unnecessary.
  234.  
  235.  
  236.     TCP/IP (Transmission Control Protocol/Internet Protocol):
  237.     TCP/IP is a protocol that allows any system on a network to
  238.     talk "directly" to any other, by passing packets of
  239.     information back and forth.  TCP/IP (and its later relative
  240.     OSI) is usually used over networks built on top of Ethernet,
  241.     Token-Ring, Starlan and other LANS.
  242.  
  243.     SMTP:
  244.     Or, "Simple Mail Transfer Protocol", is the communications
  245.     protocol used most commonly over TCP/IP links in UNIX
  246.     environments for mail.  SMTP usually operates directly between
  247.     the source and destination machines, so intermediate machines
  248.     don't get involved (except for gateways, see below).  SMTP
  249.     is usually part of the MTA.
  250.  
  251.     SLIP (Serial Line Internet Protocol):
  252.     SLIP is an implementation of TCP/IP designed for use over
  253.     RS232 serial lines (ie: modems).  The other difference is
  254.     that some SLIP implementations have the ability to "dial the
  255.     phone" to make a connection for a specific transfer, whereas
  256.     LAN TCP/IP is physically continuously connected.  You'd also
  257.     need TCP/IP to run a SMTP mail connection.
  258.  
  259.     PPP (Point-to-Point Protocol):
  260.     A successor to SLIP.
  261.  
  262.     X.25/X.29:
  263.     X.25 is a packet switched data network which is usually
  264.     half-duplex.  In this context, it's really an alternative
  265.     to dialup over voice telephone lines with modems.  X.25
  266.     is available in several "flavours", either direct X.25
  267.     trunk connects over leased lines, through "PAD" interfaces,
  268.     or by ordinary dialup modem access to X.25 "ports".
  269.  
  270.     To be useable in the context of mail transfers, you also
  271.     have to use a file transfer protocol/mechanism of some
  272.     sort on top of X.25.  The most common being UUCP "f" protocol
  273.     (through PADS or dialup), or "x" with direct X.25 connects.
  274.  
  275.     Whether you use X.25 or phones plus modems depends on a number
  276.     of factors - usually the determining factor is cost.  In North
  277.     America, high speed modems (eg: 9600 baud and above) over telephone
  278.     lines tends to be less expensive.  However, Europe's really
  279.     wierd phone system structure usually makes X.25 more cost-effective,
  280.     and therefore, X.25 use in UNIX mail systems is much more common
  281.     in Europe than North America.
  282.  
  283.     X.29 is the command set used to configure and establish
  284.     X.25 connections when you're using asynchronous connections
  285.     to a PAD.
  286.  
  287. Networks:
  288.  
  289.     Internet:
  290.     An "internet" is a network comprised of computers that talk
  291.     to each other using TCP/IP, and usually SMTP for mail.
  292.  
  293.     The "Internet" is a vast network of hundreds of thousands of
  294.     machines using SMTP protocol mail, communicating with
  295.     each other over relatively high speed lines.  But not all
  296.     "internets" are connected to *the* Internet.
  297.     
  298.     The Internet grew out of a US government funded project in
  299.     inter-computer communications that grew into an enormous network
  300.     of systems.
  301.  
  302. |    One of the principal characteristics of this network is that
  303.     machines are addressed by domain names which identify the
  304.     destination, rather than addresses that are constructed out
  305.     of the route from machine-to-machine-to-machine.
  306.  
  307.     UUCP Network:
  308.     The UUCP network is that set of machines that talk to each other
  309.     via UUCP.  Sending mail through this network requires that the sender
  310.     know the network topology of UUCP links, and specify a path from one
  311.     machine to the next.  (There are, of course, ways around this.
  312.     See the section on "do's and don'ts".)
  313.  
  314. Mail addresses:
  315.  
  316.     Addresses:
  317.     An email address is a method of specifying a given person on
  318.     a specific machine.  There are scads of conventions, usually
  319.     determined by the presence of "@"'s, "!"'s and other special
  320.     characters in the name.  An address usually consists of
  321.     two parts: a userid/name and a machine specification.
  322.  
  323.     A Domain address usually looks like:
  324.         userid@domain-address
  325.     Whereas a UUCP address usually looks like:
  326.         siteA!siteB!siteC!userid
  327.  
  328.     Domain Addresses:
  329.     Domains are a way of uniquely specifying a destination.
  330.     Much like a postal address, a domain specifies a set of
  331.     progressively more restrictive "domains" of the potential
  332.     address space.  It would perhaps be illustrative to give an
  333.     example:
  334.  
  335.         clewis@ferret.marketing.fooinc.com
  336.  
  337.     You read these things right to left: "com" means the
  338.     commercial domain.  "fooinc" is the name of an organization
  339.     within the commercial domain.  "Marketing" is the name of a
  340.     suborganization within fooinc, and ferret gives the name of
  341.     a machine (usually).  Domains can have any number of levels.
  342.  
  343.     The top level domain (com in the above example) has many
  344.     possible values.  In the United States, "com", "mil", "edu",
  345.     and "gov" are fairly standard.  Elsewhere, the top level
  346.     domain tends to be a country code, the second level tends to
  347.     be a province or state, OR a classification like "edu" or "ac"
  348.     for academic (such as ac.jp, go.jp, ac.uk, edu.au, etc)
  349.     and the third an organization.  But, for example, there are
  350.     many .com and .edu sites in Canada and other countries.
  351.  
  352.     FQDN
  353.     A fully-qualified-domain-name (FQDN) has a entry for each
  354.     level of the domain, from individual machine to top-level
  355.     domain.  In many cases, an organization has implemented an
  356.     organizational "gateway" at a higher level of domain, so
  357.     that people from outside don't have to specify FQDN's to get
  358.     to a specific person.  In the above example, for instance,
  359.     "fooinc.com" may be sufficient to get to anyone inside
  360.     fooinc, and "ferret.marketing" may not be necessary.
  361.  
  362.     On the other hand, people sometimes leave out the higher
  363.     levels of the address, as in "ferret.marketing".
  364.     This is a bad idea - because if the mail is cc'd out of the
  365.     organization, chances are the external recipient cannot reply,
  366.     because "ferret.marketing" is incomplete.  So use addresses
  367.     that are specified sufficiently for external users to use.
  368.     (fooinc.com if a organizational gateway is used, the whole
  369.     ferret.marketing.fooinc.com if not)
  370.  
  371.     NIC
  372.     Internet TOP-LEVEL domains (edu, com, gov, mil) are controlled
  373.     by a single organization, the NIC (internic.net).  An organization
  374.     "gets a piece" of the namespace by registering with the NIC, and
  375.     then they are free to administer their own namespace (everything
  376.     under fooinc.com) as they choose.  The same is true for foreign
  377.     countries; Once they have their top-level domain (usually the
  378.     two-letter ISO country code) registered with the NIC, they do
  379.     the rest, and divide it as they see fit.
  380.  
  381.     In contrast, on UUCPnet, all machine names everywhere share a
  382.     single flat namespace.  So it is important to choose a name
  383.     that has not been used before. (See do's and don'ts).  This is
  384.     why FQDN's help.  We can tell the difference between
  385.     ferret.fooinc.com and ferret.blah.edu by their full names.
  386.     (Instead of UUCP paths which may turn out to be wrong, and
  387.     autorouting will probably send the mail to the wrong machine)
  388.  
  389.     MX record:
  390.     A non-SMTP/Internet site that wishes to register on the Internet
  391.     will need to get a "nearby" Internet site to set up a MX
  392.     record for them.  An MX record is essentially a domain-server
  393.     database record that (effectively) registers your domain name
  394.     on the Internet, and indicates that the Internet site knows
  395.     how to forward mail to you.  Usually via some non-SMTP/Internet
  396.     route, such as UUCP.  You can get an MX record for one site, or
  397.     a "wildcard" MX record so that you can have your own subdomains.
  398.  
  399.     Bang-Paths:
  400.     With UUCP mail, the MTA has to specify a route to get from one
  401.     machine to another.  "A!B!C!userid" means go to machine A,
  402.     then B, then C, then user "userid" on C.  You should strive,
  403.     however, for a MUA that allows you to use domain addressing,
  404.     and let the MTA figure out the bang routing as appropriate.
  405.  
  406. Miscellaneous:
  407.  
  408.     Gateways:
  409.     There are several meanings of this term, only three are relevant
  410.     here.
  411.  
  412.     The first is a mechanism for getting from one network to another
  413.     network that uses different protocols.
  414.  
  415.     The second is a mechanism for getting from one logical (often
  416.     organizational) network to another using the same protocol.
  417.     Often for example, there will be a LAN in one department of
  418.     an organization, and one machine in the LAN has the connection
  419.     to another LAN in another department.  This means that mail from
  420.     one LAN to the other has to pass thru the gateway machine.
  421.  
  422.     Another form, which we'll mention later is that of mail to
  423.     news gatewaying.
  424.  
  425.     Routers:
  426.     There are several definitions, but the most important is that
  427.     part of the TA that figures out how to send a message to
  428.     a given machine.  This often uses a database that provides
  429.     routes from one machine to the other machines on the network.
  430.  
  431.     Smarthost:
  432.     In many cases, your machine won't know how to get to a specific
  433.     destination.  You can usually set up your mail system to send mail,
  434.     that it doesn't know how to deliver, to a machine that is more
  435.     likely to.
  436.  
  437.     RFC's:
  438.     A set of documents that include formal descriptions of mail
  439.     formats used on the Internet, and are adhered to by many
  440.     non-Internet systems.  More specifically, in the "worldnet"
  441.     of Usenet, Internet and UUCP, the RFC's set the standards
  442.     for mail exchange.  RFC822, 1123 and 976 are the most important
  443.     for Internet/UUCP mail.
  444.  
  445.     It should be pointed out, however, that there are some
  446.     regions where the RFC's are not entirely respected.  For example,
  447.     the British academic email networks (JANET) uses domains, but
  448.     they're specified backwards (they drive on the wrong side of
  449.     the road too ;-).
  450.  
  451.     MIME:
  452.     Mime is the official proposed standard format for multimedia Internet
  453.     mail encapsulated inside standard Internet RFC 822 messages.  Facilities
  454.     include sending multiple objects in a single message, character sets
  455.     other than US-Ascii, multi-font text messages, non-textual material
  456.     such as images and audio fragments, and other extensions.  For an
  457.      overview of Mime, see ftp.uu.net:networking/mail/metamail/MIME-overview.txt.Z.
  458.     The defining document is Internet RFC 1341: N Borenstein & N Freed,
  459.     ``Mime (Multipurpose Internet Mail Extensions) mechanisms for specifying
  460.     and describing the format of Internet message bodies'' (June 1992).
  461.     Also see RFC 1344: N Borenstein, ``Implications of Mime for Internet
  462.     mail gateways'' (June 1992).
  463.     RFC1341 and 1342 have since been superceded by RFC 1521 and 1522.
  464.  
  465.     Mime covers only message bodies, not message headers; to see how to
  466.     represent non-Ascii characters in message headers, see Internet
  467.     RFC 1342: K Moore, ``Representation of non-Ascii text in Internet
  468.     message headers'' (June 1992).
  469.     
  470.     X.400:
  471.     A CCITT standard for email formats, more or less an alternative
  472.     to RFC 822/976/1123.  This format will probably start taking over
  473.     from RFC 822/976/1123 mail.  It is likely to (already has?) become an
  474.     ISO/IEEE standard along with OSI etc.
  475.  
  476.     "The Maps":
  477.     A set of files describing machine-to-machine links distributed
  478.     over Usenet in the group comp.mail.maps.  These are usually posted
  479.     on a monthly schedule, and can be automatically received and
  480.     transformed into a routing database that describes the "optimal"
  481.     route to each machine.  These are operated by the "UUCP Mapping
  482.     Project".  See the README posted along with the maps for
  483.     more details.
  484.  
  485.     Aliases:
  486.     Aliases are a mechanism by which you can specify the destination
  487.     for mail on your machine.  Through the use of aliases you can
  488.     redirect mail to "virtual userids".  For example, you should
  489.     have a mail destination on your machine called "postmaster", which
  490.     is aliased to send the mail to the System Administrator (ie: you
  491.     probably).  Aliasing often also permits you to send mail to groups
  492.     of users (not necessarily on the same machine as you) pipelines of
  493.     commands or to specific files.
  494.  
  495.     Mailing lists:
  496.     Are similar to Usenet newsgroups.  They are usually aliases
  497.     pointing to groups of users, and allow mail to be sent to the
  498.     whole group at once.  Mailing lists are set up to carry certain
  499.     subjects.  The difference between a mailing list and a Usenet
  500.     newsgroup is that the messages are sent by mail, probably as
  501.     a copy to each recipient, rather than broadcast.
  502.  
  503. ------------------------------
  504. Subject: Do's and Don'ts:
  505.  
  506. 1) Register a domain name.  Even on UUCP, where <machine>.UUCP is often
  507.    used as a kludge, it is MUCH preferred that you obtain a real
  508.    domain address.  If you are directly connecting to the Internet,
  509.    you will get one as part of your registration with the NIC.
  510.  
  511.    If you aren't connecting directly to the Internet, obtaining a
  512.    registration will usually require you finding a nearby friendly
  513.    Internet site willing to act as a mail forwarder to you from
  514.    the Internet - the site that will set up a "MX record" for you.
  515.    Many sites will do this for you for free, and several of the
  516.    commercial email services (eg: uunet) will do it for you for a
  517.    nominal charge (without requiring you buy the rest of their
  518.    services).
  519.  
  520.    There are occasions where you can join what is called a "domain
  521.    park".  These are most often small regional groups of systems that
  522.    have gotten one of their number properly registered as a domain,
  523.    and provides forwarding services out to other systems.  For
  524.    example, in my address "ferret.ocunix.on.ca", "ocunix.on.ca"
  525.    is a domain park made up of the Ottawa-Carleton UNIX User's Group,
  526.    one of the other machines in the group provides a gateway between
  527.    our systems and the Internet.
  528.  
  529. 2) If your machine is going to "speak" UUCP to the outside world,
  530.    choose a unique UUCP name.  You can find out whether a name you
  531.    want is taken by consulting the UUCP maps.  Or by asking someone
  532.    else who's using them.
  533.  
  534. 3) Register your machine with the UUCP Mapping Project if you're going
  535.    to use UUCP.  Information on how to do this is included in the
  536.    monthly maps postings in the file "README".  This is usually only
  537.    required when your machine talks UUCP to the outside world, or when
  538.    other machines have to address you by your UUCP name.  If you don't
  539.    do this, somone else may choose the same name, and gross confusion
  540.    will arise when smart routers won't be able to tell whether to send
  541.    a piece of mail to you, or your doppelganger[s].  If you register
  542.    with the UUCP Mapping Project, you have prior use, and people who
  543.    choose the same name afterwards will be told to get a new one.
  544.    
  545.    If you're "behind" an organizational gateway, don't do this.
  546.    (Your organizational gateway is the thing that needs to be
  547.    registered)
  548.  
  549.    If you do fill in a map, please take the time to fill it in
  550.    carefully, giving contact people and phone numbers.  Just in
  551.    case your machine goes crazy and starts doing something nasty.
  552.    Note expecially the latitude and longitude.  Get it right,
  553.    or omit it.  Brian Reid gets really annoyed with sites that
  554.    are half a world away from where they really are.
  555.  
  556. 4) If you're going to be setting up multiple machines, have only
  557.    one or two connections to the outside world.
  558.  
  559. 5) Install a mail system that understands domain addressing, even
  560.    if you aren't registered.  (In fact, all of the suggested
  561.    configurations in this FAQ do)
  562.  
  563. 6) *Never* use UUCP bang-routing with the MUA if you can possibly
  564.    avoid it - each of the suggested mail configurations provide
  565.    mechanisms where you, the user, do not have to specify routes 
  566.    to the MUA - you can specify domains, and the TA will do the
  567.    routing (possibly bang-routing) for you.
  568.  
  569.    Important: many mailers that understand UUCP attempt to be
  570.    pedantically "UUCPish" in the construction of headers, such
  571.    as generating "bang routes" in From:/To: etc. lines.  Which,
  572.    given that the whole "mail network" is generally converging on
  573.    more Internet-like standards, and that even UUCP sites are
  574.    using fully domain-capable mailers, is a big mistake.  RFC976
  575.    attempts to codify a "meta standard" that allows the coexistance
  576.    of RFC822 (Internet mail) with UUCP-based networks.  What
  577.    this means is, essentially, that headers are formed in the
  578.    SMTP form, even if the transport will be via UUCP.  Unfortunately,
  579.    however, many mailers insist on "UUCP-izing" perfectly useable
  580.    Internet/domain headers.  "Fixing" them to prevent this is sometimes
  581.    difficult.  Sendmail is almost always a problem in this regard.
  582.  
  583. 7) Find a friendly neighboring SA to help.  A SA who has already
  584.    operating mail in your area will help smooth over the regional
  585.    "gotchas" that are bound to crop-up.  And advise you on the
  586.    right software to use, where to obtain it, and how to install it.
  587.  
  588. 8) Do NOT use "any old" Map unpacking program.  Most available
  589.    map unpacking programs automatically run the shell (or shar)
  590.    to unpack map articles.  Since it is trivially easy to forge
  591.    map articles, using this type of unpacking program can
  592.    easily let very destructive trojan horse or virus programs
  593.    into your machine.
  594.  
  595.    The two specific map unpackers described in this FAQ are known
  596.    to be secure from such attacks.  Do not run any other unpacker
  597.    unless you are aware of the issues and can inspect the code for
  598.    such vulnerabilities.  [If you know of other "secure" map
  599.    unpackers that are generally available, please let me know]
  600.  
  601. 9) If the people on your site, or small network, receive mailing
  602.    lists, it's often a good idea to gateway them to news:
  603.  
  604.    Netnews often performs many of the same services as email.
  605.    The primary difference is that messages are centrally stored,
  606.    rather than delivered to individual's mailboxes, and that
  607.    distribution looks more like a broadcast then a set of point-to-point
  608.    communications.  This means usually means that news can handle more
  609.    volume, more efficiently, then email can.
  610.  
  611.    Because of the differences (and also the similarities) people often
  612.    want to tie news and mail together.  This is known as "gatewaying."
  613.    For example, a small software development site might subscribe to the
  614.    X Windows mailing list.  Rather than have (say) eight copies of each
  615.    mail message sent to their host, they would rather have it stored as a
  616.    local newsgroup that everyone in the company can read, and which can
  617.    be centrally archived.  This is a typical use of a "mail to news"
  618.    gateway.  When a user makes a posting to this local group the article
  619.    should be sent back out to the mailing list; this is a typical use of
  620.    a "news to mail" gateway.
  621.  
  622.    On a larger scale, the "inet" groups are bi-directional gateways of
  623.    Internet mailing lists.  Within mainstream Usenet, many popular
  624.    groups such as comp.windows.x, comp.protocols.tcp-ip, comp.unix.wizards,
  625.    and so on, are gatewayed to mailing lists and back.
  626.  
  627.    Many subtle issues often come up when gatewaying mail and news, so
  628.    unless you are experienced you should use one of the already-available
  629.    packages for your local organization.  For example, you probably do not
  630.    want to write a brand-new Perl script and create a new "inet" newsgroup.
  631.    The C News distribution includes some basic gateway tools in the
  632.    contrib/nntpmail directory.  Many people use Rich $alz's "newsgate"
  633.    package that appeared in comp.sources.unix Volume 24; it includes
  634.    discussion of some of the more subtle issues that come up.
  635.  
  636.    Before starting a mailing list gateway, apart from the technical aspect
  637.    of the job you should also be aware of one important point: mailing-lists
  638.    are considered private, whereas newsgroups are public.
  639.     
  640.    One can know who gets a list, but not who reads the group. It is always
  641.    wise to get the authorization of the mailing-list manager and of the readers
  642.    before creating a mail/news gateway.
  643.  
  644. 10) If you're connecting to the Internet, or are setting up a large local
  645.    internet, you really should get a copy of the DNS and BIND book mentioned
  646.    in the bibliography.
  647.