Goodbye GSuite Legacy — My migration journey
After 15 years , all things eventually comes to an end. With the shutdown of GSuite Legacy in under 6 months from announcement, a quick and cheap migration is necessary. Here’s how I did mine.
This is another reminder as to why using your own domain name for your emails. Open protocols and standards, will likely outlive services and companies. Change is inevitable. Software as a Service (SaaS) without an easy open standards export, is a continuity risk.
⚠︎ Note:
The majority of this piece was written in early May 2022, prior to Google announcing a pathway for personal use to remain on GSuite Legacy on about 2022–05–17. This was my thought process and may still help small businesses/organisations on a budget, updates are at the end of this post.
Background
Emails, from a simple electronic replacements for paper mail and a nice to have, to now having evolved to become a proxy for our identities.
In the earlier days of websites, which were nice to haves; we used providers like Geocities/LiveSpaces, a service for our small corner on the internet; but that came with limitations, and as we now know didn’t last long. It became clear that owning your own “address” (domain names) is important for trust and longevity.
Then we moved to single service provider, single provider and server LAMP-stacks to host websites on our own domain names. Then as websites grew and became more demanding, the idea of scaling horizontally through the use of reverse proxies to route traffic gained traction. With the benefits of scaling horizontally, it allowed developers to decouple service backends — allowing for quick switching between services and providers; while keeping a consistent frontend. This exploded with NGINX and then CloudFlare going mainstream, in the 2010s.
I feel, for emails we’re going through that critical-mass change today. It is an opportune moment to make the shift during this (forced) transition. As a bonus, this allows me the flexibility to use different services for different aspects of my life — work, personal, etc.
In software architecture terms; let’s transition emails to the facade pattern, and service orientated architecture, rather than the current monolithic pattern.
The Architecture and Stack
Individuals/Families affected by this would have likely required an ongoing consumer “Google/Gmail” account for all their other Google Services (Google Play, etc) due to restrictions early on. Usage of the GSuite accounts were mostly limited to Groups Mailing Lists, Email, Google Meets and Google Drive.
Thus, the focus here is on the Email and Group Mailing Lists replacements problem, while keeping costs as low as possible. It’s for personal family use, and I’m cost sensitive ( I don’t need yet another subscription, especially with the increasing cost of living ).
Additionally, Google has on Feb 4, 2022 announced Google Workspace Essentials, which provides access to other Google Workspace services like Google Drive and Google Meets for “Free” but without any emails. Thus, not needing to actually migrate anything else. How this actually works might be for a later exploration. My current plan is to just transfer everything (Google Drive and Meets) to personal Gmail accounts.
Jumping straight to the pattern implementation, we will implement a facade/proxy as a drop-in replacement of the GSuite Gmail service, and redirect all email to existing email accounts.
The minimum prerequisites, you will need:
- Access to change your domains’ DNS
- A SimpleLogin.io account
- An email account you’d want to receive mail to.
The implementation is as follow:
The solution above forwards your existing GSuite Legacy emails to your other existing mailbox; free, paid, or other.
If you’ve got a GSuite Legacy mailbox, I will assume you’ve got more than one email address; especially since there were (and still are) a lot of Google Services limitations early on in the life of GSuite. You will also NEED the ability to modify your DNS records for the affected GSuite domain you’re migrating.
💡 Note
If you’re migrating only a single user off GSuite Legacy, and want it easy, you’re better off just paying for a Google Workspace subscription. Google Workspace/GSuite is still one of the best out-of-box email and productivity solutions out there that “just works”.If you are being frugal, and are moving more than 1 user, and want a “cheaper” ( USD$30/yr) approach; read on.
Essentially, the key functional difference from the existing state is instead of the GSuite handling receiving the email, you’re replacing it with an email proxy. The other items are simply opportunistic resilience and monitoring improvements while we are doing this.
Implement the Target Architecture:
Step 1: Sign-up to SimpleLogin.io — the Email Forwarder
Implement as described in this tutorial published by SimpleLogin:
You’d have to decide if you’d prefer the “First Way” or the “Second Way”. If you’re fully managing all the aliases, and the users are less tech savvy, you might want to select the “First Way” so that the switch over is transparent, and requires no further action from others besides click a confirmation email.
These guides on how to add a domain and setup Simple Login may be helpful:
- https://simplelogin.io/docs/custom-domain/add-domain/
- https://simplelogin.io/docs/custom-domain/registrars/namecheap/namecheap/
- https://simplelogin.io/docs/getting-started/send-email/
- https://simplelogin.io/docs/getting-started/troubleshooting/#emails-end-up-in-spam
⚠︎ Note:
This service is hosted on the ProtonMail infrastructure; ensure that the “Break Glass” email is NOT on ProtonMail infrastructure to avoid a single-point of failure. Use this “Break Glass” email for your DNS service provider as the alternate recovery email if it supports that, and SimpleLogin login.
Step 2 : Invite Mailboxes
This will be where the email will ultimately arrive at. This can be existing personal mailboxes. Example, a free Gmail, or other email service providers ( ProtonMail, Fastmail, Outlook etc. ).
In SimpleLogin, add a “New Mailbox” and invite all the people/email addresses you want to receive your mail at. That means, if I want to receive email from the address “personA@example.com” at “personA@gmail.com”, create a “New Mailbox” in SimpleLogin. This will send an invite to “personA@gmail.com” to verify and accept. Once done, you can setup an Alias to redirect the email from “personA@example.com” to “personA@gmail.com”.
Further details and instructions:
https://simplelogin.io/docs/mailbox/add-mailbox/
That’s it. You’re done.
Some tips.
- Setup the MX records and SPF for SimpleLogin first without deleting the existing GSuite and lower the update TTL to about 10 minutes.
- Setup SimpleLogin first, and get the mailbox and aliases set up. Once all that is done,
- Update the MX records priority for GSuite to be higher number (higher number is lower priority) than SimpleLogin. Eg, if SimpleLogin’s MX is priority 10, set GSuite to 50.
- Then send a test email to the aliases. Once you’ve confirmed that all the aliases work, and emails are routing as expected, delete the GSuite MX records.
⚠︎ Note:
Ensure that you test sending from at least 1 Gmail account, as there’s a possibility that the email may be internally routed within Google’s network and may not have been updated yet. You want to make sure emails flow well before deleting the “old” MX records.
Godspeed.
Hopefully, with this would last a longer time than GSuite Legacy did. ✌️
Going Deeper
Why SimpleLogin? Why an email proxy? The thought process and rationale.
It’s been a long time coming. Why didn’t we have a “email reverse proxy” like we do with HTTP connections, allowing us to easily switch the “backend” service without any pain?
The decoupling “address” from the “service” is a good way to start. Like the with web services, the “endpoint” is decoupled from the “business logic/service” in a 3-tier architecture enables the switching out of services quickly, allowing adaptation to changing requirements.
In web services, a web reverse proxy is what we use for routing requests, in the land of emails, an email forwarder sounds like what I’m looking for. Ideally a decent email forwarder/proxy would allow for delivery of an alias (”endpoint”) to multiple “backends/mailboxes”. That would be a win.
First, a quick round the immediate options, and a quick look after a brief search.
- POBox — Costly and restrictions around the total number of aliases plus domains.
- Fastmail — Costly and restrictions around the total number of aliases.
- CloudFlare — Can’t forward a single alias to more than one destination address. So I can’t use it as a Group Mailing List. Otherwise, this works as described on the tin, and relatively easy to setup; and I’m very hopeful for its future. Plus I’d get mail server DDoS protection from a major CDN. I was really hoping this was the one, since I already use them as a web reverse proxy.
- MXRoute — A promising service, but appears to be a one person shop, and was opinionated about blocking Digital Ocean IP addresses; a major cloud provider, which would likely cause issues which I can’t afford. Due to my current threat model, and needs, although a current (as of writing) customer, I have decided not to migrate to this service.
- Forward Email — https://forwardemail.net/ — Almost selected this as the solution. Reasonably priced SaaS, open sourced, privacy focused.
- A few other roll your own projects ( via cPanel, VestaCP and variants ) — Nope. Bus factor risk, and I don’t want to manage yet another server for something mission critical. A company focused on doing it would more likely do a better job than I can long term. Also managing IP reputation, and deliverability is a significant pain!
- Then there’s SimpleLogin, the service that ProtonMail, and it had mobile apps for both iOS and Android. Looks like Forward email, but with more polish, and activity.
SimpleLogin ( simplelogin.io ) a service recently acquired by ProtonMail looks promising. They even have a guide discussing how to do the very thing I’m trying to do.
SimpleLogin
This looks promising.
Let’s create a Proof-of-Concept, to validate functional requirements.
- [y] Price — USD$30 per year — Yes, it’s affordable.
- [y] Supports unlimited aliases, reply/send from alias, custom domains ( I can add all my other domains), send new mail from alias, and unlimited mailboxes (where I receive mail).
- [y] Check MXToolbox and other Spam Reputation services — Looks clean at time of writing.
- [y] We’ll need to specifically test being able to forward a single alias to multiple addresses/mailboxes.
A few other good to knows about Simple Login:
- A French registered company — Means GDPR and other EU regulations come into play.
- The App and platform is Open Source — means that if the services is discontinued, I can continue to run my own. I can also verify or contribute functionality to the service.
- Clear, sensible, and privacy friendly TOS, Privacy Policy, and Security Policy
- It’s product roadmap is public on Github
- They use privacy focused, open sourced web analytics Plausible.
- On-boarding Guides is nice and friendly
This fully covers the main use-cases required. There’s even a mobile app to help manage aliases. Importantly from a security perspective, it supports WebAUTHN and TOTP.
From initial quick testing, it works as needed.
Now that we know the key functionality works,
a quick threat model to validate risks and concerns.
So, let’s do some personal napkin threat modelling:
- What are we working on?
Primary email router — practically this will hold by proxy my online identities and my comms. - What can go wrong? ( In order of Concern highest concern first )
Lost/missing emails
Account takeover
Data breach/account compromise
Service interruption & reliability
Loss of service - What can we do about it?
Lost/missing emails: Accept & Monitor — Use DMARC to track incoming emails.
.
Account takeover: Reduce — Use MFA + WebAuthN to secure account login. AppSec risks; retain off-platform break-glass recovery pathway. Another risk management, perform a code review, and pentest against the service for a sanity check.
.
Data breach/account compromise: Accept & monitor — Risk of Impersonation is significant as it’s a proxy for my identity. Personally, due to the nature of the work I do, I may have an elevated risk that I’m targeted. As it is now part of Proton AG, hopefully this means they will get access to the security and quality track-record Proton is known for; especially against persistent threat actors. Is it better than Google’s collective resources, NO; but Google Workspace is too expensive.
.
RISK management note: Ensure that the break-glass, and failure recovery pathway is NOT a ProtonMail service; as there is a residual risk that ProtonAG is compromised.
.
Service interruption & reliability: Accept — Appears to have a sensible business model, built on proven infrastructure (ProtonMail). It appears that it’s mostly a one-person team, but this is now lesser of a concern as it is also now part of ProtonMail; thus likely to be more sustainable. Is it better than Google’s collective resources, no; but Google Workspace is too expensive.
.
Loss of service: Monitor & Accept — Monitor ProtonAG and SimpleLogin news on how the organisation and service is progressing. If concerns rise, the full service is available on GitHub as an Open Source project. As long as this continues to exist, a potential migration/succession pathway is to self-host the service. Is it better than Google’s collective resources, NO; but Google Workspace is too expensive.
.
Risk management notes: Regularly mirror, creating a local copy of SimpleLogin’s Github repositories to ensure continued access if it no longer is available.
.
SimpleLogin has Import and Export tools to help accomplish this. - Did we do a good job?
Well, it’s too early to tell. But, given the current circumstances, it’s “good enough”. We have a clear escape plan, and the key risks and concerns can be managed with a fair bit of concerns minimised by the acquisition of ProtonAG — an existing trusted provider.
Threat Model conclusion:
I feel that the Risk is managed and acceptable with the following actions:
- Implement DMARC reporting on all domains.
- Implement MFA/WebAuthN to secure the account login.
- Create a break-glass recovery plan and process for all key services and accounts that’s off-platform from ProtonAG. (Eg. Domain Registrar/DNS provider)
- Regular Backup SimpleLogin repositories & export configuration state
- Monitor news and risks to ProtonAG and SimpleLogin ( add it to the risk register ).
Good to go!
Do your own Threat Model and determine if this is right for you.
That’s it. Godspeed.✌️
📢 Update : 2022–05–17 — Free GSuite for Personal use
Google has offered a free pathway forward for personal GSuite accounts, just as I was going to finish up executing the switchover. For while it lasts, I’ll keep with Google G Suite Legacy, as not having to transition is still less effort. Good enough for now.
More details at Google’s Support article
https://support.google.com/a/answer/60217?hl=en-GB&visit_id=637884376722382993-1409358395&p=nocost_faq&rd=1#nocostfaq
