To members of the Miami Email project team: We need to get together to finish up our recommendations with respect to electronic messaging at Miami. In light of the request from the MCIS senior staff to John Harlan, reproduced below, we need to reconvene to make a recommendation on workstation email services to be included in the network services plan. Our goal is to produce a list of recommended services that can be recommended to the Network Services planning group identified below. Linda Rose will be contacting you to set up a meeting. As a refresher, I have attached the April 24 version of our email recommendations. If you have questions or comments in the meantime, please let me know. Thanks, Debi *********************** Text of memo to John Harlan: *********************** As we have discussed, the MCIS senior staff has assigned you to serve as the chair for a network services group, with the charge of drafting a network services plan to accompany the Data and Video Network Plan. The services plan should outline what services are recommended to be made available via a network connection, with an indication of the infrastructure and staffing requirements to support these services. The needs of the regional campuses and students not residing in Miami residence halls should be included. Please consider, insofar as possible, the implications of a student laptop initiative on these services. As an example, Gartner Group recommends that a single network communication session should cause several activities to occur, some unbeknownst to the client (e.g., backup of the client's hard disk, upload/download of email, transparent software updates). The MCIS Senior Staff requests the following people to be assigned to assist with the draft of the services plan: John Kinne Peter Murray Bill Sylvester John Vaughn I have spoken with each of them and they have agreed to assist with this project. It is anticipated that this group will need to meet with various other individuals as part of the plan's development. Please target January 6, 1995 as the date for presentation to the senior staff on Monday, January 9. [end of memo] <<<<<< Attached TEXT file follows >>>>>> This version of the Email project recommendations includes comments and recommendations added by Barbara Edwards, and includes answers to her questions/concerns that I have received to date. I am circulating this version in advance of the July 8 deadline to assist you with further comments you may wish to add. Next steps: We need to develop a task list of items to be accomplished, with responsible person listed and timeframes listed. The resulting recommendations will be presented to the Microcomputer Committee and then to Kris Froehlke. Email Project - Recommendations March 28, 1994 April 13, 1994: Barbara Edwards comments added June 28, 1994: responses to Barb's concerns/questions added. Subgroup members: Debra Allison, Kent Covert, Barb Edwards, John Harlan, Peter Murray, Rob Pickering A. Recommendations - Qi server/Ph client; Mail Redirection 1. Qi and In-bound Mail Redirection: up in test this summer; in production before Fall 1994 on Rose and/or VMS (Technical Services to decide, in consultation with Client Services (John Harlan) and Instructional Computing (Barb Edwards)). 2. University Directory Survey: (a) ask for preferred email address on form requesting directory updates; (b) include Library question [what does this mean?] or statement on email notices. John Harlan to contact Publications to get this included. Barb's comments: Have we requested that a system be built to maintain the Qi directory? a. Is there a process being defined for taking the information off the directory update forms and updating the Qi server? Answer: No, we will be using the appropriate university databases for student, faculty and staff data. b. Are we defining a process for coordination between updates of hard copy and availability of softcopy updates? Answer: There will be periodic updates from the university databases - typially, one week, but during parts of the year as often as once per day. This will be scheduled as a production job with MCIS Customer Services. c. Are we defining procedures for coordination of the installation of undergraduate accounts and the updating of the Qi server. Answer: as soon as undergraduate accounts show up on the mainframe, they will be put in the Qi server. This will happen daily, coming from the user lists. d. Will the e-mail addressed be part of the paper directory? Answer: No; Publications is unwilling to do this due to the additional cost. e. What is the procedure for documentation and updating of such? Answer: We will have MCIS documentation for the process. Client instructions will appear in this fall's directory. f. What about "unlisted numbers"? Answer: The data going into the Qi directory is the data that the faculty, student or staff authorizes to appear in the directory. Anyone who tells the Registrar or Personnel that they do not want to be listed in the directory will not appear in the Qi server. We can also remove someone from the Qi directory. 3. Kerberos: Investigate using Kerberos authentication as university-wide security scheme. Goal: a university-wide security scheme in place by Summer 1995 (we recommend Kerberos). Steve Moore to look at Kerberos on VM. Barb's concern: There are several issues with regards security left over from old discussions. Has John Andrea been involved? Answer: Discussions have been held, but more work is needed. A security audit needs to be done on Rose. Currently, no confidential data is being stored on Rose; it is stored on secure systems. 4. Passwords in Qi database (to allow modifications to data elements in Qi database): we recommend that the database be (a) modifiable and (b) authenticated (to be determined by Client Services, Technical Services, Security, in consultation with Internal Auditing). This is a long-term recommendation, tied to Kerberos implmentation. 5. Queries to the Qi databaseto be provided via: a. Gopher and Web (Fall 1994) b. Ph client (Fall 1994 in test, but unsupported - at Level 3+) c. Mail packages - ASAP; tied to selection of mail packages. Barb's concern: Will all this be added to enduser on VM? Will there be DCL and Scripts written for VMS and UNIX for the clients to use? Is technical services exploring this issue? Answer: Queries can be made from Miami Root, which is accessible from the new EndUser. We will be asking Steve Moore about giving direct access from EndUser. The Ph/Qi package provides for queries on VMS and UNI. 6. Alias structure in Qi data base recommended to be: a. unique b. eight characters c. same as university-wide account ID (Tim and Barb have different recommendations on this -- Tim: 1st 6 characters of last name, first initial, middle initial (to permit sorting by last name); Barb: first initial, middle initial, 1st 6 characters of last name (to correspond to exisiting IDs). We recommend that the Qi alias be: first initial, middle initial, 1st 6 characters of last name, except in the case of a duplicate where a digit is needed to distinguish, e.g. RAPICKER RAPICKE1 RAPICK10 RAPIC100 What will "from" address show to the world? Does it have to be the alias, or do we want it to be? John Harlan to check with Notre Dame, since their "from" addresses are "friendlier." Rob to check if Qi and Kerberos ID name limitations are 8 characters; he will also try to find out about X.500. We recommend Mail.Name@domain for use by sender when email address is unknown. Example: [log in to unmask], [log in to unmask], [log in to unmask] will all cause the message to be sent to Peter E. Murray's preferred email address. If P.Murray is used and there is more than one match, information on all matches will be returned to the sender as bounced mail and sender will choose based upon info in Qi database. Barb's comments: Please add as a recommendation: There will be a record in the directory entry that identifies the real person by full name and Miami Id number (currently social security number is used). This comment should be consistent with the personnel record or the student master file record. Answer: The personal data comes from the Student Master file and the Personnel data base. Neither Miami ID number nor Social Security number are displayed. For ids not associated with a single person there will be a person identified for that mail box and that person will be recorded in the comment card. Answer: This needs to be part of the account generation policy and process as it cannot be done within Qi. This comment and the userid should be in a file or database that is regularly updated and easily accessed by system management. We recommend that the lowest character count be used as mail identifiers. ---end Barb's comments for #6--- 7. Long-term direction: Our stated long-term direction is to replace the Qi server with an X.500 server. Qi evolves nicely into X.500 (Ph client can query X.500 server; Qi server database can be ported to X.500). Barb's comment for #7: Please add to the recommendation: X.500 is a stated goal and will be re-evaluated in 3 years as the technology evolves. Answer: We intend to be reevaluating this continuously. IMAP/POP Recommendations 1. Recommendation: Pine (IMAP) as a replacement for Microsoft Mail and Pegasus Mail,with Eudora (Qualcomm?) as a POP alternative where desirable or required. Pine is the client of choice where available and where the client wishes to sign on and read mail from any station. Eudora is recommended when a Pine client is not available or when a client has a primary need to use a laptop to which s/he wishes to download mail. Pine has clients available for VMS, UNIX and DOS. The Windows client is due 3Q94; the Macintosh client is due 4Q94 or 1Q95. Justification: Barb's comments for #1: Concern: This recommends IMAP as a replacement for Microsoft Mail and Pegasus Mail. What about Open-VMS and VM mail? Answer: We have a Pine client up and running on Open VMS; we are checking whether there is a Pine implementation on VM. Currently there are significant numbers of mail users on VM and VMS. Please be aware- CPPO has requested VM accounts for at least sophmores and juniors and maybe first year students by January, 1995 and will continue their request for all seniors for August, 1994. ---end comment--- Timeframe: IMAP - test group of 100 faculty/staff/students July-Dec. 1994. Hope to have Qi server available at start of test. Test participants require: a. Reliable (added by Barb) Network connection to desktop, or at a lab for students (LTCs or divisional labs) b. IMAP/POP-accessible account on one host (Technical Services to decide whether ROSE or OCEAN, in consultation with Client Services (John Harlan) and Instructional Computing (Barb Edwards)). c. Start with core test group and ask them who they email (workgroup commonality); then include them. Barb's comment: Start with a small test group that is computer as well as e-mail literate. Expand this test to workgroups of the initial group. d. We want a variety of clients (MS Mail, PMail, new users (Bill Slover?); high-volume users). e. IMAP/POP software (1/2 using public domain client; 1/2 using commerical client). Debi and Kent to solicit vendors for evaluation/test copies. f. Way to re-route mail to new address for MS Mail, etc. since test participants won't want to tell the email world that they have a new address. We need: a. Solicit eval client software from vendors b. Ask for volunteers. Do they want IMAP or POP client? c. Documentation for test participants on all platforms Barb's comments: Criteria for IMAP or POP selection Software installation procedures Directions on how to use software Directions on how to update records in central databases d. Help Desk involvement in the test (preferably including interaction by e-mail via Target->Hotline, so that we can test the software with Hotline) e. Involvement from Instructional Computing, Networking, Technical Services, Client Services (including Help Desk). Barb's comments: Please add these recommendations: f. Procedures for installing mail boxes for users. g. Licensing and distribution issues to be part of the evaluation process h. Training and documentation for support staff in areas where tests will be conducted. ---end comment--- C. Critical Success Factors - How will we know we've succeeded, and what factors are most likely to determine whether we're successful? 1. Client Services says installation/maintenance concerns are easier with this set of solutions. Barb's comments: Please add these Factors. a. Ease of use to include How quickly the software installed Clients ability to update records Ability to determine another persons address Ability to inform someone else of users address ---end of comment 2. Mail gets delivered reliably (probably the #1 CSF) 3. Survey of client satisfaction. a. Ease of use? b. perception of reliability c. perception of usefulness d. comparison with old sysem e. would client continue to use/recommend this solution? 4. During test, check with clients. Are they still using the new solution, or did they revert to their previous product? 5. System benchmarks - performance monitoring, server sizing. 6. Total cost/scalable cost comparison (added functionality, freed resources?) Barb's comments: 6. Please add this to the evaluation: (... ,installation of volumes of mail boxes, distribution of software and collection of fees) Calendaring/Scheduling Our project began due to a request from Sarah Baker for calendaring/scheduling recommendations. We began investigating available software, but it quickly became apparent that Miami does not have the infrastructure to support university-wide calendaring/scheduling. We then backed up and began to address the infrastructure issues, and the above recommendations are the result. Calendaring/scheduling software has not yet evolved to where there is a product to meet our needs. We identified the following needs: 1. Scalability to 21,000 clients, on multiple platforms and multiple networks. 2. Ability to chose that an individual's unavailable time can be shown without displaying to others the purpose. 3. Selective ability to give a secretary access to the manager's detailed schedule. 4. Meeting not scheduled until invited people confirm their attendance. Confirmation of the meeting to be sent following all confirmations. 5. Ability to schedule conference rooms, and equipmenet, with ability to restrict authority for scheduling these resources to the responsible people. 6. Ability to print daily, weekly, monthly schedules for use by the individual and the secretary. Preference given to software that provides a variety of format choices. 7. Ability to designate who may access an individual's calendar. (or restrict who may access it?) 8. Ability to schedule recurring meetings -- weekly, monthly, first/last work day of the month, first and third Tuesdays, etc. for one year beyond the current date. 9. Requirement that messaging services be an integral part of desktop applications. Must span applications, platform, network environment.