Mail Servers for Campus Networks ---- ------- --- ------ -------- This report is the result of a questionnaire on computers that act as "electronic-mail servers" on campus networks. The specific goal of the survey was to figure out what size of computer is necessary to serve a campus. The slant is towards universities and similar institutions. Below is a copy of the questionnaire, and another copy of the questionnaire with the answers I received following each question. Unfortunately, I forgot to ask permission to publish the names of all the respondents, thus I have chosen to keep the answers anonymous. You will probably note that the questionnaire could have been better, something I can easily see in hindsight. Many thanks to all who responded. John Wobus Syracuse University =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Questions on computers acting as mail servers/relays: Roughly how many people does it serve? What computer & what operating system? Roughly how much disk space does it use for electronic-mail functions (i.e., if mail is its only function, how much disk is on the system)? How much primary memory? Is it well-fitted to the application? Too large? Too small? Does it also carry out non-mail-related functions (e.g. general purpose timesharing)? Does using a separate computer have any particular advantages? Which of these does it do: forward mail; run user mail applications; run a directory server (e.g. whois database); other mail-related applications? What software does it use to do each of these? Have you collected any "mail statistics"? If so, do you see growth? Any big problems with the system? Anything special that you would or wouldn't do again if you were setting something like this at another University? How do you estimate the necessary staffing to run it (e.g. full-time operator; half of full-time systems programmer, etc). Do you know any other places I might contact which are doing something similar? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The same questions along with answers from several sites: Roughly how many people does it serve? 600> 600 use for time-sharing system to read and compose mail, it 600> performs mail gatewaying for another 300. 800> About 800 1000> 1000 3000> 2500-3000 students/staff/faculty 10000> 10,000, plus two or three large mailing lists 11000> We have roughly 11000 names in the on-line directory. In 11000> one sense all of these people are served by umail since one 11000> of the functions is to act as a forwarding agent. There 11000> are three major functions umail provides. The forwarding 11000> service, the online directory service (names, phone 11000> numbers, email addresses, etc.), and the umail user mail 11000> service (for sending and receiving mail). 11000> 11000> Currently 1200 people are registered as umail users, about 11000> 350 are active users of the mail interface. 37000> They serve 37,000 users plus MX forwarding for over 30 other 37000> sites. What computer & what operating system? 600> VAX 785, ULTRIX 800> IBM 3090-300S, VM/HPO 4.2 1000> Sun 4/280 SunOS 4.0.3 3000> VAX-11/750 w/ ULTRIX V3.1 10000> For mail, 4 RT PCs,... 10000> For bboards, another 4 RT PCs,... 10000> All this is tied to a central file storage system, AFS, which 10000> provides all file storage for those users... on 20 separate 10000> sun3-class servers. 11000> Currently we use a DECStation 3100 running Ultrix. 37000> 3 processors: 37000> - Sequent Symmetry: 6 processors (386), 32meg 37000> (also does general purpose timesharing--up to 200 users). 37000> - Vaxstation 3500 (BSD 4.3) 16 meg memory, uses about 90 meg 37000> for mail purposes. 37000> - Vaxstation 3500 (Ultrix): acts as DECnet gateway. Roughly how much disk space does it use for electronic-mail functions (i.e., if mail is its only function, how much disk is on the system)? 600> 3.0 Gig 800> MAILER has a 10 cylinder 3380 A-disk 1000> 20 Meg 1000> (i.e., if mail is its only function, how much disk is on the system)? 1000> 892 Meg 3000> 80Mb for Mail and News combined. 10000> (For mail, 4 RT PCs) 40-70Meg per machine hard drives. 10000> (For bboards, 4 RT PCs) comparable hardware. 10000> (For central file server, mail an otherwise) about 30 GBytes on 10000> 20 separate sun3-class servers. Of that central storage, 10000> arbitrary amounts could in principle be consumed by bboards: I 10000> expect that about 500MBytes is tied up in public bboards. 11000> The amount of space used increases as the user base 11000> increases. We currently do not have any quota limits in 11000> place but expect to limit users to 2 Megabytes of disk 11000> storage each. How much primary memory? 600> 32 Meg 800> 128 megabytes! 1000> 16 Meg 3000> 8Mb 10000> (For mail, 4 RT PCs) two with 8Meg, two with 4Meg. 10000> (For bboards, 4 RT PCs) comparable hardware. 11000> 8 Megabytes Is it well-fitted to the application? Too large? Too small? 600> Woefully undersized. 800> Yes, indeed. 1000> Well-fitted 3000> The VAX-11/750 is to 3000> old/small/slow/tired/expensive_to_maintain for all it does. 10000> It's on the edge of too small; the mail (PO, Post Office) 10000> machines are often swamped. 11000> It seems to be able to service the current user base with 11000> fairly quick response times. Of course during peak periods 11000> service levels decline. Does it also carry out non-mail-related functions (e.g. general purpose timesharing)? 600> It is almost 100% mail use, including bulletin boards, 600> which are a pretty big part of the load. 800> Yes 1000> It is also news server, time server, domain name server, 1000> slip server. Very little gp timesharing usage. 3000> News, File server for most all user files, Yellow_Pages 3000> secondary server (slave), secondary name server, Mop_mom 3000> boot server (not used much), remote installation server 3000> (used only for system upgrades ... eg not much), UUCP, FTP 3000> server. 10000> The four dedicated PCs don't, but AFS does it all. 11000> No, it services the umail related functions only. Does using a separate computer have any particular advantages? 600> I guess one advantage is that we can use UNIX, which is 600> very good for mail, and we can use our HPs and IBMs for 600> administrative stuff which I assume that they are good for. 600> We definitely could not run the caliber of mail system we 600> want on either of those systems. 800> Yes 1000> Yes. Not affected by time-sharing users. 3000> Yes - common location for both inhouse systems with our 3000> primary mail machine and the interface to the outside 3000> world. Basically for all but the primary mailserver, one 3000> can setup a simplified sendmail.cf which can be used as a 3000> simple template for other systems (and give to other system 3000> managers) in your domain. You have much more control over 3000> trouble shooting your communications with the outside world 3000> from a centrally located mail server. 10000> That's the only way our architecture would do it. For that 10000> matter, we have to address scalability that way, since a baby RT 10000> couldn't handle 10K users. We've achieved that scalability, we 10000> think. 11000> We can more easily create a closed system. The umail user 11000> currently accesses the umail system and is placed in a menu 11000> oriented environment with lots of user help and assistance. 11000> They do not have access to the underlying system. Most do 11000> not know that they are running on an Ultrix system. Which of these does it do: forward mail; run user mail applications; run a directory server (e.g. whois database); other mail-related applications? 600> We do not currently run a directory server. We do almost 600> everything else connected with mail. Mailing lists are big 600> here. 800> We have a home-brew user directory system that allows users 800> to known by their "personal" name (e.g. John.Doe@abc.edu). 1000> POP server, mail forwarder, runs our ACSnet and slip 1000> connection to another University. Will be our directory 1000> server once we get a decent X.500. 3000> All mail from the other systems in our domain is sent to 3000> the mail server for distribution. All aliases are resolved 3000> on the mail server. Since the mail server is also the file 3000> server for (almost) all users the delivery from the server 3000> for all local mail is local to that system. The user files 3000> are mounted via NFS to the other systems. Mail to 2.10bsd 3000> and VMS has to be forwarded. Mail to MACs and PCs is sent 3000> to the POPserver which is also the Mail server (eg local 3000> holding pen) where the MAC and PC user eventually pick up 3000> their mail via POP using SU-MAC/MH or SU-PC/MH from 3000> Stanford University. We have experimented with Stanford's 3000> netdb whois server/database but never really set it up for 3000> other than a couple of test entries. Lack of 3000> documentation/support (at least bug fixes) is why we didn't 3000> go further. We may set up NYSERNet/PSIs White_Pages later 3000> this semester. 10000> Forwards, runs a directory service (via White Pages files that 10000> it maintains in AFS). The bboard machines run "privileged" 10000> programs to maintain the bboard database. Explodes 10000> user-maintained distribution lists. But user mail applications 10000> run on their own workstations, connected via the common file 10000> system. 11000> One interesting feature is the automatic printing of email 11000> that is being sent to non-email/umail users. That is, for 11000> those users that have never used umail, and have not 11000> indicated to the personnel office an email address, any 11000> mail sent to them will be printed and deliver by campus 11000> mail. 37000> Forwards mail What software does it use to do each of these? 600> We run MMDF, MH, and a small amount of custom stuff, mostly 600> shell scripts that we've coded in C for performance. 1000> MH POP, Stanford Uni Mac/MH and Pc/MH, ACSnet, Slip, sendmail 3000> Sendmail (eg unix bsd mailers), mail-11 (talks to VMSMail 3000> and PDP-11 mailers if I had 'em), Rand's MH, Stanford's 3000> SU-MAC/MH and SU-IP/MH. We will be adding Joiner Assoc. 3000> JANET software as soon as the State contract is in place. 3000> On our VMS boxes we're using DECUS-UUCP to munge the mail 3000> headers - whether we stick with DECUS-UUCP or go to PMDF 3000> when we get JANET up and running is unclear at this point. 10000> Generally, the Andrew Message System, now distributed with 10000> X.V11R4; a bit of well-worked-over and lobotomized UCB sendmail 10000> to do the long-haul message transport; and AFS, now available 10000> from Transarc. (UCB sendmail knows nothing about our local 10000> names and its namespace.) 11000> The software has all be developed here. 37000> They use CSNET central server code 37000> Server code: QI 37000> Client code to update server: PH or TH (?) 37000> Interface with sendmail: phquery (locally written) Have you collected any "mail statistics"? If so, do you see growth? 600> We collect statistics. We saw rapid growth until we 600> outgrew the machine. Then we saw moderate growth until the 600> machine was so overloaded it was intolerable. From my 600> experience, demand will expand to consume available 600> resources for at least an order of magnitude from what we 600> are doing now. In particular, bulletin boards usage could 600> easily go up by a factor of 10 if the machine could handle 600> it. 800> No data, but we see lots of people using it. 1000> No. Yes. 3000> No real statistics have been collected. We get UUCP (eg ! 3000> routed) stats but don't really even look at them except for 3000> trouble shooting. However, we do have a "gut feeling", 3000> based on user's questions/requests and the occasional look 3000> at the size of the /usr/spool/mail partition that the use 3000> of Email has expanded every semester. 10000> Sure: we receive and file about four messages a minute in our 10000> bboard system. I'd guess we exchange about 2000 messages a day 10000> with the outside world, but it's been a while since I looked. 10000> Yes, there's growth; load probably doubles every two years. 11000> Yes, there is definite growth. In July '89 there was about 11000> 250 unique users during the month. During November the 11000> equivalent number was about 420. In between, the increase 11000> appears linear. 37000> They handle 6000 messages/day Any big problems with the system? 600> 1. System should be about 10 times bigger. 600> 2. The MH interface, while very powerful, and surprisingly 600> popular with NSF staff, is very difficult for 600> non-computer literate people, and we have a lot of 600> turnover here. Also the command-line approach seems a 600> little dated. However, there is very little someone 600> wants to do but can't, they'd just like to do it 600> easier. 800> NO, we are quite pleased. It would ne nice if 800> MAIL/MAILBOOK were written in a compiler language for 800> performance reasons. 1000> No. 3000> None really as far as functionality is concerned. The 3000> VAX-11/750 is slow/old/tired and maintenance costs are to 3000> high for the performance ... BUT IT WORKS! (ain't broke 3000> ... don't fix it). 10000> Nah; works fine. Needs a bit more horsepower over which to 10000> distribute its services. 11000> Maintenance seems to be one issue worth seriously 11000> considering. We must obtain regular updates from the 11000> personnel office for the directory. This sometimes means 11000> their online directory is a couple of weeks out of date. Anything special that you would or wouldn't do again if you were setting something like this at another University? 600> As you can expect from the above comments, we'd have 600> planned for a bigger machine. At this point, however, 600> given the economics of the thing we'd probably go entirely 600> with a PC-based system. 1000> It would be nice to have directory services from day 1. 1000> Also we should have hid the machine name from day one. We 1000> are just about to change so that mail is rewritten as 1000> username@host.abc.edu 3000> Start using whois/White_pages/netbd or something right at 3000> the start. Have all workstations use POP rather than be 3000> the destination for the mailers. Thus when the workstation 3000> user powers down for vacation their mail doesn't go to left 3000> hyperspace while they are away, having the sending parties 3000> screaming at the domain administrator about the down 3000> machine. 10000> I'd do it again, if I could talk the powers that be into buying 10000> AFS for us. 11000> We are changing this system into a client-server based 11000> system so that people will be able to use the mail 11000> interface from their favorite workstation. If I were to do 11000> it over again, I would probably have skipped the remote 11000> login scheme we currently have and gone straight to the 11000> client server model. We are currently limited to the 11000> terminal device characteristics for display and user 11000> interactions. This means we can't use function keys 11000> effectively, we are limited to normal character display, 11000> etc. How do you estimate the necessary staffing to run it (e.g. full-time operator; half of full-time systems programmer, etc). 600> 2 full time people, plus a manager, and some operator time 600> to do disk backups. 800> All our mail operations on all systems might be a 1/2 time job 800> for one person. 1000> Don't waste money on an operator (biased). 1/2 Systems 1000> Person would be fine. 3000> Our Systems Programmer estimates that he spends 1/2 to 1 3000> hr. per week on mail related problems. 10000> One full-time person, I guess. Currently the load is split 10000> among a little bit of many different people. 11000> Postmaster functions, directory updates, and general system 11000> maintenance take a little more than 1/2 time system 11000> programmer. Development can be as much as you are willing 11000> to spend. We have the equivalent of 1 full-time programmer 11000> doing additional development. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=