Changes between Version 3 and Version 4 of standard-server-split
- Timestamp:
- Jun 22, 2011, 10:51:44 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
standard-server-split
v3 v4 23 23 * 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 24 24 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.25 Rather 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: 26 26 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. 28 28 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. 30 30 31 31 * 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. … … 35 35 The 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. 36 36 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 38 38 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. 40 40 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 42 42 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