BIND/Sendmail Notes

I'll probably revise this page later, but here are some BIND 9.1.2 samples for the moment - you should still read the other notes below for an overview first.

(just tacked on .912 on the end of files so I could post them quickly - but they don't have .912 in my 'real' setup - in case it's not obvious)

/etc/named.conf
jdog.hosts
jdog.rev
named.local
root.cache

(Of course you want to create your own root.cache file with dig)

I set this up when I was playing around with SuSE Linux on my machines at home... but it should be fairly obvious where things might differ with other distributions (in a nutshell... where your sendmail cf files are - so you can build a custom configuration).

Just for trivia (don't laugh at my machine names) - I'm telling you what I set up at home - just to point out I *do* have a mixed bag of computers and it doesn't particularly matter.

My machines: (all set up with fictitious 'home.org' domain)

  1. set up a nameserver for my fictitious domain on sonny

    2. very similar to DNS/bind lab... with different machine names/IP's

    the relevant 'change/addition' for sendmail was the inclusion of an 'MX' record to specify the mail handler for the domain

  2. all machines need to use sonny as their nameserver
  3. Also... not specifically related to this - I set the gateway on the Linux machines to 192.168.0.10 - since I want to share the single modem connection through speedy with the rest of my network.

    4. The proxy server running on speedy maps incoming/outgoing traffic correctly with the outside world.

    The point is: machines on the internet only see my 'gateway/firewall/proxy server machine, but it is possible to map incoming requests to machines on the internal network... and it is possible for all of my internal machines to access the internet through the gateway - while still remaining 'hidden' to the outside world. Each request is passed to the gateway/firewall/proxy server... which then fetches a particular page, etc... and gives it back (or not) to the requesting client.

    Of course This is an extreme over-simplification of the actual details - but the overview is probably worth something.

    All traffic appears as though it is originating from the gateway machine... and an external machine has no idea how many/which machines I have on my internal network.

    When I get my internet connection... my ISP gives me a *real* IP address. The internal machines see the gateway as 192.168.0.10, but to the outside world, the gateway machine is 209.162.x.x (depending on which IP my ISP gave me)

  4. Install sendmail on any machines that need it - to simplify everything... let's just assume you grab the rpm packages instead of compiling from scratch. You can just as easily build a custom 'mc' file to generate a new sendmail.cf after an rpm installation... so it doesn't really matter.
  5. Configure sendmail on pokey, celly, and rusty (nullclients) using m4 and null.mc to generate a new /etc/sendmail.cf file.
  6. Configure sendmail on sonny to act as the mail hub (server)
  7. Also... on sonny (mail server) I had to add some machine names to /etc/sendmail.cw.

    8. Relaying is denied by default with sendmail 8.9.x? - so in order to relay messages for the other machines on your network... you need to add them to /etc/sendmail.cw - along with a few other entries:

    The last entry (home.org) is important for a jbyrne@home.org address to map correctly to a local account on the mail server.

    If you look at the null.mc file - I set up the mail hub as 'sonny.home.org'... but I actually want to 'masquerade' as 'home.org' from all of the clients.

    This gives you the typical behavior you see in most places... hiding specific machine names when you send mail... and just tacking on the domain name.

    We do need to add the individual client machines to /etc/sendmail.cw... because in a typical SMTP session... the client 'identifies' as 'root@pokey.home.org' even though it also lets the server knows it wants to masquerade as 'home.org'.

    I think I have the basic theory right ;-)

  8. That's it - not too complicated

    9. The most important part is adding the MX record to the nameserver tables... and making sure all the machines use that nameserver for resolving machine names/addresses.

    Also... since relaying is denied by default... the server needs to have the appropriate Cw entries to accept/forward mail from other machines on the network *and* recognize itself as 'home.org' for proper local delivery of mail addressed as 'jbyrne@home.org', etc...