Xref: utzoo comp.mail.sendmail:2330 comp.mail.misc:4250 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!rex!wuarchive!swbatl!texbell!moxie!texsun!newstop!exodus!kessler From: kessler@hacketorium.Eng.Sun.COM (Tom Kessler) Newsgroups: comp.mail.sendmail,comp.mail.misc Subject: Re: Mail architecture Message-ID: Date: 31 Oct 90 02:27:50 GMT References: <1990Oct29.170344.27870@kodak.kodak.com> Sender: news@exodus.Eng.Sun.COM Followup-To: comp.mail.sendmail Distribution: na Organization: Rocket Scientists Anonymous Lines: 77 In-reply-to: mccrave@kodak.kodak.com's message of 29 Oct 90 17:03:44 GMT 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 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.