⟦91382b6f2⟧

TextFile

A guide to the options available with the IDA-1.3.4 configuration package.

Note:  A number of the options are used to define classes.  In a class
       definition, the value of the keyword may be a list of names, a
       complete file name beginning with '/', or a command pipe beginning
       with '|'.  See sendmail.mc for more information and the sample .m4
       files for examples.

  ALIASES.  This defines the location of the aliases(5) database.

  FORCE_NAMED.

 This should normally be defined for hosts which are on the Internet, and have
access to a name server.  The name server need not be on the same machine, 
provided that there is a suitable '/etc/resolv.conf'.  The effect is that 
sendmail will not trust '/etc/hosts' and will only use the name server for 
looking up addresses.

  PSEUDODOMAINS

 This is a list (or CLASS) of top level domains that are not known to the name 
servers.  It should include domains such as BITNET and UUCP.  See the sample 
m4 files for a suitable definition.

  DEFAULT_HOST

 If your system is properly configured, you should not need to define this.  
The purpose is to define the macro $w, which should evaluate to your host's
fully qualified name. 

 There is a quick test you can make to see if you need this.  Send yourself
some mail, as in:  mail 'me'  (where 'me' is replaced by your own logon id).
Then look carefully at the 'From:' header line.  It should read:
From: me@fully.qualified.domain.name

 Whatever follows the '@' is what sendmail thinks is your fully qualified
domain name.  If this is correct, you need not define DEFAULT_HOST.  If it
is not correct, you should define DEFAULT_HOST to the correct value.  But
it is a good idea to find out why sendmail couldn't find the correct
value.  See the discussion below on domain setup for more information. 

 DEFAULT_DOMAIN

 If you are Internet connected, or have a valid Internet domain name, you
should NOT define DEFAULT_DOMAIN, as it will result in the generation of
incomplete addresses.  However it may be useful if you are only in a
non-Internet domain such as BITNET or UUCP.

 PSEUDONYMS

 This is used to define the class of all domain names which you consider 
local.  There is no need to include your UUCP name or your fully qualified 
host name, as they are automatically included from other definitions.  It is, 
however, a good idea to include 'localhost', or 'localhost.my.domain' 
depending on your name server setup.

 Example:  My machine is known as:  'mp.cs.niu.edu'.  However the prefered 
email address for our department is 'user@cs.niu.edu'.  Consequently 
'cs.niu.edu' must go into the definition of PSEUDONYMS.  If 'other.cs.niu.edu' 
shares the mail spool files with my machine, I would also want that to be 
included in the definition of PSEUDONYMS.

 UUCPNAME

 This defines your UUCP name to sendmail.  You may be able to find your
UUCP name with the command 'uuname -l'.  If you don't use UUCP you can ignore
this option, or define it to be the first word of your domain name.

 If you significantly use UUCP mail and UUCP mail addresses, you should
send a UUCP map entry into the UUCP mapping project: <uucpmap@rutgers.edu> or
<uucpmap@rutgers.UUCP>.  However if you use UUCP only locally, such as for
MX gatewaying, and can ensure that your UUCP name never escapes onto the
general network, this is not needed.

 UUCPNODES

 This defines the class of all your UUCP neighbours.  It is usually defined
with:

define(UUCPNODES, |uuname|sort|uniq)dnl

 If you have a 'uuname' command, the above definition should automatically
give the correct set of names, based on the contents of your L.sys UUCP
configuration file.

 ALTERNATENAMES

 This is a list of other host names which are not pseudonyms for your host, 
but for which in some manner you handle final delivery.  In most cases you
need not define this.  As an example, I place 'niu.edu' in this class.  The
address 'name@niu.edu' is not treated as identical to 'name@cs.niu.edu'.  
Neverthless, by means of a database lookup, my machine attempts to make final 
delivery for mail addressed to 'name@niu.edu'.

 BANGIMPLIESUUCP

 In most cases, this should be defined.  The effect is that in an address of 
the form 'host!name', the 'host' is translated into 'host.UUCP'.  This is 
usually the correct approach.

 BANGONLYUUCP

 If this is defined, '.UUCP' will not be added to an unqualified host name 
unless the address is of the form 'host!name'. 

 DOMAINTABLE
 PATHTABLE
 GENERICFROM
 MAILERTABLE
 UUCPXTABLE

 These define the various DBM lookup tables which may optionally be used.  
There use is fully documented elsewhere.

 POSTMASTERBOUNCE

 If you define this the postmaster will receive a copy of each mail which 
could not be delivered.  This is sometime useful if you are not sure whether 
your configuration is correct.

 UUCPRELAYS

 This is used to define a set of well known UUCP domains, and is used only to 
simplify the header addresses.  It is purely optional, and unless you receive 
a high volume of UUCP traffic there is probably no reason to define it.  For
more information look at the documentation in Sendmail.mc.

 UUCPPRECEDENCE

 Some UUCP hosts incorrectly add 'host!' in front of addresses, even when the 
address is an Internet format address, using '@' to define the domain.  For 
example, uuhost might convert 'user@full.domain.name' to 
'uuhost!user@full.domain.name'.  If parsed in the normal manner, this is 
treated as meaning that the mail should be forwarded to 'full.domain.name' and 
then from their to 'uuhost'.  Unfortunately 'uuhost' is your neighbor, not the 
neighbor of 'full.domain.name'.  To avoid this problem, such addresses should 
be parsed specially, so as to give precedence to the UUCP domain.  
UUCPPRECEDENCE should be defined as the list of those of your UUCP neighbors 
which generate these garbled addresses.  It is intended as a temporary fix 
until you can persuade those confused UUCP neighbors to get their act 
together.

 HIDDENNET and HIDDENNETHOST

 These are useful for a network of hosts all sharing a common mail name.
Just define HIDDENNET to be the class of all machines in the network, and
HIDDENNETHOST to be the common mail name they are sharing.  You can even
use this option with just a single host if you want the mail name to be
different from the host name.  (But make sure that the mail name is
publically known, usually with an MX domain record).

 ISOLATED_DOMAINS
 RELAY_HOST
 RELAY_MAILER

 These are useful for hosts which are not connected to the Internet, but
are able to forward mail to Internet hosts via a gateway host.  Define
RELAY_HOST to be your gateway host, and RELAY_MAILER to be the mailer which
forwards mail to the gateway.  If you have an Internet domain name and are
using UUCP for forwarding, try the UUCP-A mailer as your first preference for
RELAY_MAILER.  In some circumstances a host will be on an internal network
which permits SMTP mail, and possibly access to a name server on the gateway
host.  In this case ISOLATED_DOMAINS can be defined to specify the hosts on
the network to which you can connect.  See 'Sendmail.mc' for more information.

 NIS_MAILALIASES

 This allows use of a NIS (or YP) network alias database in addition to the
local aliases file.  See 'Sendmail.mc' for more information.

 LOADAVEQUEUE
 LOADAVEREJ

 These define the load average at which sendmail starts queueing mail instead 
of delivering it, and starts rejecting SMTP connections.  In most cases you
should not need to define these - the default values should be satisfactory.

 TRUSTEDUSERS

 This defines additional trusted users who are permitted to use the -f option 
to sendmail.  By default uucp, daemon and root are in this class.  You may 
wish to add other names.  It is perfectly alright to not define this.

 DECNETNAME

 This defines your DECnet node name to sendmail.  Define this only if you act
as a DECnet/Internet mail gateway and have the mail11v3 program installed on
your system.  This option requires sendmail to be compiled with the MAIL11V3
option enabled in src/conf.h .

 -----------

 A number of addition options, such as:
  DECNETNODES, DECNETXTABLE are available.  See 'Sendmail.mc'
for a complete set of available options.

 -----------

 NOTES ON YOUR DOMAIN SETUP.

	These notes assume access to a name server.  If you do not have
	access to a name server, see the special comments later.

 The name server and resolver library are normally used to map between host 
names and network numbers.  The file '/etc/resolv.conf' defines the default 
domain which is automatically added to host names, and defines the network
addresses of up to three hosts running name servers.  The administrator of 
your domain should be able to help you set up this file.

 'sendmail' normally uses this system to find your host name.  It starts with 
the value returned by hostname (1) which is usually set in '/etc/rc'.  The 
following are all reasonable setups:

            hostname - returns your fully qualified host name.
            hostname - returns a value which will become your fully qualified 
                       host name when the default domain (from resolv.conf) is 
                       appended.
            hostname - returns your UUCP name, but there is a CNAME record in 
                       the domain database which maps uucpname.domain.name 
                       into your fully qualified host name.

 You might try:  nslookup `hostname`

  If this returns your fully qualifed hostname and your network address, all 
is OK.

  Conventional wisdom strongly suggests that you should avoid having
any wild card MX records in your domain.  For example if there is a
wildcard MX record (an MX record for *.your.domain), then when you
try to send mail to: user@ucbvax.berkeley.edu your resolver library is
likely to interpret the address as being at the valid:
ucbvax.berkeley.edu.your.domain

  This is clearly not what you wanted.  Wildcard MX records in other
domains should not cause any problems.  It is best for directly
connected Internet hosts to not use wildcards for their own domain.
Hosts with internet addresses, but which are only connected indirectly
such as via UUCP may wish to have wildcard MX records for their
domains to simplify domain maintenance.

  However, if you MUST have wildcard MX records in your domain, be
very certain that you comment out the define for NO_WILDCARD_MX in the
file src/conf.h when you build the sendmail executable.  If your mailer
still has trouble mailing to other MX domains you may need to use
RELAY_MAILER and ISOLATED_DOMAINS.

  Be sure that all of your network addresses are correctly mapped back to your 
hostname with PTR records.  Traditionally either 'localhost' or 
'localhost.your.domain' will map to the loop back address of 127.0.0.1.  If 
so, be sure that the appropriate name is defined in PSEUDONYMS.  Likewise 
there should be a PTR record mapping 127.0.0.1 back to a name, usually either
localhost, or localhost.your.domain.  Again whatever name it is mapped to 
should be in your definition of PSEUDONYMS.  This only matters if you wish to 
correctly handle mail addressed to: 'user@localhost' or to 'user@[127.0.0.1]'.  
These should not really be used as local mailing addresses, but someone is 
likely to test them out to see what happens.

 IF YOU DO NOT HAVE A NAME SERVER:

 If you are on Internet, you can find a name server somewhere which you
can access via a suitable '/etc/resolv.conf'.  If you are on an internal
network which has at least one gateway host also on Internet, see if you
can get the gateway host to run a name server, which can be accessed with
a suitable '/etc/resolv.conf'.

 If your only access to Internet is via a UUCP or similar link, then name
server service will not be available.  In that case you will need to have
a RELAY_MAILER and a RELAY_HOST to handle addresses that you cannot access
directly.  Make sure that 'FORCE_NAMED' is not defined in your .m4 source.
You might even try '#undef'ing 'NAMED_BIND' when you compile the sendmail
sources to build the executable (I have not tested this).

 A more important consideration is in the way you set up '/etc/hosts'.
It is important that on each line the fully qualified domain name appear
first.  For my domain (mp.cs.niu.edu), I can use:

	131.156.1.2	mp.cs.niu.edu	mp	mp.cs
	131.156.3.2	math.niu.edu	math	denali

If, for some reason (broken system software, for example) you cannot
organize your '/etc/hosts' table in this way, you had best define
DEFAULT_HOST, and have DOMAINTABLE entries for all hosts in your domain
to fully qualify them.

This is because when the name server is not used, the first entry in a
hosts record is taken as the official entry.  Attempts to canonicalize
names with the hosts table will not give correct results unless you get
this right.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦91382b6f2⟧ TextFile

Derivation

TextFile
