SLAC EMAIL

Current and Future

Teresa Downey

6/9/99

Current Status

Mail through are main gateways is increasing at approximately 25% per year with the current daily rate at about 40K/day. We have a 6 MB size limit in our gateways. We are running two offsite email gateways; one internal SMTP server; a Unix mail spool server; a POP server; an IMAP server; and an LDAP server. Here is a pictorial view of the SLAC Email topology.

We have a Mailrouter database which allows users to have generic email addresses such as: fname.lname@SLAC.Stanford.Edu or userid@SLAC.Stanford.Edu

Average disk usage for IMAP user is 30MB; average for POP user is .8MB; average for unix mail user is 1.6MB. We currently have no quotas implemented.

We support Eudora and Pine email clients. Although a significant number of people are using Netscape. Our POP and IMAP servers are from UW and we authenticate via AFS or NIS passwords. Our SMTP servers do not support authenticated SMTP via a mechanism which we could incorporate.

There is a summary of all our hardware and software in SLAC Servers and their Functions.

We have been buying one new Solaris system per year for the past several years to accomodate increased load and enable us to separate functions into different servers.

Future Plans

We need to prevent clear-text passwords for email as soon as possible. We also want to get away from using an NFS-mounted POP and IMAP mail spool to reduce locking and email loss problems. There is still ~1400 users who are not currently using POP or IMAP (perhaps using Pine in non-IMAP mode, exmh, elm, etc.) and they may choose to continue to use an NFS-mounted mail spool. In addition, POP and IMAP is running on a couple vaxclusters and these users would have to shift over to using the centrally supported email server because we would require all other POP and IMAP servers to be shutdown.

We have tested Sun's SIMS server and found it lacked ease of configurability and had only a GUI management interface which we felt was not sufficient. We also tested Execmail's server and it did not work in our Kerberos4 environment.

We are currently testing an "email appliance" from Mirapoint, Inc. It supports SSL (NIS authentication) for POP and IMAP and Kerberos4 for IMAP. We have open questions to them about being able to authenticate via our AFS password. We have successfully used SSL for POP and IMAP, but have been unable to prove that Kerberos works.

For administration purposes it supports Secure HTTP for web-style command interface and SSH for a line-mode command interface.

We will probably shift our support to Netscape from Eudora since the SSL authentication is so much simpler than Kerberos to implement and Mirapoint server does not support Eudora as a client (currently). There are pros and cons for both SSL and Kerberos. If we went with Kerberos we'd have to deploy PC-Leland for all the NT's and Macintosh's and the users would have to start this up before email to get their ticket, but we could assign people to particular mail servers via DNS CNAMEs. If we went with SSL we'd be able to avoid PC-Leland but we'd have to assign users to particular mail servers from Day 1 and if we ever needed to move them from server to server it would take coodination with the user. Either way we'd need Kerberos for the Pine users.

We expect the test of the Mirapoint server to last until the end of July 1999. The topology of our email network would be simplified at this time to remove the UW POP/IMAP servers. The pictorial view of this can be found in Proposed Email Topology. We would replace the two OpenVMS systems (Serv04 and Serv05) with freed up Solaris systems at this point too.