SUMMARY: switching from uucp to smtp mail delivery

From: Roger Spaulding (ras@ramtron.com)
Date: Mon Apr 07 1997 - 14:36:11 CDT


        Hello good people!

        Here's my posting:
>
> Ok gang, here's the situation.
>
> We have a small network of 12 SPARCs, SS1+ through SS20s.
> Our mail server also handles e-mail for about 90 PeeCees that
> use Microsoft Exchange running Win95.
>
> We are now changing things to become directly connected to the
> Internet. I turn to the wisdom of this group for some help in
> determining what needs to be done and how to do it.
>
> Specifics: Our mail server is a Solbourne 5/500 running OS/MP
> 4.1B. This is a dual processor machine and this OS corresponds
> to SunOS 4.1.3 (Solaris 1.1.1).
>
> We have purchased an Ascend Pipeline 50 ISDN interface/router box,
> and, after six months of our listening to their lies, US West
> finally installed our ISDN line. Our new ISP is to be
> UUNET Technologies.
>
> Because of the CAEE/CAD software we are using, upgrading the
> OS to Solaris 2.x is not an immediate option.
>
> To make all this work together I'm guessing I must:
> - reconfigure sendmail
> - bring up DNS/BIND, at least on the mailhost
> - implement routing, at least on the mailhost
>
> Question 1: How anyone been down this path before who could
> offer advice on reconfiguring sendmail?
>
> Question 2: Is the above list correct? Must I do additional thing?
> Am I doing too much?
>
>
        
        And attached at the end of this message are the responses. I
        haven't had time to act on them yet, but the replies shook the
        cobwebs out of my brain. My way is now clear :-).

        Special thanks go out to:

                Jochen Bern
                David Neal
                Stefan Voss
                Alfredo Sola
                Alex Finkel

        Roger Spaulding
        Network System Administrator
        Ramtron International Corporation
        1850 Ramtron Drive
        Colorado Springs, CO 80921
        ras@ramtron.com

        "Keep your stick on the ice" -- Red Green

-------- Reply from: Jochen Bern -----------------------------------------------

> To make all this work together I'm guessing I must:
> - reconfigure sendmail

Yup, and while you're at it, I recommend that you stop whittling
sendmail.cf's and start using the m4 Mechanism of 8.8.x instead.
There might be Instances where cf Magick is necessary, but they're
quite rare (and certainly getting rarer all the Time, since the
m4 Mechanism gets more and more defined Features to account for
special Situations) and the Incomprehensibility of the cf's is a
MAJOR Deterrent. Not to mention that if you ever replace sendmail
with a newer Version, the provided m4 Files will probably take Care
of any changed cf Stuff for you as long as you're using defined
FEATUREs of 8.8.x only.

Lemme show you what I do to create sendmail.cf's for my Hosts (and
compare it to the normal sendmail.cf Rhubarb):

[File CTVD-Cluster.m4, Comments edited:]

VERSIONID(`@(#)CTVD-Cluster.m4 8.2 (Berkeley) 22-Aug-1996')
DOMAIN(Uni-Trier.DE)dnl
# We want Addresses user@TI... rather than user@host... wherever possible
MASQUERADE_AS(TI.Uni-Trier.DE)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(allmasquerade)dnl
# ... but not for these Users (want to see *where* emailed Errors occured ;-)
EXPOSED_USER(root mailer-daemon uucp)
# This is necessary because we have MXes within the same Domain, but
# with a different Set of Users; Force user -> user@something Expansion
FEATURE(always_add_domain)dnl
# This is only to support our national Gateway to X.400 Email ...
FEATURE(mailertable, dbm /usr/local/lists/special/mailertable.ndbm)dnl
# These are currently under Test for "fancy Address Magic" ...
FEATURE(genericstable, dbm /etc/mail/cool-addresses-encode.ndbm)dnl
FEATURE(virtusertable, dbm /etc/mail/cool-addresses-decode.ndbm)dnl
# These are handy, and a good Thing Security-wise:
FEATURE(local_procmail)dnl
FEATURE(smrsh)dnl
# More Security relevant Setups, moderate Level of Paranoia:
define(`confPRIVACY_FLAGS', needmailhelo needexpnhelo authwarnings)
# I ***hate*** those "uh, the Target Host's been down *3 Hours* now"
# Warnings, so I up the Timeout on our Hosts to 24 Hours
define(`confTO_QUEUEWARN', 1d)
# There's no Service Switch File in SunOS, give sendmail a Fake one
define(`confSERVICE_SWITCH_FILE', /usr/local/etc/pseudo-nsswitch.conf)
# I want these Files *there*, forget the Default Location
define(`STATUS_FILE', /var/adm/sendmail.st)
define(`ALIAS_FILE', /etc/mail/aliases)
# Default Error Mode 'write' doesn't mix well with some GUI Mailers
define(`confERROR_MODE', mail)
# This is to work around a temporary Problem in our DNS
define(`confDONT_EXPAND_CNAMES')
# Not used (by us) at this Time, keep it set to most secure Mode
define(`confUNSAFE_GROUP_WRITES')
# This might come in handy one Day (but isn't used by us right now)
MAILER(procmail)dnl
# Don't edit these!!!
MAILER(local)dnl
MAILER(smtp)dnl

[File CTVD-Server.mc, Comments edited:]

VERSIONID(`@(#)CTVD-Server.mc 8.2 (Berkeley) 22-Aug-1996')
OSTYPE(sunos4.1.3_U1B)dnl
# We want the Server to accept Mail for A LOT of Hosts and Domains,
# give them to sendmail as a one-per-Line File
define(`confCW_FILE', /usr/local/lists/special/mailclients)dnl
FEATURE(use_cw_file)dnl
# include clusterwide Setup
include(CTVD-Cluster.m4)
# Special Tweak (soon to be another FEATURE, I've been told):
# Refuse Mails from Domains listed in a special File
LOCAL_RULE_0
R$* < @$*$=K . > $* $#error $@ 5.7.1 $: "Sending domain is blacklisted by the CTVD dpt.; no mail will be accepted."
R$* < @$*$=K > $* $#error $@ 5.7.1 $: "Sending domain is blacklisted by the CTVD dpt.; no mail will be accepted."
LOCAL_CONFIG
FK /usr/local/lists/special/sendmail.DOA

[File CTVD-SunOS-Client.mc, Comments edited:]

VERSIONID(`@(#)CTVD-SunOS-Client.mc 8.2 (Berkeley) 22-Aug-1996')
OSTYPE(sunos4.1.3_U1B)dnl
# You're dumb dumb dumb! Let TI.Uni-Trier.DE do the Work for you
FEATURE(nullclient, TI)dnl
# include clusterwide Setup
include(CTVD-Cluster.m4)

That's it! The Rest of the m4 Input comes with sendmail.

> - bring up DNS/BIND, at least on the mailhost

Depends on your Provider / Contract. Plus, it consists of a Client
and a Server Side.

-- Client Side: Once you have an Internet Connection, ALL your
   Hosts should be properly configured to request DNS Information.
   (This holds even if you run NIS with an NIS Master doing DNS
   Lookups on Behalf of the Clients, since some Apps - e.g., xgopher -
   insist on sending DNS Requests right away.) As long as we're
   talking of Unix, this means to have a usable /etc/resolv.conf
   and - if your Unix has it, Solaris has, SunOS doesn't - an appro-
   priate Service Switch File (/etc/nsswitch.conf on Solaris).
   resolv.conf's are easy:
; The Name of our (Internet) Domain
domain Uni-Trier.DE
; Available Nameservers, up to three, by IP Number
; (Lookups will fallback from first to last, so
; give the default Server first)
nameserver 136.199.55.62
nameserver 136.199.8.101
; Some DNS Implementations support a "searchlist"
; Statement, giving the Domains requested Names
; should be searched in, but better don't rely
; on that unless you KNOW the Host supports it

-- Server Side: If you have, say, two Days for Setup and something like
   an Hour per Week to set up the Primary yourself and your Provider allows
   you to do so, go ahead and construct your own Nameserver. Else, your
   Provider will offer to do it for you (and send you a Fee whenever
   Data gets changed :-{ ). Anyway, it is highly recommended to have
   two Servers available inside your Net and two outside if your Net
   Access happens to be down; One is the Primary (where Data is entered)
   and the others are Secondaries that simply mirror the Data off the
   Primary. Setting up and maintaining a Primary is a Bit too compli-
   cated to spell it out here. :-} Setting up and maintaining a Secondary
   is a Breeze (actually, as long as the Admin of the Primary knows
   what he's doing, there's no Maintenance to be done at all except
   retrieving a new named.root File a couple Times per Year). For
   both, I wholeheartedly recommend BIND. Here's an Excerpt of the
   /etc/named.boot I use to run a Secondary of several Domains of
   Interest to us:
;==================== OPTIONS ON INFORMATION OUTPUT ====================
;
; On Listings, first give Addresses on local Network, then on Networks
; listed here, then the Rest of the Cache [DISABLED]
;
;sortlist 10.0.0.0
;
; Do not provide Scans (Zone Transfers) to Hosts outside this Network
;
xfrnets 136.199.0.0
;
;==================== OPTIONS ON INFORMATION RETRIEVAL ====================
;
; Where to look for Files?
;
directory /usr/local/lists/special
;
; Where to get (and put) DNS Data?
; Format: type domain source host(s)/file backup file
;
; Root Servers (re-retrieve File every once in a While
; from ftp://ftp.rs.internic.net/domain/named.root)
cache . named.root
; Local Info we want to serve
secondary Uni-Trier.DE 136.199.8.101 136.199.8.129 named.uni
secondary 199.136.IN-ADDR.ARPA 136.199.8.101 136.199.8.129 named.uni.rev
secondary Trier.ITWM.FHG.DE 153.96.230.2 153.96.1.1 named.trier.itwm
;secondary ITWM-Trier.FHG.DE 153.96.230.2 153.96.1.1 named.itwm-trier
secondary 230.96.153.in-addr.arpa 153.96.230.2 153.96.1.1 named.itwm.rev
; Temporary Setup: de. Nameservers down End of August 1996,
; let's grab all the Stuff, better safe than sorry ...
;secondary DE 193.141.40.1 192.76.144.16 named.de
; Loopback Data (never changed)
primary localhost named.loopback
primary 0.0.127.IN-ADDR.ARPA named.local
;
; Try to go over central DNS Servers (fallback to do it yourself if Failure)
;
forwarders 136.199.8.101 136.199.8.129 136.199.8.132 136.199.8.224
;
; Avoid the following Nameservers [DISABLED]
;
;bogusns 10.11.12.13
;
; Go to Slave Mode (forward ALL Requests) [DISABLED]
;
;slave
   named.loopback and named.local are actually never changed since
   they just implement the fixed 127.0.0.x Network. named.loopback:
$ORIGIN localhost.
@ IN SOA aurelia.Uni-Trier.DE root.ti.Uni-Trier.DE (
                                1996111400 ; Serial
                                3600 ; Refresh
                                300 ; Retry
                                3600000 ; Expire
                                14400 ) ; Minimum
        IN NS aurelia.Uni-Trier.DE.
        IN A 127.0.0.1
   (OK, you have to fill in Hostname and Admin Email of the Secondary,
   but ...) named.local:
$ORIGIN 0.0.127.in-addr.arpa.
@ IN SOA aurelia.Uni-Trier.DE root.ti.Uni-Trier.DE (
                                1996111400 ; Serial
                                3600 ; Refresh
                                300 ; Retry
                                3600000 ; Expire
                                14400 ) ; Minimum
        IN NS aurelia.Uni-Trier.DE.
0 IN PTR loopback.aurelia.Uni-Trier.DE.
1 IN PTR localhost.

> - implement routing, at least on the mailhost

You mentioned that you have a plain Vanilla Class C Network. In that Case
- and again, as long as we're talking Unix - your Hosts should already
know what Addresses are to be considered local and which remote. All
that is left to do is to tell them where to send Packets destined for
remote Hosts - that's done by entering the Router into /etc/defaultrouter
and rebooting (*could* be "pushed" manually, but a Reboot is simpler ;-).
You can either give an IP Number there - or a Hostname that's to be
listed in a) DNS, b) /etc/hosts and c) in NIS/NIS+ if you run it.

Regards,
                                                                J. Bern
-------- Reply from: David Neal ------------------------------------------------

Roger Spaulding wrote:
>
> Ok gang, here's the situation.
>

> We have a small network of 12 SPARCs, SS1+ through SS20s.
> Our mail server also handles e-mail for about 90 PeeCees that
> use Microsoft Exchange running Win95.
We too use a sparc system as the mail router with exchange on the
backend.

>
> We are now changing things to become directly connected to the
> Internet. I turn to the wisdom of this group for some help in
> determining what needs to be done and how to do it.
>
> Specifics: Our mail server is a Solbourne 5/500 running OS/MP
> 4.1B. This is a dual processor machine and this OS corresponds
> to SunOS 4.1.3 (Solaris 1.1.1).
>
Is just the mail router going to see the internet? You want
to configure DNS on the mail router, but if only it is going
to see the net, you can just make it a client. If many people
are going to use the internet, you want to make a box (might
as well be the mail router) a caching dns server. This means
pcs in your lan ask the mail router for addresses which it
gets from the internet and then supplies to the pc. This is a big
win since the mail router caches the requests and the next pc
to ask for the same address gets an instant response.
 

>
> We have purchased an Ascend Pipeline 50 ISDN interface/router box,
> and, after six months of our listening to their lies, US West
> finally installed our ISDN line. Our new ISP is to be
> UUNET Technologies.
>
Been there, done that. Oy vey.

> Because of the CAEE/CAD software we are using, upgrading the
> OS to Solaris 2.x is not an immediate option.
>

No problem, our firewall runs sunos 4.1.3 just fine.

>
> - reconfigure sendmail
> - bring up DNS/BIND, at least on the mailhost
> - implement routing, at least on the mailhost
>

Yes to all three, although routing on the mailhost need not be
any more than putting a default route on the box that points
to your ascend. Any address that is not local will automatically
end up on the ascend, which is what you want.

> Question 1: How anyone been down this path before who could
> offer advice on reconfiguring sendmail?
>

Once you have default routing and dns working, sendmail will
work pretty much out of the box. Let me know if you have a
specific question.
 
> Question 2: Is the above list correct? Must I do additional thing?
> Am I doing too much?
>

Yup, looks about right.

If the women don't find you handy, at least they'll find ya
handsome.

-------- Reply from: Stefan Voss -----------------------------------------------

Hi,

we did not use uucp before, but apart from this, i have done nearly the same
during the last weeks. Oh - forgot to tell you, that we ARE using NIS.

Well...

1. DNS:

   You do not need to setup DNS on your machines, as long as your ISP provides
   a name server. You only have to create a file /etc/resolv.conf:

      domain your.full.domain.com
      nameserver ip.ip.ip.ip

   where ip.ip.ip.ip is the IP adress (DO NOT TAKE A HOSTNAME !) of your ISP's
   name server. In order to reduce name server requests going out thru the phone
   (and thus wasting money), you can think of setting up a local caching only
   name server in the future - i havn't done that yet.

2. routing:

   create /etc/defaultrouter. This file contains nothing more than one line:
   the hostname OR the IP adress of your router. Routing should be set up auto-
   matically during start up, if one of the /etc/rc* scripts finds a file
   /etc/defaultrouter...

   Check the routing with: netstat -rn

/etc/defaultrouter and /etc/resolv.conf have to be set up on all machines which
want something from the internet - at least your mail server. But when you give
netscape to your users and execute it locally...

In order to keep things simple, i have set up mailtool and netscape in such a
way, that they are executed only on ONE host, redirecting their display to the
machine where they were started. So i have to manage only ONE sendmail.cf.

3. sendmail...

   Our ISP gave us a sample sendmail.cf, where i had to change only 3 or 4
   lines (right enogh for not fully illuminated people like me).

   This caused the next trouble: we needed sendmail 8.5 (SunOS 4.1.3's sendmail
   is a little bit too old...). To compile it, we also needed the new bind
   package - at least the part, which created libdb.a. Using the new
   sendmail/bind, we can mask out hostnames in outgoing mail adresses and we can
   map internal usernames "wombat" (my boss...) to something like "e.kril" (his
   real name for e-mail). Nice, isn't it ?

   NOTE: install libdb.a first, sendmail later, sendmail relies on libdb.a !

   By the way: sendmail is extremly full of severe bugs, so that it is always
   a good advice to use the latest version (which in the moment seems to be
   8.5).

4. Monitoring:

   If everything seems to work fine, you should monitor your router: if some-
   thing isn't set up correct, you will see lots of outgoing calls asking for
   the name server of your ISP. In this case, is a good idea, to monitor the
   router also with tcpdump (assuming your router hostname from /etc/hosts is
   foobar):

      tcpdump gateway foobar

   If something goes wrong (indicated by outgoing calls), you can see (or
   better: get an idea) of what is going wrong using this command. Then you can
   call your ISP's hotline to get more support.

-------- Reply from: Alfredo Sola ----------------------------------------------

> We are now changing things to become directly connected to the
> Internet. I turn to the wisdom of this group for some help in
> determining what needs to be done and how to do it.
[...]
> - reconfigure sendmail

        In many cases, one of the included configuration files will fit
your case with minor customization. You will read it everywhere, but
there is no single configuration that works for everyone. Instead, there
is a sample that will easily be adapted to your needs.

> - bring up DNS/BIND, at least on the mailhost

        You need only one name server on your network, no matter where
it is. You may even rely on your ISP's. Just ensure that all the
machines can resolve names.

> - implement routing, at least on the mailhost

        Why? You have an external router, don't you?.

> Question 1: How anyone been down this path before who could
> offer advice on reconfiguring sendmail?

        Advice? http://www.sendmail.org.

> Question 2: Is the above list correct? Must I do additional thing?
> Am I doing too much?

        Just setup name service first, then go for Sendmail.

        Oh, I almost forgot... There is a book edited by O'Reilly and
Associates that has the descriptive name of "Sendmail". Buy it.

Saludos,

-------- Reply from: Alex Finkel -----------------------------------------------

At 10:15 AM 4/1/97 -0700, you wrote:
> This is a natural time to upgrade my sendmail and I compiled
> version 8.8.5 yesterday.

This will certainly make your life simpler and more secure.

> To make all this work together I'm guessing I must:
>
> - reconfigure sendmail

Did you generate a new sendmail.cf file from the sendmail source
distribution? You should make sure you have the latest version of
sendmail.cf, as many old sendmail.cf files that shipped with SunOS won't
work properly with V8 sendmail.

Will your ISDN line be up all the time, or is this a dial-on-demand setup?
You should be able set an option in the sendmail.cf file to queue all
messages and only send them at certain intervals.

> - bring up DNS/BIND, at least on the mailhost

Will UUNET handle your primary DNS service and are they coordinating the
cutover. Your MX records will need to be changed to reflect your new
mailserver.

> - implement routing, at least on the mailhost

You should be able to define a default static route through your Ascend
router to the internet. 'route add default <ascend IP address> 1'

> Question 1: How anyone been down this path before who could
> offer advice on reconfiguring sendmail?

If you generate a .cf file from the latest source it will be much easier to
use. If you need to hang on to your UUCP setup for a while, you should be
able to generate a new .cf file that will handle that as well. I highly
recommend that you get a copy of the latest edition of the Sendmail book
(O'Reilly), it is a great reference.

> Question 2: Is the above list correct? Must I do additional thing?
> Am I doing too much?

- Alex

-------- end attached replies --------------------------------------------------



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:50 CDT