Xref: utzoo comp.mail.sendmail:2316 comp.mail.misc:4231
Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!caen!stealth
From: stealth@caen.engin.umich.edu (Mike Pelletier)
Newsgroups: comp.mail.sendmail,comp.mail.misc
Subject: Re: Mail architecture
Message-ID: <1990Oct29.194011.26249@engin.umich.edu>
Date: 29 Oct 90 19:40:11 GMT
References: <1990Oct29.170344.27870@kodak.kodak.com>
Sender: news@engin.umich.edu (CAEN Netnews)
Distribution: na
Organization: University of Michigan Engineering, Ann Arbor
Lines: 61

In article <1990Oct29.170344.27870@kodak.kodak.com>
	mccrave@kodak.kodak.com (Donna McCrave) writes:
>My group has about 400 Sun systems spread out over
>three plants.  ... the main concern is smtp mail.
>
>I would like to design an architecture that requires minimal
>effort to keep going.  It should be easy to bring systems in and
>out of the loop.
>I need to set up a rather intelligent mail hub, but I am unsure
>of the role that the rest of the systems should play in order
>to keep maintenance of sendmail configurations to a minimum.

A good book to have around would be "!%@:: A Directory of Electronic
Mail Addressing and Networks".  As for design of a mail system,
here at the University of Michigan College of Engineering, we've
settled on the following structure, which I think would work well for
you.

We have a set of mail hubs, each able to do local delivery.
The rest of the hundreds of machines around campus are considered
"drones", and all have identical sendmail.cf files, a file that sends
*everything*, no matter where it's going, to one of the mail hubs.
That way, the drones don't have to do name service requests or worry
about MX records, or worry about getting an internet connection to
some arbitrary place in the outside world.  The configuration file
can be about as dumb as they come, and the machines don't require
an alias file.

Each user currently has a line in the alias file specifying on which
hub thier mailbox is located.  Eventually this will be replaced with
nameserver MB records.  So, the process goes something like this:

drone machine punt.engin.umich.edu user sends mail to "stealth"
drone cf sends it off to MX-ed mailhub.engin.umich.edu
mailhub gets message from user@punt.engin.umich.edu, to "stealth"
mailhub looks up "stealth" in the alias file and comes up with
        stealth@caen.engin.umich.edu, "caen" being another mailhub
mailhub decides that "punt" is not one of the mailhubs, so the
        name is removed, leaving "From: user@engin.umich.edu" -- $~H
mailhub contacts "caen.engin.umich.edu" mail from: user@engin.umich.edu,
        rcpt to: stealth, message is sent, and delivered to my mailbox
        on caen.engin.umich.edu.

That's how it goes for local mail.  For anything outside of the
engin.umich.edu domain, the hostname is removed even if it is a mailhub,
so that the remote user will always get mail from user@engin.umich.edu.

One of our mailhubs is also a UUCP gateway, so any UUCP mail will be
sent there by the other hubs.  We also have some people supporting
their own "standalonetcp" mail sites, that stand outside of the drone/hub
arrangement and spool their own mail.

This way, only the hub configuration files need to be worried about,
since the drones are too stupid to mess anything up or to have to worry
about anything.

--
	Mike Pelletier - Usenet News Admin & Programmer
"Wind, waves, etc. are breakdowns in the face of the commitment to getting
 from here to there.  But they are the conditions for sailing -- not
 something to be gotten rid of, but something to be danced with."