[paxys]

Disagree with the first two.

1. Netflix shouldn't have to care about the internal implementation of Gmail addresses. It's perfectly fine to treat [e-mail] and [e-mail] as separate accounts.

2. If you attempt to sign up for Netflix with an email address which already exists in their system and they tell you that, it isn't a security or privacy breach. There is absolutely no other way to handle the situation.

Agree with the third one though. A "click here to activate" email absolutely needs to be standard in every sign-up flow.

[fvargas]

By canonicalization I'm not saying any arbitrary practice by Gmail or any other email provider should be considered as standard. I haven't looked at the RFC in some time, but I don't believe the use of plus suffixes is standard either. Nonetheless, I believe plus suffixes are more commonplace, generally permitted, and serve a reasonable purpose. For instance, sending email to a user using their email address as provided is a good practice in order to preserve a plus suffix which may aid the user in organizing their email. At the same time, canonicalizing email addresses in a sensible way, e.g. stripping plus suffixes, can be an aid for preventing unintentional, duplicate sign-ups. Just consider a sign-up form on the homepage of a website. It's not uncommon for people to enter their email and password into that form by mistake thinking they're signing in. Additionally, if the website compares canonical email addresses when checking login credentials, then a user who signed up with an email address containing a plus suffix can sign in using their base email. These two situations combined could lead to the accidental creation of a duplicate account if canonical email addresses are not compared during registration. There are some trade offs with this strategy, but as long as the canonicalization is implemented reasonably, I see it as an aid to the user. Note that reasonably doesn't necessarily mean stripping dots.

As for the second point, I consider it a privacy breach if a service publicly associates my email address with their service without my consent. Sign-up forms do this when giving different responses when an email address is registered vs not registered.

As for how to handle it, if a user signs up with a new email address, you send them an email to verify their email address and instruct them to check their email. Similarly, if a user attempts to sign up with an already registered email address, you send them an email letting them know they already have an account and instruct them to check their email, which will provide them with a link to login.

In the latter case, if they enter the correct password, you can just directly tell the user they already have an account, as they've proven their identity.

[__david__]

The problem with your canonicalization idea is that it doesn't work in all cases. Yes, it might work with gmail addresses, but there's no way that you can assume that "[e-mail]" and "[e-mail]" are actually the same mailbox. If you so assume that, then you've just broken you websites for users where that isn't the case.

[fvargas]

Why would you broadly assume an incorrect rule? Email address parsers correctly implement canonicalization rules that consider the domain e.g. gmail. It doesn't require any extra work as a developer and the logic is hidden behind the abstraction. But certainly, you shouldn't go implementing arbitrary rules that aren't reasonably applicable.