200 likes | 345 Views
Electronic Mail. Upgrade, Conversion, Migration. Goals. Improve Performance Minimize disruption of user environment Architecture that is open to additional features and services Minimize Cost. What Is Changing?. The Mail Servers Themselves Other Architectural Components
E N D
Electronic Mail Upgrade, Conversion, Migration
Goals • Improve Performance • Minimize disruption of user environment • Architecture that is open to additional features and services • Minimize Cost
What Is Changing? • The Mail Servers Themselves • Other Architectural Components • User interfaces (clients) – some optionally • Password/Authentication Policies/Procedures • @ALL behavior/management (optionally) • Use of VMS
Servers • Current: • OpenVMS Compaq Alpha • VMS Mail • PMDF (IMAP/POP/SMTP) • New: • Linux on Dell PowerEdge (Xeons) • Courier IMAP • Courier or Eudora POP • Postfix SMTP
Architectural Changes • Redundant Mail Gateways (fault-tolerance, SPAM/Virus intercept, user interface/server flexibility, open for other services) • Redundant LDAPs (fault tolerance) • Routing of SMTP Traffic • E-mail account merges with LDAP/network account
User Interfaces • VMS Mail will no longer be an option • Text-based client access to be determined • Netscape Messenger 4.7 – recommend retiring due to security flaw and instability • Webmail – speed and service enhancement, possible alternative client
Passwords/Authentication • E-Mail/LDAP (network password) merge • Expiration Rules – To Be Determined (TBD) • Evasive Action Behavior – TBD • Reset Rules (Local) – TBD • Remote Reset (faculty/students abroad, distance learners, etc.) – TBD • Encrypted Storage – By default • Encrypted Transmission – Optional by service
@ALL List Behavior/Management • An opportunity, not a requirement • Needs more discussion • Some feedback on dissatisfaction with volume and content of @ALLs • Opt-in vs. Opt-out methodology
Migration Options • Cutover - Users would all be moved to the new system en masse. New mail would immediately begin arriving on the new system, while mail from the previous system would be moved (by technical staff) at the same time or shortly after. • Guided Conversion - The Helpdesk arranges for groups of individuals, departments, or whole buildings to move on a given date or within a given time frame.
Migration Options (cont’d) • Do-It-Yourself (DIY) - Users are given the tools to migrate their mail as they wish. • Cut Over/DIY – Cut over to new system but leave mail on old system and give users a web page to move as they wish.
Migration Questions? • When is the best time to do it? During the semester? During an intersession? • What is a good balance of DIY and technical service? • Should users be asked to clean up old mail before migration? • What other opportunities present themselves?
Migration Issues • Timing in general… • VMS Mail interface use • Disk space • System Performance (load) • IMAP Folder names – some may change to all upper case
Migration Issues (cont’d) • Handling subfolders • “Replied To” flag not preserved • Dangling Mail files on OpenVMS • Existing distribution (.DIS) files on OpenVMS • Timing of password change/merge and notification to users
Migration Survey • Notice will be sent to all faculty staff users • Used to answer basic user preference questions • http://www.plattsburgh.edu/emailsurvey/ • Log in with LDAP/network password
More Migration Info • http://www.plattsburgh.edu/technology/email/ • http://lists.plattsburgh.edu/mailman/listinfo/e-migrate
Future Opportunities… • Better SPAM control • Workgroup features – calendaring, etc. to serve an educational or “business” function • Integration with other services