mccrave@kodak.kodak.com (Donna McCrave) (10/30/90)
Here is your chance to wax philosophic on the net. I have the task of "making the email in our division work." The rest is up to me. My group has about 400 Sun systems spread out over three plants. There are some other miscellaneous systems, but the main concern is smtp mail. There is a mix of stand alone systems, data-less clients, disk-less clients, and large file servers. Most systems use NIS. We will also be providing Internet mail, and have our own subdomain. 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 don't mind replacing the libc.a's on all the machines with the libc.a that includes libresolv.a. I know that 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. Does anyone have any recommendations on an email architecture for a large department, or any leads on some reference material? Donna McCrave mccrave@SSD.Kodak.COM
stealth@caen.engin.umich.edu (Mike Pelletier) (10/30/90)
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."
lrb@rrivax.rri.uwo.ca (Lance R. Bailey) (10/30/90)
In article <1990Oct29.170344.27870@kodak.kodak.com>, mccrave@kodak.kodak.com (Donna McCrave) writes... >Here is your chance to wax philosophic on the net. I have the >task of "making the email in our division work." The rest is >up to me. My group has about 400 Sun systems spread out over >three plants. There are some other miscellaneous systems, but >the main concern is smtp mail. There is a mix of stand alone >systems, data-less clients, disk-less clients, and large file >servers. Most systems use NIS. We will also be providing >Internet mail, and have our own subdomain. > The Robarts is an institute with cleanly divisible research groups. we do not have '400 suns' scattered about, but we have enough standalone, diskless, dataless &c suns, together with vaxen, hp's, S.G. to make coordinating the whole mess a pain for the systems manager. me. to this is added the fact that some people want 'all mail to look like it came from one machine', some want department-wide aliasing, some want host specific aliasing &c. my slice of the domain for which i am respsonible is rri.uwo.ca and in the following i will uppercase it to avoid confusion. there are 6 departments or research areas within the robarts clinical pharmacology (clinpharm) heart and circulation (heart) stroke and aging (stroke) clinical trials (ctrg) imaging (irus AND mri) immunology (immune) (the seventh, admininstration, has yet to be convinced of the wisdom of email) all hosts are named as host.dept.RRI.UWO.CA (eg: sun.irus.RRI.UWO.CA, valve.heart.RRI.UWO.CA, rri9000.ctrg.RRI.UWO.CA) the only exception being the institute vax (rrivax.RRI.UWO.CA). there is ONE place of reject/accept for addresses of the format badhost.dept.RRI.UWO.CA. in the real-nice-world this would be nameservers and MX hosts, but we do not live there, we live in the real-world and thus i have at least one sendmail.cf foeey.dept.RRI.UWO.CA. my metric for deciding whethor or not a host is hidden under another is the password files. If a diskless sun has no password file of it's own or a disked sun uses YP to live off a servers password file then that host is hidden under the sun with the passwd file. mail directly to that machine name will bounce. if a server host is hiding many hosts and itself under one name then that host may or maynot receive mail directly. my personal feeling is not, but then again, i chose coke. what i have done is quite easy to manage once set up. it involve 3 template sendmail cf's which are tailored to meet the smtp"functions" of the host. 1) client.cf this is for a diskless node, a machine with the passwd files served by another machine. no MX records point to this machine and no daemon runs on it, the MX records point the the 'machine of dept authority'. 2) server-host.cf this is for either a host that serves a number of diskless/passwd-less machines -OR- a host that handles it's own mail. additionally, this host may have been designated the 'end point' of a department. that is all goodname.dept.RRI.UWO.CA may be shipped here if they land at the server for the entire domain, this allows a department to quickly have a host handled by mentioning it a class on this .cf until DNS data gets propagated/dumb-.cf updated. 3) domain.cf this .cf is the 'buck stops here' for *...*.RRI.UWO.CA. In the *real*nice*world, the only names that this would see is user@RRI.UWO.CA user@hostname.dept.RRI.UWO.CA and user@dept.RRI.UWO.CA because all else will be MX'ed to another host or 'dept host' but in the *real*world someone has to handle foo.bar.RRI.UWO.CA. this .cf is that place. any host.known-dept.RRI.UWO.CA is punted to the .cf for that known-dept. any host.unknown-dept.RRI.UWO.CA is kicked back with an unknown host/deptartment error. these three .cf's are able to handle what i think are the seven possible department needs. 1) a department name (eg: irus.RRI.UWO.CA) will hide ALL hosts in the dept 2) a department name hides MOST hosts 3) a department has one host and does not want to hide it under dept.RRI.UWO.CA 4) a department has one host and hides it under dept.RRI.UWO.CA 5) a department has many hosts and hides none under dept.RRI.UWO.CA 6) a department has NO hosts and wants an email link under dept.RRI.UWO.CA 7) a department has NO hosts and does not want an email link a lot of the above attitudes were created after much dissertation among the researchers in the institute and the input from my two smtp mentors, reggers and magi. Lance R. Bailey, Systems Manager ================================ box: Robarts Research Institute email: lrb@rri.uwo.ca Clinical Trials Resources Group fax: 519.663.3789 P.O. Box 5015, 100 Perth Dr. vox: 519.663.3787 ext. 4108 London, Canada N6A 5K8
kessler@hacketorium.Eng.Sun.COM (Tom Kessler) (10/31/90)
I wholeheartedly aggree with having one sendmail.cf file for all of
your "drone" machines.
In fact we do something a lot like that at Sun where we use the
sendmail.subsiary.cf file (included as the default /etc/sendmail.cf file
in sunos releases) on all but about a dozen machines here in Mt. View.
I also encourage people to NFS mount their /var/spool/mail directory and use
the OR (remote mode) option so that mail for most of a group appears to
come only from a single server. This helps to keep reply's to messages sent
from machines which are now down from sitting around for a long time.
Note that it's pretty easy to modify a sendmail.cf file to do
something like this even if you don't want to use (or don't have)
the OR (remote mode) option in sendmail.
We've broken up our organization into a couple of of administrative
"domains" (Note these are only roughly related to the domains we
use for name service and NIS), each of which knows how to get to other domains.
Currently they have names like .Eng.Sun.COM, .Corp.Sun.COM, East.Sun.COM,
West.Sun.COM, Ebay.Sun.COM and etc.. Within these domains there are aliases
(maintained by NIS) for each person directing mail to the machine which holds
that persons mailbox. Note that if you don't like NIS you can accomplish
the same thing by maintaing an /etc/aliases file with rdist. This takes
a great deal of load off our mail routing machines (fighting high
mailrouter loads becomes an important issue when you process something
like 6000 messages an hour each monday morning) because mail is sent
directly to the machine with a users mailbox if that user is in the
same mail domain as you are. If the address (or alias) for the person
you are sending mail to is in another domain your mail is passed on
to the host named "mailhost". The mailhosts are used solely for mail
routing and Usenet servering and each deal with about 1000 to 2500 users.
We've worked very hard to keep the number of the mailhost machines to an
absolute minimum (there are about 5 in the Bay area) as everyone from the
CEO to Janitors rely on email to get their work done. Most everything else
runs with the stock sendmail.cf file. The only exceptions I know of are
machines with gateways to other networks (X.400 connections, uucp, etc.)
On our mailhosts we invert aliases (and extend the domainname if necessary) on
the from lines of the mail going to other domains. In addition to Sun's
sendmail I believe that the latest IDA sendmail enhancement package has a
hook for doing this.
For example other people in .Eng.Sun.COM see mail coming from
kessler@hacketorium, people in other domains see mail coming from
kessler@Eng.Sun.COM and people outside of Sun see mail coming
from kessler@Sun.COM (or at least that's the theory). I recommend
inverting aliases because if you don't have an alias in the domain
mail routers map your mail is still replyable. For example if someone
misspelled my name in the Eng aliases map you would see mail coming
from kessler@hacketorium.Eng.Sun.COM, if I didn't have an alias on
sun.com (most people at sun don't) mail going to the outside world
would appear to come from kessler@Eng.Sun.COM.
We encourage our users to address their mail as username if the person is
in their area or as username@DOMAIN if the person is in one of the other
domains.
On our main mail router (which appears to be sun.com from the outside
world) we try to have an alias for everyone with their first initial
and last name (we have program called ambigmail which handles the case
where an alias is ambiguous by mailing you a list of the possible
choices).
By the way at least on suns you can run sendmail.mx to talk to the
resolver independent of what's in your libc (i.e. the resolver support
is built into the sendmail.mx) so all that you would need to do to use
MX records is to move sendmail to sendmail.nomx and sendmail.mx to sendmail.
--Tom Kessler, Sun Microsystems Internet Engineering Group
<kessler@sun.com>
P.S. For those of you at sun who've found errors in my above description
please send me mail directly and I'll post corrections, I'd like to
avoid the confusion of having dozens of people post corrections.