Task:	Mail-related services
Group:	morna,jmho, neilb, cms
Stage:	1

Report changes

2002-03-12

Implications of IMAP-only service: many users will have to change their user-agents. We need to provide a good alternative for them - "pine" won't do!

2002-03-01

Updates about EUCS response on various central services (getting unique user names, deletion of central accounts, SMTP-AUTH). Further implications for whether we use staffmail or not.

2002-02-14

Forwarding email from secondary home directories when sorting out common home directories. Added actions.

2002-03-13

Should check on plans for kerberised SMS service.

2002-04-11

Rough spec for mailhub and mail service agreed on. staffmail@ed will not be used.

2002-04-25

Additional hardware and software specs for mail service.

Description

Anything related to electronic mail within the Division: mail domains, delivery point (mailboxes), mail agents, mailing lists, encryption, remote access, etc.

Notes/Definitions

User mail addresses/mailboxes

It is important to first make the distinction between a mail address and a mailbox:

mail address

any valid address that can be mailed to (eg user@inf), irrespective of whether the mail is rejected, redirected elsewhere, handled by a user's dot-forward or safely delivered on the local @inf system.

mailbox

where a user's received mail is physically stored.

Key points

• ultimately, every continuing legacy user will need a mailbox on a non-legacy system.
  • legacy systems and the associated local mailboxes will eventually be decommissioned.
  • redirections for mail sent to legacy accounts will exist for a significant period after the actual legacy mailboxes disappear (potentially forever).
• we do not want to set up references back to mailboxes on legacy systems. This is an important principle to establish as backwards redirects are destined to cause problems when legacy mailboxes go away.

Issues

There are potentially lots of issues to be addressed under the title 'mail'. The following list outlines the main topics and the associated basic questions. These include questions that we think we have the answers to already in order that it is clear that an issue has been addressed and not forgotten.

However, it should be noted that many of these issues are not critical to deal with for the initial rollout and only the stage 1 ones will be dealt with properly here. The remaining ones will be dealt with in subsequent stages and consequently other documents.

• multiple mailable addresses
  • every user account created in the @inf domain creates a new mailable address.
  • legacy mail addresses will continue to work regardless of the new accounts created.
  • every user of a legacy system will get an account on an @inf system so in effect get an additional mailable address from the start of Stage 1.

    2002-04-11

  • @inf mail will be delivered to a local mailbox on the mailhub, accessible by IMAP
• mail to user@inf will be handled in some way (ie, it won't be bounced).

• preferred mail address
• the Divisional database contains an entry for each user for their preferred mail address.
  • need to coordinate if/how this gets updated as users change to different/new mailboxes when we start using @inf mailboxes.
  • important that auto-generated lists of mail addresses contain the right address (so that people submitting mail to closed lists will not get bounced).

• mail domains (handling incoming/outgoing and identity)
• handling of incoming mail to olduser@legacy and forwarding to user@inf
  • NB <olduser> will generally, but not always, be the same as <user> in user@inf
  • inactive users with dot-forwards in place--how will they be handled?
• will some existing domains still require outgoing email (eg AIAI, ANC)?
  • these are political decisions but may need to catered for technically
    • can we have a DICE-configured machine with a different mail domain identity?
    • because <user>@legacy will almost certainly not always map to <user>@inf, will we need a different set of users for legacy? Or will user have to change to their standard @inf name?
• outgoing mail identity
  • outgoing mail from a standard Informatics machine will be stamped @informatics.

2002-04-11

Mail will be 'physically' delivered to an mbx-format mailbox on the mailhub mail spool.

• Individual users may opt to use central EUCS service anyway
• student email
  • it should just continue as before, with everything being forwarded to <student>@sms
  • the forwarding rule (s[0-9]*@inf -> [0-9]*@sms ) operates at the system level (sendmail configuration).
  • will need to be able to setup and use pseudo-users and or aliases (eg for conferences, systems stuff, etc)
• access to @inf delivered mail

  2002-04-11

  • Use IMAP, for internal and remote access
  • As IMAP only - must provide something "better" than pine for staff.
• not very high support load for user mail, given that no student email will be carried
• we have to handle incoming email to user@inf. Might be fine to deliver staff acount mail to @inf machines. It wouldn't require any special configuration.

  2002-04-11

  Central delivery of user mail to EUCS.

• This route will not be taken in the short to medium term, due largely to uncertainty in matters of University/EUCS policy and not to considerations about the quality of the services provided by EUCS. >/ul>

• it might be a good idea to 'switch off' all legacy mailboxes at the same time.
• users who stay on legacy systems can still collect their mail from @informatics, assuming that mail is delivered to somewhere accessible via IMAP (common spool area or standard home directory location).

• single signon

• directory services (external/internal) for email
• internal email lists will probably be web pages autogenerated from the database
• will we provide a top-level directory of the sort Real.Name@informatics?
  • this would be for staff only
  • the big problem is having flat namespaces.
    • do we allow Fred.Smith@inf (implicit 1st instance of that name). Or do we have Fred.Smith-1@inf and never allow the canonical name?
    • we can always just ignore this issue and hope it works out on a first-come, first-served basis. Not very elegant but probably workable for 99% of cases.
  • what technology would we use for a directory service?
• many existing staff users already have @ed aliases and will continue to use them regardless of any new directory offered.
• will we need to offer special features or directory services for old domains? (eg you can currently send to A.User@anc)

• conflating existing logins/aliases
  • there is a University-wide unique name system but it was a snapshot and we may have local users that aren't in it yet.
  • each site also will have a variety of pseudo (eg, a conference, local interest groups, etc) and system aliases. These might need to migrate to @inf rather than just wither away. There may be clashes to be resolved.
  • these issues are covered extensively in the User Transition document.

2002-04-11

• mail user agents
  • Only IMAP-capable mail agents will be used.
  • contentious!
  • Provide IMP: some users will want the sort of browser interface access to mail (from anywhere) that staffmail.ed already allows. Some users are bound to use that.

  2002-04-25

  • Allow folders to contain either sub-folders or mail messages but not both.

• mailing lists
  • currently already handling lists in the @inf/@informatics domain using mailman which seems to be working fine
  • current setup is self-contained and can probably continue as is for stage 1. However, it is on the machines that has the informatics MX record so may have to move.
  • will need to consolidate lists in legacy domains as they disappear
  • need to check what clashes there are and deal with them.

• encryption/decryption
  • users would like easier ways to encrypt/decryt mail and manage keys, particularly for local users.
  • if staff start to use encrypted mail more, will this be a problem for students who are already using an external mailbox/service (eg, hotmail) that may not support it?

2002-04-11

• mail filtering
  • staffmail.ed already have a GUI filtering system via the web interface. Ask Scott/EUCS for this code.

• authenticated SMTP
  • users have requested an authenticated SMTP service. EUCS plan to have one in the longer term. 2002-03-01 they have confirmed that they will be providing one but have given no dates yet.

Summary

• mail delivery
• transitioning from legacy mailboxes
• common home directories and forwarding for non-primary accounts

mail delivery

2002-04-11

• Finalised requirements/implications of setting up a mailhub for @informatics. See mailhub doc for details.
• Decided against moving to staffmail.ed in the short term because:
  • Easier to transition to mailboxes on @informatics as we have control over their setup.
  • Some problems of policy have yet to be clarified/agreed with the EUCS and the university.
• users who wish to transfer can but there may be implications (eg, kerberisation) 2002-03-01. EUCS have confirmed that they will be looking into providing a Kerberos service for staffmail (and a central Kerberos KDC) but there are issues to be resolved around cross-realm use (who would trust who, etc). Basically it is not straightforward.
• we should encourage users of staffmail to either use an @ed alias or use their @informatics address as reply-to in case they need/want to move to @informatics at some point.
• student mail will be forwarded to sms.ed at system level as currently happens

transitioning from legacy mailboxes

Proposal:

2002-04-11

• stop delivering mail to all olduser@legacy mailboxes at an agreed time between July and September.
• Some DICE users may be able to move to using user@inf addresses in early June.
• forward all incoming mail to olduser@legacy domains to the relevant user@informatics once users have access to their non-legacy mailbox. We will probably do this even if we choose to deliver @informatics elsewhere as the mapping is known.
• make sure legacy users can access their new mailbox from their legacy system---need to check on mail agents, etc
• students who had non- s<matric> accounts will need to make sure they get access to their SMS account when the changeover happens
• check what clashes there are between delivery formats (mail and MMDF)

Common home directories/forwarding

• we will forward from secondary accounts to account at primary home directory site.
• we will not use the ~/.forward option, even though a forward of eg user@cogsci will not in fact confuse cogsci's sendmail.
• we will put the forward in the /etc/aliases file (using :include:) in order to avoid the user accidentally losing their forward if they did something to it by mistake (eg, when setting a vaacation message by hand).
• we will need to check for users who have existing forward files as they may already be redirecting off-site rather than to their primary home directory domain.
• if there are users who don't have a forward at their non-primary account (eg, they pick up their mail at two different sites) they will have to cope with it being redirected to their primary. There is no practical alternative. (Could we put it through procmail and tag it somehow?)

Dependencies

2002-04-11

• Getting EUCS IMP/procmail to work on linux.

Actions

Timescales

mail delivery

2002-04-11

transition from legacy mailboxes

• preparatory work can be completed well in advance of the actual transition. This includes:
  • creating the mappings from olduser@legacy to user@inf to be used in legacy /etc/aliases files.
  • checking mail clients so that they will be able to access an IMAP mailbox. Identify standard user agent to recommend to users.
  • suggesting policy on reply-to fields
  • making sure that there are adequate conversion or access methods for user mailboxes of different formats (eg existing MMDF users).
• the transition cannot be started until there are all the user accounts available on @inf machines. putting in place the redirects from legacy to inf is straightforward. The problem area will be making sure that all users have adequate access to their account on @inf and their mail clients are setup correctly.

 : Deploy 

Please contact us with any comments or corrections. Unless explicitly stated otherwise, all material is copyright The University of Edinburgh