This mess will continue until parents come to their senses and start giving their children UUIDs as names. When your legal name is “EC691F44-C4D8-48D0-86EF-4A0E7BB8214D”, there’s no reason to ever change it, or your email address. For work email you could even go by a nickname like “EC691F44@example.com” since it’s almost surely unique.
At $WORK, we do something similar at scale. 180k+ users over 500+ applications through an IdP - realistically impossbile to handle name changes manually at our scale. For any given user, they will have a username and email that they are aware of (i.e. jdoe0001 / John.Doe@org.xyz)
However, at the identity level, they actually have different immutable identifiers that are guaranteed to never change:
orgObjectID: ea553c28-9db3-4e0c-952d-bcceacb1655b
Unique to a specific account
orgPersonID: a9362415-7ec7-43a2-ad39-5e095997f553
Unique to all accounts owned by this user
orgAccountID: sgyxomlhai
orgPrivacyMail: sgyxomlhai@p.org.xyz
No application will ever see the ‘human’ attributes like username, but will instead get a combination of attributes. Names can change, usernames and emails can change, but applications will only ever see immutable identifiers in claims from an IdP.
Applications love to use usernames and emails as primary keys, so we enforce application owners to pick one (or more) of the immutable identifiers to consume. No app ever sees anything deemed ‘mutable’ in an OIDC/SAML claim.
Users don’t even know that applications don’t have their ‘human-readable’ email, as the privacyMail is just an alias. But we don’t ever have to deal with the mess that comes with syncing mutable identifiers :)
I mean, you kid, but Sweden (and Estonia IIRC) have the concept of a unique identity which is tied to such a system.
In Sweden it’s called a “Personnummer”, it consists of your date of birth and a 4 digit suffix, one used for gender, one for checksum; with an additional number (bringing the total to 5) for an interim number that’s not permanent.
Since they’re guaranteed to be unique they can be used for basically everything and they can be used as primary keys as databases.
You can request a specific personnummer pay some money and it will work, you can request a personnummer sign something which will be forwarded to a BankID phone app for your authorisation.
You can request a new personnummer with the appropriate gender numeral (IIRC, divisible by 2 means the person considers themselves female), but that leaves enbies in the lurch of course.
You can also request an entirely new personnummer if you need a hidden identity.
The system is from the 1940s and has had to evolve with the times.
Same problems as the similar Finnish one: date of birth can change (apparently recent citizens can turn out to have new and more accurate information about their date of birth) and gender can change. Neither should be part of the immutable identifier.
This was an issue in Sweden too. Other cultures don’t place as much importance on the date of birth as we do, so many people arriving from (IIRC) Syria stated their birthday as the same date in a year, which led to the dates there getting “exhausted”.
The ultimate arbiter of the connection between the numerical identifier and the legal person it’s attached to is Folkbokföringen (population registry), previously part of the local church parish, now part of the tax authority. The “simple” way you get this assigned is through birth. Mom is confirmed to be mom, (dad later), gender is confirmed, birth is reported to the tax authority, and a few days later the personnummer is assigned, and stuff like benefits are routed to the correct recipients. So in a way the number precedes the name, as you’re not required to register a name until 6 months after birth.
I was moreso thinking of being issued a new personnummer, since the closest analog I could compare it to is my SSN, which wasn’t updated to a new number when my name and gender marker were changed. But from the other response, it sounds like they account for changes better in the personnummer system, which makes it less of a roadblock
This is reductive. If there is a gender component in a number that you cannot change, the gender will be (incorrectly) inferred from the number & automated systems may out you, which increases your surface area for potential discrimination.
I can understand why you think it’s like that , but it’s not. The personnummer is simply a numerical representation of your identity. It happens to have a gender component, which is now problematic, just like if you happened to be born outside the country the first digit after the birth date used to be 9, which led to some discrimination.
But fundamentally it’s just a short, numerical, immutable (within limits) representation of who you are.
Using such number as a primary key in your database sounds like a GDPR nightmare. It will end up in logs, URLs and error messages.
There’s also a question of future proofing. What if you start selling to companies in addition to individuals and need to extend your customer registry schema? What Personnummers do you assign to non-persons? Or will you migrate to a new schema, invalidating all existing IDs in the process?
Please just use random integers or GUIDs for this purpose.
Personnummer are now considered to be PII so they should not be used as a primary key (even if that’s been done before).
Note that Sweden’s transparency laws are quite expansive so if you know someone’s personnummer, you basically know their name, and vice versa. GDPR actually restricted these laws.
Companies and other legal persons have a similar number called “organisationsnummer”, used for VAT payments etc.
Estonia’s is pretty much the same (isikukood) — 11 digits which include gender, date of birth, serial number and checksum. Mine was issued post-transition so it has my “current” gender; I’m not sure how (or if) they handle that change.
Interesting choice to encode century (and gender) into the first digit. To me this looks like a better solution than the Swedish (well apart from hardcoding gender) where people born in 1903 and 2003 would share the first “03” digits at the start for standard 10-digit format (nowadays some applications use 12 digits including the century). Estonian numbers won’t have to rollover until around 2150 or so.
Yeah, we have those in Czechia and try to get rid of them in favor of rotating IDs and org-specific IDs to prevent uncontrolled aggregation of personal data.
Anyway, we have 2 duplicates in the old IDs (from what I’ve heard from the guys at the Ministry of Interior). The hospitals ran out of their daily allocation and used next number, hoping for best after delivering the babies. Well, duplicates happened.
Interesting. There was a big debate in the 70s and 80s about how the state was aggregating this data, with laws passed to prevent (say) social services from looking at police databases for criminals. Now the tide has turned, and more and more people are demanding that this can be done to combat benefits fraud.
Just to throw another annoying case in: a lot of older people have shared email addresses with a spouse.
I mean, they share a postal address and a landline number too, right, why wouldn’t they share an email address?
Which is fine until they both want to sign up with your service as two separate customers.
I have also seen this, but I wonder if it will go away as that generation dies out. I cannot imagine sharing an email address with my wife, and I can’t think of anyone who was under 30 when they got their first email address who does this.
Not quite the same but my wife and I got separate email addresses before 20, yet about 15 years ago we created a shared email address (well, an alias for both out addresses) we use for utility companies—since they don’t allow multiple identities managing the same account.
I imagine that gets confusing quickly when you start getting e-mail notifications from the service. Which account does it pertain to? And some messages to all customers will be duplicate.
I imagine that gets confusing quickly when you start getting e-mail notifications from the service. Which account does it pertain to?
This really isn’t confusing at all. When we got married, my wife and I created a new Gmail account to forward to our real emails (at least one of which is not on Gmail). Because Gmail ignores periods (this.email.account.is.fake@gmail.com and thisemailaccountisfake@gmail.com are handled the same), it is trivial to sign up for services as many times as you like, as long as the service is just doing a string compare for email uniqueness (and I have not yet found a service that rejected my use of Gmail addresses like this).
When an email comes in, you look at the email address it was sent to (just.email or justemail) and you know which account it was intended for. In addition, most services don’t address the email body to the email address, but the user name or person’s name as they signed up. So I can read “Dear [wife’s name]” and know it is not for me, even if I didn’t filter emails down to the ones for me.
And some messages to all customers will be duplicate.
The amount of (what I consider) spam I get from services is vastly greater than the amount of times we both get a meaningful message sent to all customers. Filters also can fix this for you.
Now, assuming a non-technically literate couple that only uses the one email (i.e. logs into Gmail to use that email as their primary), I think you’d also solve the above issues simply by creating filters within Gmail to tag the emails as categories with each of the names on it, again based on the permutation of email that it was sent to.
GitHub has the best user identity model. You can have one account, affiliated with multiple organizations, and log in through any of them. Each org can even set its own requirements for login – so for example my work requires that I login through their SSO, so even if I’m already logged into my own account, I may have to login again to get access to work stuff. You can have multiple email addresses as well and always change which is primary. They’ve clearly put a ton of thought into it.
Ugh yes. I’ve had so many coworkers change names (marriage, transition, adding middle name, etc.), and while the display name change syncs perfectly, the email change causes all kinds of issues.
One that it provides is the NameID, inside of Subject. This is usually something abstract, and it should be unchanging. It’s a reliable way to tell if a login comes from the same person or not. On the other hand, they also include an email attribute.
SAML isn’t prescriptive on what IdPs give as the NameID (§8.2), so a bunch of IdPs do, at least by default, pass emails rather than something abstract and unchanging. Current default NameIDs:
Google: email address
Okta: email address
Azure AD: UPN
Auth0: user ID
So in this specific case, you might blame:
Google, for defaulting to email as NameID
The non-Jira SPs for accepting that default
The SAML spec authors, for being that flexible
To give some specific advice to SPs, it’s less that they need to read the NameID and not other attributes, and more that they need to ask the IdP for a NameID like persistent or transient when they preregister with the IdP. This can be difficult when the folks that are implementing SSO are different from those talking to and registering with the IdP.
For large-scale public services, I agree - email should be easily changed. For smaller business support systems, I think the complexity is not worth it - e-mail address changes will be extremely infrequent (once in a lifetime, or rather once for the duration of an employment) and the occasional change can be handled by a direct update statement in the database by an admin.
In systems design, it can really pay off to consider edge cases to be exactly that - to be dealt with as they occur.
Not that I’m disagreeing with the premise per se but those all sound like “email was not the problem”, but the Google account as a third party canonical auth provider.
When I have x@example.tld at any service (NOT backed by anything), I can usually change to y@example.com and it just works. There is not even a possible workflow where it would assume I am new user unless I click “sign up” again. In this case I assume the software has some half-baked idea of identity “user is authed via Google, and the handle is x@example.org” but then it falls flat when it’s the same “user” but with a different handle-
It’s common for SSO application support to auto-provision user account. Therefor when an application see a new a new user (or email) coming from SSO it sends them to the sign up flow and add the new account to the configured organization. The issue here is that most application identify user based on email and not a persistent IdP identifier.
I don’t see the big issue, to be honest. For incoming e-mail you set an alias, and for outgoing e-mail you can make the SMTP-server aware of aliases, so it does not reject e-mails with the wrong “FROM”-header. Then you gradually switch e-mails with each service you are using.
It’s a bit unfair, in my opinion, to compare a decentralized system like e-mail, which has its weaknesses, to single-company turnkey solutions. It will never be the same.
Maybe this is a stupid question, but, does OIDC works more or less in the same way? As in, if I was developing a B2C system and wanted to let users login with, say, Google, could I support the same use case without compromising security?
Some detail — SAML identifiers can be anything, contributing to this issue, but OIDC gives slightly more guidance to encourage SPs away from depending on email addresses:
sub
REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.
Some issues remain: some IdPs send an email address sub (!) and SPs can usually get the email address off other claims.
I feel the pain. Our organization is currently going through a primary domain change. We are still in the planning phase and it seems like it’s going to be overwhelming, trying to support 50 people, including non-technical people that have to do the same tricks that the author. I think so far the surprising applications that support frictionless transition are Tailscale and Archbee.
It could be worse. I travel around these days, and there’s no hell like defaulting to phone numbers for identification, which are even less stable than emails.
I get a new number with pretty much every country, and it causes so many problems with cross-country services (Grab, Disney+ Hotstar, etc.)
at my company we need to change our email domain as it’s a rather out of date brand name and doing so is insanely complicated just due to how every platform on the planet uses all our employee email addresses as unique keys…
I’m building a new forum software package too and have made the early decision to use usernames as the unique key for people not email addresses. The default installation state for the forum software is to not even require anything to do with emails (smtp, sendgrid, domains, etc) it’s all going away slowly I think.
I’m building a new forum software package too and have made the early decision to use usernames as the unique key for people not email addresses.
Good luck, that makes it impossible to comply with a load of European legislation related to dead names, if the username includes a person’s real name. Please do the thing that others in the thread have recommended and make a UUID or some other opaque token the unique identifier and map anything human-facing to this internally. Users of forum software should be able to change their usernames, contact emails, real names, gender, and so on, without changing their account.
I don’t understand how some pretty big companies get something so obvious so clearly wrong. UUIDs are pretty decent for very large systems, and a bit more random than an auto-incrementing integer. And pretty easy to add unique constraints on email addresses. I built a system that integrated with multiple different external systems, with separate email addresses for each, as some people surprisingly had different email addresses between the different external services.
Also, services using email addresses as primary identifiers makes moving away from one email service to another extremely difficult :(
This mess will continue until parents come to their senses and start giving their children UUIDs as names. When your legal name is “EC691F44-C4D8-48D0-86EF-4A0E7BB8214D”, there’s no reason to ever change it, or your email address. For work email you could even go by a nickname like “EC691F44@example.com” since it’s almost surely unique.
At $WORK, we do something similar at scale. 180k+ users over 500+ applications through an IdP - realistically impossbile to handle name changes manually at our scale. For any given user, they will have a username and email that they are aware of (i.e. jdoe0001 / John.Doe@org.xyz)
However, at the identity level, they actually have different immutable identifiers that are guaranteed to never change:
ea553c28-9db3-4e0c-952d-bcceacb1655ba9362415-7ec7-43a2-ad39-5e095997f553sgyxomlhaisgyxomlhai@p.org.xyzNo application will ever see the ‘human’ attributes like username, but will instead get a combination of attributes. Names can change, usernames and emails can change, but applications will only ever see immutable identifiers in claims from an IdP.
Applications love to use usernames and emails as primary keys, so we enforce application owners to pick one (or more) of the immutable identifiers to consume. No app ever sees anything deemed ‘mutable’ in an OIDC/SAML claim.
Users don’t even know that applications don’t have their ‘human-readable’ email, as the privacyMail is just an alias. But we don’t ever have to deal with the mess that comes with syncing mutable identifiers :)
Isn’t this how most IDPs work? You have an underlying “real” identity and then a bunch of metadata that lets humans differentiate it?
I mean, you kid, but Sweden (and Estonia IIRC) have the concept of a unique identity which is tied to such a system.
In Sweden it’s called a “Personnummer”, it consists of your date of birth and a 4 digit suffix, one used for gender, one for checksum; with an additional number (bringing the total to 5) for an interim number that’s not permanent.
Since they’re guaranteed to be unique they can be used for basically everything and they can be used as primary keys as databases.
You can request a specific personnummer pay some money and it will work, you can request a personnummer sign something which will be forwarded to a BankID phone app for your authorisation.
Works really nicely, honestly.
Encoding gender into the identifier number sounds like a pain for trans people though
You can request a new personnummer with the appropriate gender numeral (IIRC, divisible by 2 means the person considers themselves female), but that leaves enbies in the lurch of course.
You can also request an entirely new personnummer if you need a hidden identity.
The system is from the 1940s and has had to evolve with the times.
Same problems as the similar Finnish one: date of birth can change (apparently recent citizens can turn out to have new and more accurate information about their date of birth) and gender can change. Neither should be part of the immutable identifier.
This was an issue in Sweden too. Other cultures don’t place as much importance on the date of birth as we do, so many people arriving from (IIRC) Syria stated their birthday as the same date in a year, which led to the dates there getting “exhausted”.
The ultimate arbiter of the connection between the numerical identifier and the legal person it’s attached to is Folkbokföringen (population registry), previously part of the local church parish, now part of the tax authority. The “simple” way you get this assigned is through birth. Mom is confirmed to be mom, (dad later), gender is confirmed, birth is reported to the tax authority, and a few days later the personnummer is assigned, and stuff like benefits are routed to the correct recipients. So in a way the number precedes the name, as you’re not required to register a name until 6 months after birth.
That’s really cool, thanks for the information!
If it’s a digit, it could theoretically have room for up to 10 genders… good enough I guess?
I was moreso thinking of being issued a new personnummer, since the closest analog I could compare it to is my SSN, which wasn’t updated to a new number when my name and gender marker were changed. But from the other response, it sounds like they account for changes better in the personnummer system, which makes it less of a roadblock
If you self-identify with the lifelong-tracking-number you’ve been given by the state you might need to deal with that problem first.
This is reductive. If there is a gender component in a number that you cannot change, the gender will be (incorrectly) inferred from the number & automated systems may out you, which increases your surface area for potential discrimination.
Fortunately, looks like you can change it.
Thank you for clarifying the intent of what I was getting at
I can understand why you think it’s like that , but it’s not. The personnummer is simply a numerical representation of your identity. It happens to have a gender component, which is now problematic, just like if you happened to be born outside the country the first digit after the birth date used to be 9, which led to some discrimination.
But fundamentally it’s just a short, numerical, immutable (within limits) representation of who you are.
Using such number as a primary key in your database sounds like a GDPR nightmare. It will end up in logs, URLs and error messages.
There’s also a question of future proofing. What if you start selling to companies in addition to individuals and need to extend your customer registry schema? What Personnummers do you assign to non-persons? Or will you migrate to a new schema, invalidating all existing IDs in the process?
Please just use random integers or GUIDs for this purpose.
Personnummer are now considered to be PII so they should not be used as a primary key (even if that’s been done before).
Note that Sweden’s transparency laws are quite expansive so if you know someone’s personnummer, you basically know their name, and vice versa. GDPR actually restricted these laws.
Companies and other legal persons have a similar number called “organisationsnummer”, used for VAT payments etc.
Estonia’s is pretty much the same (isikukood) — 11 digits which include gender, date of birth, serial number and checksum. Mine was issued post-transition so it has my “current” gender; I’m not sure how (or if) they handle that change.
Interesting choice to encode century (and gender) into the first digit. To me this looks like a better solution than the Swedish (well apart from hardcoding gender) where people born in 1903 and 2003 would share the first “03” digits at the start for standard 10-digit format (nowadays some applications use 12 digits including the century). Estonian numbers won’t have to rollover until around 2150 or so.
Yeah, we have those in Czechia and try to get rid of them in favor of rotating IDs and org-specific IDs to prevent uncontrolled aggregation of personal data.
Anyway, we have 2 duplicates in the old IDs (from what I’ve heard from the guys at the Ministry of Interior). The hospitals ran out of their daily allocation and used next number, hoping for best after delivering the babies. Well, duplicates happened.
Interesting. There was a big debate in the 70s and 80s about how the state was aggregating this data, with laws passed to prevent (say) social services from looking at police databases for criminals. Now the tide has turned, and more and more people are demanding that this can be done to combat benefits fraud.
Hah! Except if you want to move to a different email provider, then you’re stuck once again :p
Tripartite identity is the one true way.
You split up:
The next time you build a user-account system, you can save yourself a lot of trouble by setting it up this way from day one.
Just to throw another annoying case in: a lot of older people have shared email addresses with a spouse. I mean, they share a postal address and a landline number too, right, why wouldn’t they share an email address? Which is fine until they both want to sign up with your service as two separate customers.
I have also seen this, but I wonder if it will go away as that generation dies out. I cannot imagine sharing an email address with my wife, and I can’t think of anyone who was under 30 when they got their first email address who does this.
Not quite the same but my wife and I got separate email addresses before 20, yet about 15 years ago we created a shared email address (well, an alias for both out addresses) we use for utility companies—since they don’t allow multiple identities managing the same account.
I imagine that gets confusing quickly when you start getting e-mail notifications from the service. Which account does it pertain to? And some messages to all customers will be duplicate.
But it could be done with
+aliases perhaps?This really isn’t confusing at all. When we got married, my wife and I created a new Gmail account to forward to our real emails (at least one of which is not on Gmail). Because Gmail ignores periods (this.email.account.is.fake@gmail.com and thisemailaccountisfake@gmail.com are handled the same), it is trivial to sign up for services as many times as you like, as long as the service is just doing a string compare for email uniqueness (and I have not yet found a service that rejected my use of Gmail addresses like this).
When an email comes in, you look at the email address it was sent to (just.email or justemail) and you know which account it was intended for. In addition, most services don’t address the email body to the email address, but the user name or person’s name as they signed up. So I can read “Dear [wife’s name]” and know it is not for me, even if I didn’t filter emails down to the ones for me.
The amount of (what I consider) spam I get from services is vastly greater than the amount of times we both get a meaningful message sent to all customers. Filters also can fix this for you.
Now, assuming a non-technically literate couple that only uses the one email (i.e. logs into Gmail to use that email as their primary), I think you’d also solve the above issues simply by creating filters within Gmail to tag the emails as categories with each of the names on it, again based on the permutation of email that it was sent to.
GitHub has the best user identity model. You can have one account, affiliated with multiple organizations, and log in through any of them. Each org can even set its own requirements for login – so for example my work requires that I login through their SSO, so even if I’m already logged into my own account, I may have to login again to get access to work stuff. You can have multiple email addresses as well and always change which is primary. They’ve clearly put a ton of thought into it.
Ugh yes. I’ve had so many coworkers change names (marriage, transition, adding middle name, etc.), and while the display name change syncs perfectly, the email change causes all kinds of issues.
SAML isn’t prescriptive on what IdPs give as the NameID (§8.2), so a bunch of IdPs do, at least by default, pass emails rather than something abstract and unchanging. Current default NameIDs:
So in this specific case, you might blame:
To give some specific advice to SPs, it’s less that they need to read the NameID and not other attributes, and more that they need to ask the IdP for a NameID like
persistentortransientwhen they preregister with the IdP. This can be difficult when the folks that are implementing SSO are different from those talking to and registering with the IdP.For large-scale public services, I agree - email should be easily changed. For smaller business support systems, I think the complexity is not worth it - e-mail address changes will be extremely infrequent (once in a lifetime, or rather once for the duration of an employment) and the occasional change can be handled by a direct update statement in the database by an admin.
In systems design, it can really pay off to consider edge cases to be exactly that - to be dealt with as they occur.
Not that I’m disagreeing with the premise per se but those all sound like “email was not the problem”, but the Google account as a third party canonical auth provider.
When I have x@example.tld at any service (NOT backed by anything), I can usually change to y@example.com and it just works. There is not even a possible workflow where it would assume I am new user unless I click “sign up” again. In this case I assume the software has some half-baked idea of identity “user is authed via Google, and the handle is x@example.org” but then it falls flat when it’s the same “user” but with a different handle-
It’s common for SSO application support to auto-provision user account. Therefor when an application see a new a new user (or email) coming from SSO it sends them to the sign up flow and add the new account to the configured organization. The issue here is that most application identify user based on email and not a persistent IdP identifier.
I don’t see the big issue, to be honest. For incoming e-mail you set an alias, and for outgoing e-mail you can make the SMTP-server aware of aliases, so it does not reject e-mails with the wrong “FROM”-header. Then you gradually switch e-mails with each service you are using.
It’s a bit unfair, in my opinion, to compare a decentralized system like e-mail, which has its weaknesses, to single-company turnkey solutions. It will never be the same.
But now, honestly, what’s the big deal?
Maybe this is a stupid question, but, does OIDC works more or less in the same way? As in, if I was developing a B2C system and wanted to let users login with, say, Google, could I support the same use case without compromising security?
Yes! Use Google’s
subclaim and you’re good.Some detail — SAML identifiers can be anything, contributing to this issue, but OIDC gives slightly more guidance to encourage SPs away from depending on email addresses:
Some issues remain: some IdPs send an email address
sub(!) and SPs can usually get the email address off other claims.I feel the pain. Our organization is currently going through a primary domain change. We are still in the planning phase and it seems like it’s going to be overwhelming, trying to support 50 people, including non-technical people that have to do the same tricks that the author. I think so far the surprising applications that support frictionless transition are Tailscale and Archbee.
[Comment removed by author]
It could be worse. I travel around these days, and there’s no hell like defaulting to phone numbers for identification, which are even less stable than emails.
I get a new number with pretty much every country, and it causes so many problems with cross-country services (Grab, Disney+ Hotstar, etc.)
at my company we need to change our email domain as it’s a rather out of date brand name and doing so is insanely complicated just due to how every platform on the planet uses all our employee email addresses as unique keys…
I’m building a new forum software package too and have made the early decision to use usernames as the unique key for people not email addresses. The default installation state for the forum software is to not even require anything to do with emails (smtp, sendgrid, domains, etc) it’s all going away slowly I think.
Good luck, that makes it impossible to comply with a load of European legislation related to dead names, if the username includes a person’s real name. Please do the thing that others in the thread have recommended and make a UUID or some other opaque token the unique identifier and map anything human-facing to this internally. Users of forum software should be able to change their usernames, contact emails, real names, gender, and so on, without changing their account.
I don’t understand how some pretty big companies get something so obvious so clearly wrong. UUIDs are pretty decent for very large systems, and a bit more random than an auto-incrementing integer. And pretty easy to add unique constraints on email addresses. I built a system that integrated with multiple different external systems, with separate email addresses for each, as some people surprisingly had different email addresses between the different external services.
Also, services using email addresses as primary identifiers makes moving away from one email service to another extremely difficult :(