tsmith@USNA.MIL ("Tim G. Smith", Mechanical) (05/18/88)
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
bae@ati.tis.llnl.gov (Hwa Jin Bae) (05/20/88)
In article <8805180903.aa03398@CAD.USNA.MIL> tsmith@USNA.MIL ("Tim G. Smith", Mechanical) writes: >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. No offense. But in my view MMDF has far better design than sendmail. I don't see why you would go from MMDF to sendmail. The other way around makes much more sense. I guess I've actually lived long enough to hear someone say "I LIKE SENDMAIL!". sendmail is a very sickening piece of software - overblown, unnecessarily complicated, huge Mo.Fo. I don't know how you are using MMDF but it's concept is closer to modern mail system models like X.400 where several delivery mechanism can be handled transparently. MMDF allows you to have separate processes for mail delivery channels which can be totally different. One of the channels may be sendmail since it does implement SMTP. I would prefer to use simpler SMTP mailer though. It's truely incredible to see how a Simple Mail Tranfer Protocol can be implemented in such Complex ways (as in sendmail), which tries to do too much. I think I've work on sendmail code enough to know that it is the ultimate example of the BSD mentality - 10 times more flexible but 100 bigger and more complex. ----- Hwa Jin Bae | The Devil made me do it...yeah, that's right! Control Data Corp. | (415) 463 - 6865 4234 Hacienda Drive | bae@tis.llnl.gov (Internet) Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae (UUCP)
piet@cwi.nl (Piet Beertema) (05/20/88)
>No offense. But in my view MMDF has far better design than sendmail. >I don't see why you would go from MMDF to sendmail. The other way around >makes much more sense. I guess I've actually lived long enough to >hear someone say "I LIKE SENDMAIL!". sendmail is a very sickening >piece of software - overblown, unnecessarily complicated, I like sendmail too, for various reasons. But this is not exactly a newsgroup to fight out a largely theological discussion. -- Piet Beertema, CWI, Amsterdam (piet@cwi.nl)
pdb@sei.cmu.edu (Patrick Barron) (05/20/88)
In article <22208@tis.llnl.gov> bae@ati.tis.llnl.gov (Hwa Jin Bae) writes: >I don't know how you are using MMDF but it's >concept is closer to modern mail system models like X.400 where several >delivery mechanism can be handled transparently. MMDF allows you to >have separate processes for mail delivery channels which can be totally >different. sendmail will let you do exactly the same thing - it's not just a big, complicated SMTP implementation. It can do UUCP, BITNET, SMTP, local Unix mail, etc. It can let you vary how (or if, at all) a message gets delivered depending on what the address looks like and/or who the sender is. You can define different mailers which use the same delivery mechanism but with different parameters. I'll certainly admit that it's very complex, probably much more so than it needs to be - especially if you have to hack the configuration file. [Usenet followups redirected to comp.mail.sendmail] --Pat.
nsb+@ANDREW.CMU.EDU (Nathaniel Borenstein) (05/24/88)
It sounds like you might be interested in the Andrew Message System. AMS was designed for the Andrew File System, but also works on NFS or with no central file system. Most of it is distributed as part of the Andrew release on the X11 R2 tape from MIT. (Some parts of it haven't made it onto the R2 release, but are expected to be on the R3 release this fall.) A good overview paper about it can be found in the February, 1988 USENIX proceedings. Basically, it does just about everything you ask for and a whole lot more, including, IF you're on a high-function workstation running X11, handling multi-media mail with rasters, animations, music, and so on. For more information, especially if you can't get ahold of the USENIX paper and/or MIT release, please send mail to me or to info-andrew@andrew.cmu.edu.