I appreciate your reference to RFC-5321. I agree that "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address."
However, in practice, there exist many services which have GMail's logic baked-in. Or worse, they get overzealous/underzealous with validating the email.
For example, you decide to sign up for e.g. Netflix as [email protected], which is the address for a Google account which you own completely.
There exists a small edge case where you want a second Netflix account, so you could do that by also registering [email protected]. Or [email protected]. In that case, all the emails to these 2 addresses will be directed to the 'main' [email protected], as you might be aware of. So you'll get messages for more than one, separate Netflix accounts on the same inbox.
I'm not sure if they had this "plus aliasing" from the beginning, same as their logic with the dots.
When I say that there exist many services which have GMail's logic baked-in, I mean that certain apps will forbid you from registering again as [email protected] or even [email protected], because they want to stop on person from 'exploiting' multiple accounts (though Netflix is not one of them).
It is indeed important to go back to the RFC and understand what you are pointing out:
i.e. That, even though GMail redirects messages from both [email protected] and [email protected] to plain old [email protected], it doesn't make it standard behavior, and this is likely not the case for your home-brewed mail server or your enterprise exchange server, which may treat those as separate inboxes, and this can lead and has led to unintended consequences.
I've been involved in the QA of a system which handles payments for a telecommunications provider. It's very common for the customer to land on a payment page, where he essentially clicks on a link, his telecom's account information is pre-filled, like his email address, phone number, and payment amount, and the customer just has to fill in payment information. So even though the telecoms provider can (and in some instances already has) saved a customer's email with a plus sign, the external payment processor's portal mangles it during parsing, converts the plus signs to a space, and then complains about a malformed URL.
As always, this gets filed as out of scope.
However, in practice, there exist many services which have GMail's logic baked-in. Or worse, they get overzealous/underzealous with validating the email.
For example, you decide to sign up for e.g. Netflix as [email protected], which is the address for a Google account which you own completely.
There exists a small edge case where you want a second Netflix account, so you could do that by also registering [email protected]. Or [email protected]. In that case, all the emails to these 2 addresses will be directed to the 'main' [email protected], as you might be aware of. So you'll get messages for more than one, separate Netflix accounts on the same inbox.
I'm not sure if they had this "plus aliasing" from the beginning, same as their logic with the dots.
When I say that there exist many services which have GMail's logic baked-in, I mean that certain apps will forbid you from registering again as [email protected] or even [email protected], because they want to stop on person from 'exploiting' multiple accounts (though Netflix is not one of them).
It is indeed important to go back to the RFC and understand what you are pointing out:
i.e. That, even though GMail redirects messages from both [email protected] and [email protected] to plain old [email protected], it doesn't make it standard behavior, and this is likely not the case for your home-brewed mail server or your enterprise exchange server, which may treat those as separate inboxes, and this can lead and has led to unintended consequences.
I've been involved in the QA of a system which handles payments for a telecommunications provider. It's very common for the customer to land on a payment page, where he essentially clicks on a link, his telecom's account information is pre-filled, like his email address, phone number, and payment amount, and the customer just has to fill in payment information. So even though the telecoms provider can (and in some instances already has) saved a customer's email with a plus sign, the external payment processor's portal mangles it during parsing, converts the plus signs to a space, and then complains about a malformed URL.
As always, this gets filed as out of scope.