Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!USNA.MIL!tsmith From: tsmith@USNA.MIL ("Tim G. Smith", Mechanical) Newsgroups: comp.protocols.tcp-ip Subject: SendMail Message-ID: <8805180903.aa03398@CAD.USNA.MIL> Date: 18 May 88 13:03:48 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 222 This is a long message. If your aren't interested in sendmail and large networks then you might as well skip this message. You may have seen this message elsewhere as it is being cross posted to big-lan, sun-spots, nfs, tcp-ip, and unix-wizards. If there is a more appropriate list to discuss this in let me know and I will take this matter there. We here at the US Naval Academy (USNA) in Annapolis, MD are building a network. We have been operating an ethernet LAN connecting several minis and workstations for quite some time. We use thin, thick, and fiber based ethernet. We are reasonably well versed in TCP/IP and have experience with mpr's and gateways. Our hosts run the gamut from Zenith PC AT clones using SUNs PCNFS package to SUN workstations to VAX and Gould minis. We have about 20 hosts on our network that are capable of exchanging mail via sendmail. We are in a growth process and expect our number of workstations to increase dramatically as our new network is installed and more folks buy workstations. It is quite possible that we will eventually have 4-7k workstations and their servers attached to our network in the future. We currently use MMDF as our mail handler but are in the process of switching to sendmail as sendmail seems to be emerging as the "standard" mail handler. I have been selected to work on installing sendmail and planning our mail routing system. I have spent a reasonable amount of time working with sendmail and thought I would ask around to see if what everyone else is doing. Here is what I am planning/doing.... Some background... First, USNA will switch from 2 level domains to 3 level. Currently hostnames are of the form "machine.USNA.MIL", in the near future hostnames will change to the form "machine.division.USNA.MIL" (if necessary we might even switch to 4 level domains- "machine.department.division.USNA.MIL"). There will be an authoritative host named USNA.MIL. There will also be a host (or possibly an alias pointing to a host) for each sub-domain, ie there will be a sub-domain named "math.USNA.MIL" with a primary server named "math.USNA.MIL". Second, every user's home directory will be made available to him on every workstation in the yard. The goal is to allow any user to sit down in front of any workstation in the yard and be able to login and have his files available. Yes, I realize that will involve a tremendous amount of NFS cross mounts and may not actually be feasible but that is the plan for the time being. How the password file updates will be made has not yet been determined. Ideally I would like to use SUN's Yellow Pages to handle all of the password mess. I am not sure how may vendors do/will support YP but I will worry about that problem later. I have come up with the following tenets that I think are wise. If you disagree then send me mail and we can discuss it- maybe we all can learn something new about sendmail. I would prefer that all responses come straight to me and I will summarize to the net if there is interest. Maybe there is enough interest to start a sendmail interest group (provided there isn't already one that I don't know about). Sendmail workstation/server configuration philosophy: (aka "the gospel according to tim") ------------------------------------------------------- -All mail should live on a sub-domain host. Individual workstations should never receive incoming mail- there WILL NOT be a mailer daemon running on the workstation to receive incoming mail. Whether mail will live in /usr/spool/mail or the user's home directory is yet to be decided. I am leaning towards hacking sendmail to put mail in the user's home directory. -Workstations punt all mail to their sub-domain server. Workstations exchange mail only with their sub-domain server. Only outgoing mail is handled by workstations. -Workstations should have very minimal configuration files on them. Workstations should have a sendmail.cf that is virtually identical to all others in the yard. Workstation sendmail.cf's should essentially be "maintenance free". -The address data in intra-USNA messages will never contain a workstation hostname- only sub-domain names will be used. (There will be a host or host alias with the sub-domain name.) -Inter-sub-domain mail (ie intra-USNA) can be directly routed from one sub-domain server to another. -Mail bound for destinations outside USNA will be routed from the sub-domain host to the USNA.MIL server. This mail will have USNA.MIL in the address lines. Sub-domain names will never appear in outgoing message address lines. This will allow USNA.MIL to reliably accept mail from the outside world regardless of the status of the internal USNA network. -Mail arriving at USNA.MIL from outside hosts will be forwarded to the proper server using a large central data base of aliases on the USNA.MIL server. Individual users will also be able to forward their mail via the .forward file in their home directory. ---------- End of Philosophy Statement-------------------- Here is a typical scenario that I imagine... User "joe" invokes the sending front end to sendmail on his workstation. He composes and addresses a message to user "mike" and hands it to his mail agent to pass to sendmail. Sendmail on the local workstation starts up and the following takes place: 1) The workstation punts the message to the sub-domain server. 2) The sub-domain server tries to deliver the mail. If the sub-domain-server finds that "mike" is a user who gets his mail on this server then the mail is delivered as per sendmail's local mail delivery procedures. If the sub-domain-server finds that "mike" is a user who gets his mail on another sub-domain-server then the mail is passed to that server. If the local sub-domain-server cannot determine where "mike" gets his mail then the message is punted to USNA.MIL (the next level up the domain ladder). 3) USNA.MIL gets the mail and tries to deliver it. If USNA.MIL knows who the user is the mail will get delivered- if USNA.MIL doesn't know who the user is then that user doesn't exist and an error should be returned to the sender. What needs to be done to make all this happen is not yet known. SUN's Yellow Pages service either complicates or simplifies this whole issue. Do we expect all the machines in the yard to understand YP (it would sure be nice if they did!)? I doubt that I can count on all of the yard understanding YP. I am open to suggestions/opinions, one way or another. ------------------------------------------------------------ Problems I for see: -All sorts of "odd" cases... A user could be logged into a workstation in a division other than his own sending mail to anyone. Not a major problem but something to keep in mind when "Reply-To:" and "From:" lines are being set up. What should the "Reply-To:" and "From:" lines say? Should they list the sub-domain server that the user is sending from? Should they list the user's "home" sub-domain? (I would tend think so.) If the mail is addressed to someone outside of USNA then the problem will go away since (according to the tenets above) all mail leaving USNA should have its "Reply-To:" and "From:" fields rewritten to the form "user@USNA.MIL". A user may prefer to receive his mail on a machine other than his "home" sub-domain server. No big deal, a .forward file should handle this without any problems (I think). Where do aliases get expanded? I have just about ruled out an alias expansion on each workstation. I would think that they could be expanded on either the sub-domain server or on USNA.MIL (or maybe on both). -Conflicts over file locking and simultaneous access to the user's mailbox. Here is a possible scenario of locking problems... User "joe" is reading his mail on workstation "xxx.math.USNA.MIL". joe's workstation is diskless and mounts its files from his sub-domain server. In order for this to happen the directory that joe's mailbox lives in will have to be NFS mounted on his workstation. For joe to be able to delete messages from his mailbox he will need write permissions on his mailbox. Thus the NFS mount of the directory containing joe's mailbox will have to be mode "rw". I see a potential problem here. If joe is has just finished deleting messages from his mailbox and is updating it when a new message comes in (ie math.USNA.MIL tries to deliver it) there could be an ugly scene as the process trying to purge the deleted messages from the mailbox and the delivering agent fight over who gets to write in the mailbox file. So what happens in the above case? -Where do users mailboxes live? If I already have all sorts of home directories NFS cross-mounted all over the place I certainly don't want to add to the mess by cross mounting /usr/spool/mail all over. Not to mention what do I call the directories? I would be NFS mounting several different /usr/spool/mail directories from several different servers. I have already ruled out the idea of a single machine with a massive /usr/spool/mail for several reasons. Ideally I would like to have each user's mailbox live in his home directory. -------------------------------------------------- Sendmail Gripes: -sendmail.cf cannot find out its domain (or subdomain) internally (at least I can't figure out a way to do this). This would be a nice feature to have so we don't have to hard code this info into each sendmail.cf. (Isn't there a system call that returns the domain name of a host? How about adding an internal macro to sendmail to add this feature.) -It should be possible to configure sendmail to have the user's mailbox live anywhere (Like maybe their home directory). Well that is about it. I would like to hear from others- sendmail experiences, solutions to my problems, ideas about what to do next, or just commiseration would all be appreciated. NOTE: I LIKE SENDMAIL! I think it is very flexible and powerful. I am simply pointing out my difficulties (and non-difficulties) and asking whatcha'all think. So please spare me any flames telling me I don't appreciate sendmail and that I should be condemned to an afterlife in a post office in hell doing "manual mail routing". OK? Looking forward to hearing from everybody, Tim Smith US mail:CADIG mailstop: 11G E-mail: US Naval Academy internet:tsmith@USNA.MIL Annapolis, MD 21402 uucp :...!uunet!usna!tsmith MaBell :(301)267-4413