		     Sendmail -- care and feeding

$Author: reggers $
$Date: 1993/08/25 18:36:44 $
$Id: README,v 1.6 1993/08/25 18:36:44 reggers Exp $
$Source: /usr/src/usr.local/mail/sendmail.cf/RCS/README,v $
$State: Exp $

Note: Original version of this package was dated 1990/01/20, we've
      been using it ever since. This is known to work on Suns, Mips, SGI,
      AIX and will likely work on others as well.

If you're willing to build and maintain your own sendmail system here's what
you need to do. (If you'd rather seek the help of CCS we can and will do this
for you at a modest fee).

This document describes the care and feeding of sendmail for sites on the
campus IPnet and those which use UUCP to route their mail to a campus gateway
machine. I describe how to configure mail on a machine 'out of the box' -- if
you're updating an existing machine you may have things configured a bit
differently. Machines which provide some local gateway service, have other
uucp neighbors, or implement limited hidden domains will require further
effort not documented here (however, this is a good starting point).

I'm going to assume you already have the directories

	/usr/local	   -- for local software, etc.
	/usr/local/bin	   -- for local executeables
	/usr/local/lib	   -- for local support data
	/usr/src/usr.local -- for local sources
 or     /usr/local/src     -- for local sources

If you don't these directories; make them now. All locally hacked stuff (like
sendmail's configuration file, the aliases file, etc.) should be stored under
the /usr/local tree so that you can find them after OS upgrades (where the
vendor often clobbers your work!).

Sources for local additions (including this distribution) should be stored in
the /usr/src/usr.local tree (some people store things in /usr/local/src). I
recommend you create a "sendmail" subdirectory in one of those to store all of
the files in this distribution and work from there. If you store this stuff in
your home directory nobody will be able to find them when you get "hit by a
bus". Good system managers store things in predictable places and that applies
to sources as well.

Anyways, enough said. Try to follow these instructions:

0. You cannot send/receive mail without

	a) being registered in the Domain Name System
	b) haveing an MX record in the DNS pointing at you

   On both these issues, talk to NIC@uwo.ca. Mail to/from unregistered
   sites will not be tolerated! PROCEDE NO FURTHER IF YOU HAVEN'T DONE
   THIS FIRST.

1. You *might* want an up to date /etc/hosts file -- you can always find
   an up to date version of this file on julian:~ftp/nic/hosts. You
   really ought to be integrated into the DNS, if not then an accurate
   /etc/hosts is required.

2. You should be integrated into the Domain Names System (ie. at least
   have installed an /etc/resolv.conf). See also julian:~ftp/nic. If you
   are integrated then you can use an MX sendmail and route your mail
   directly to most sites -- else you'll have to punt thru some relay
   machine. We encourage everyone to be fully integrated and use MX mail
   routing (but you may punt if you like).

   Make sure you can 'telnet' to a site not listed in your /etc/hosts
   -- eg. telnet uunet.uu.net. If you can, then your DNS is working
   fine. If not, get your DNS going first -- this doesn't apply of course
   to sites not on the campus backbone.

3. Construct a custom sendmail.cf file (that's a configuration file that
   drives sendmail) for your machine and a custom alias file (that's for
   mailing to aliases like 'postmaster'). This is the most complicated
   procedure. The basic idea is for you to edit the file 'Configure.sh'
   and then execute it to create your custom files. The file is just
   a couple of editor scripts that create 'sendmail.cf' and 'aliases' out
   of distribution files -- comments in the text tell you how to procede.
   Having editted Configure.sh, you construct your files by:

	% sh Configure.sh

   Take a look at the results to verify that they look right.

4. Install sendmail.cf on /usr/local/lib by saying (you need to be root
   from here on):

	% cp sendmail.cf /usr/local/lib
	% chmod 644 /usr/local/lib/sendmail.cf

   I like to store locally hacked stuff under /usr/local rather than
   plunk them into the systems area. In a moment we'll make the systems
   area link into the local area.

5. Save your distribution sendmail.cf (on most systems under /usr/lib, on
   Sun under /etc) by saying

	% cd /usr/lib		(or /etc
	% mv sendmail.cf sendmail.cf.distribution

   You don't *need* to save these files, but it's usually a good idea
   to not trust anyone -- not even me. This lets you back out of any
   changes you make.

6. To maintain compatiblity with Sun (who want to find sendmail.cf on
   /etc) and BSD types (who look under /usr/lib) make logical links from
   the systems areas to your sendmail.cf

	% cd /usr/lib
	% ln -s /usr/local/lib/sendmail.cf .
	% cd /etc				(only required on Suns
	% ln -s /usr/local/lib/sendmail.cf .

   I have seen some systems (the NeXT springs to mind) that store the
   configuration file in an /etc/sendmail directory. Link accordingly.

7. I recommend that you move /bin/mail (the usual delivery agent) into
   /usr/local/lib/binmail and make /bin/mail a logical link to a
   better mail program (/usr/ucb/mail, or /usr/ucb/Mail, or /sbin/Mail,
   or etc.). The original /bin/mail is therefore hidden from naive users
   who shouldn't be using it anyways.

	% cd /bin
	% cp mail /usr/local/lib/binmail
	% chmod 4755 /usr/local/lib/binmail (ie. make it setuid root).

		! Beware: on some systems you may need to make
		! this setgid 'mail' as well. To do that:
		!	% chgrp mail /usr/local/lib/binmail
		!	% chmod 6755 /usr/local/lib/binmail

	% mv mail mail.distribution
	% ln -s /usr/ucb/mail .

   You'll find if you browse the sendmail.cf file that it uses binmail as
   the delivery agent for local mail. You can, of course, leave /bin/mail
   on /bin and configure the sendmail.cf to use it there. I like to move
   if off /bin because I don't think anyone, apart from sendmail, should
   be using /bin/mail.

   IBM/AIX machines use /bin/bellmail to deliver mail. That's a good
   name that doesn't conflict with other programs called 'mail'. You'll
   not need to hide it from users.

   A NOTE ON SETUID PROGRAMS:

	Traditionally /bin/mail ran setuid root so that it could deliver
	mail to your mail box and set the ownership accordingly. Of course
	/bin/mail is famous for hackers exploiting the setuid feature
	to gain access to the root account -- very bad news.

	These days (1993) I'm seeing more and more systems where /bin/mail
	is NOT installed setuid root. Instead, the expectation is that
	sendmail (which is installed setuid root) will invoke /bin/mail
	as user root. This is the 'S' (for safe) flag on the local mailer.
	This configuration is using the 'S' flag -- which means that
	/bin/mail (or whatever you use) need no longer be setuid root.

	I'd recommend you use the existing protections that the vendor has
	given you on /bin/mail. If you have problems you can always put
	setuid root on later.

8. If you've configured your system to be using an MX mail routing strategy
   make sure you have a version of sendmail which understands MX routing.
   On Suns you'll have a version

	% cd /usr/lib
	% mv sendmail sendmail.nonmx
	% ln -s sendmail.mx sendmail

   On mips machines the mx version is called "sendmail.named".

   So far I've seen several machines that don't offer a version of
   sendmail that understands MX records -- IBM/AIX and SGI spring to mind.
   On these systems you'll have to punt thru a local gateway which does
   MX routing. These days (1993) most Unix machines I'm seeing do support
   MX routing (even SGI and AIX!!).

9. Freeze the configuration file by typing

	% /usr/lib/sendmail -bz

   This makes a file /usr/lib/sendmail.fc (fc for frozen configuration
   file). A frozen configuration file is a quick representation of the
   original text file. Any time you change the configuration file (and
   you shouldn't be doing that at all!) you freeze it when done.

   On IBM/AIX the frozen configuration file is called sendmail.fcDB and
   sendmail.fcDBL -- strange names indeed. Why do they hack perfectly
   good code?

10. UUCP only sites don't need to have a sendmail daemon but it won't
   hurt anything if you do. IP sites need to kill and restart the daemon
   (Any time you change the configuration file you need to kill and restart
   the daemon). Do this by saying:

	% ps agx | grep sendmail	(or 'ps -ef' on Sys V machines
	% kill -9 <pid-determined-above>
	% /usr/lib/sendmail -bd -q1h &	(or uucp sites don't need it
					(at all

   You likely have sendmail started automatically at boot time. The '-bd'
   flag means run as a daemon, the '-q1h' means check the queue every hour.

	A nice tool for looking at the Mail Queue is the 'mailq' command,
	if you don't have it you can install it by saying:

		% ln -s /usr/lib/sendmail /usr/local/mailq
		% rehash

11. Locate your sendmail aliases file under /usr/local/lib. Since Sun types
   usually look for it in /etc and BSD types usually look under /usr/lib
   set up the appropriate links. Type:

	% cp aliases /usr/local/lib
	% chmod 644 /usr/local/lib/aliases
	% cd /etc
	% ln -s /usr/local/lib/aliases .
	% cd /usr/lib
	% ln -s /usr/local/lib/aliases .

   I've made the aliases {postmaster, root, bin, sys, news, etc.} all point
   to you. EVERY SITE WHICH RECEIVES MAIL MUST SUPPORT THE ADDRESS POSTMASTER!

12. Having created the alias file, turned it into the data base required
   by sendmail by typing

	% newaliases	

   Note, if you don't have this command you can create it by saying

	% ln -s /usr/lib/sendmail /usr/local/newaliases
	% rehash

   This creates .pag and .dir versions. To verify that mail for postmaster
   is properly aliased type:

	% /usr/lib/sendmail -bv postmaster


13. Many applications that we support will need to be able to determine the
   domain name that you're using for E-mail -- applications like Pine, Rn,
   Xrn, and others. Around campus the convention we're trying to support:

	1. the command 'mailname' should return the domain name used
	   for mail. Note this is a local utility on /uwo/ccs/share/bin.
	   It is NOT part of any standard Unix.

	2. the command 'mailname' will try to find the domain name
	   squirreled away in several files -- the important one is

		/usr/spool/mail/mailname

   PLEASE CREATE THIS FILE, PUT IN YOUR DOMAIN NAME, AND MAKE THE FILE
   READABLE BY THE WORLD:

	% echo your-domain >/usr/spool/mail/mailname
	% chmod a+r /usr/spool/mail/mailname

14. Finally, do a bit of testing to verify that everything is in order.
   SEND ME A MESSAGE TELLING ME THAT YOU'VE INSTALLED SENDMAIL. If you
   see anything strange happening, let me know:

		Reg Quinton <reggers@julian.uwo.ca> 661-2151 xt.6026
		Network Information Centre,
		Information Technology Services,
		(aka Computing and Communications Services, ie. CCS)
		Natural Sciences Centre, UWO
		London, Ont. Canada N6A 5B7


SEE ALSO:

If you're interested in knowing more about Sendmail you might try the
document:

	ftp.uwo.ca:~ftp/doc/courses/sendmail.{ps,txt}

That's a much longer paper that describes in detail how sendmail works.
The instructions in this package (ie. this file) should be adequate for
most people.

If you're in an NFS environment where you want many Unix machines to share
the same /usr/spool/mail you might be interested in:

	ftp.uwo.ca:~ftp/pub/unix/mail/rsendmail

This is a neat tool that makes it possible for your client Unix systems to
run sendmail on the server rather than locally. It's not too hard and works
rather well. 

BEWARE/WARNING:

I am aware that sites other than UWO have been using this distribution and I'm
only too happy to discover that my work has reached such a wide audience.
However, UWO is not a gateway to the world -- if you're not at UWO don't
configure your sendmail system to punt things at us (especially UUCP, BITNET
and other pseduo domains). That will not be appreciated.
