Changes between Version 3 and Version 4 of standard-server-split


Ignore:
Timestamp:
Jun 22, 2011, 6:51:44 PM (8 years ago)
Author:
Jamie McClelland
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • standard-server-split

    v3 v4  
    2323 * POP/IMAP: all members who access their email via POP or IMAP must specify either in the desktop client or when they visit https://members.mayfirst.org/ to check their email via the web the name of their primary server
    2424
    25 Rather than forcing our users to specify their primary servers for these settings, each one should have a organization-wide address used by everyone.
     25Rather than forcing our users to specify their primary servers for these settings, we should have one address for both that works for all member: mail.mayfirst.org. This server would provide two services:
    2626
    27  * relay.mayfirst.org: Currently, we have authenticated mail relay on each of our standard servers. If we setup one or several servers that had a login for every MFPL user, we could easily transition to the use of a single domain name for all mail relaying.
     27 * Relay: Currently, we have authenticated mail relay on each of our standard servers. If we setup one or several servers that had a login for every MFPL user, we could easily transition to the use of a single domain name for all mail relaying.
    2828
    29  * incoming.mayfirst.org: Using [http://www.debianadmin.com/howto-install-nginx-webserver-in-debian.html nginx] or [http://www.debianhelp.co.uk/perdition.htm perdition], we could setup one or several IMAP/POP proxies that similarly redirect requests to the appropriate server based on a database / table lookup.
     29 * Proxy POP/IMAP: Using [http://www.debianhelp.co.uk/perdition.htm perdition], we could setup one or several IMAP/POP proxies that similarly redirect requests to the appropriate server based on a database / table lookup.
    3030
    3131 * mx records should stay configured to the individual server. This way, our DNS records can provide a canonical way to identify the ''real'' mail server for any given domain.
     
    3535The transition would need to be implemented so that there is a long overlap period whereby the current approach to mail settings work as do the new approach.
    3636
    37 Implementing relay.mayfirst.org is the easiest of the three, since we can use the same software and configuration we are currently using - with the exception of implementing it on a dedicated server. Once in place and tested, we can begin using it immediately. It will, however, require users to change their own desktop email settings.
     37 * Have more tech support team members test it out
    3838
    39 incoming.mayfirst.org requires us to explore new software, making it the most complex step. Furthermore, it will also require users to change their local settings.
     39 * Get a handful of heavy users on chavez to switch to mail.mayfirst.org as a way of testing it and facilitating their move to a different server to relieve the load on chavez.
    4040
    41 Probably best to make all changes first, and then request that users update their settings. Through our mail logs we can accurately assess exactly who has made the changes and who hasn't.
     41 * Publicly announce it to all members, ask for volunteers to try it
    4242
    43 Only after everyone has made the changes can we really put this new setup to use by moving users around and splitting off our standard servers into web and mail servers.
     43 * Officially announce it to all members, with an end of life date for the old way of configuring email (6 months? 8 months?).
     44