Nope. RFC 5321: "the local-part MUST be interpreted and assigned semantics only by the host specified in the domain of the address". That means it's actually technically against the RFC to do any normalization of the local-part (like ignoring dots or case).
My point is that the RFC doesn't say they "don't matter", it says they don't have to matter. For Netflix to assume they don't matter would be in violation of the RFC (it would be assigning semantics to the local-part).
Doesn't that support what Google is doing? Google is the host specified in the domain, and they are interpreting the local-part to refer to the same mailbox if they only differ by dots.
The RFC also notes that the local-part MAY be case-sensitive (i.e. it's up to the host).
Edit: the host SHOULD ignore case: "a host that expects to receive mail SHOULD avoid defining mailboxes where [...] Local-part is case-sensitive".
It does. The relevant RFC says they don't have to matter and that senders shouldn't assume they do or don't. That means that both Google and Netflix are following the standard. The problem isn't with either company's compliance with the RFC, but that's not saying a lot. A mail provider could legally ignore all vowels in mailbox names.
(Similarly, although the RFC does say hosts shouldn't have case-sensitive local-parts, it doesn't say that senders can assume that local-parts are case-insensitive.)
By that logic, jacksmith@example.com and johnjsmith@example.com could be delivered to the same mailbox. When I read TFA my first thought was "what does the standard say about it" and it does sound like Netflix is the one making the wrong assumption here.
But I also see his point about how this can confuse users who don't realize this or are not using this behavior intentionally.
> By that logic, jacksmith@example.com and johnjsmith@example.com could be delivered to the same mailbox.
They absolutely could. Netflix can't assume they are or they aren't. Which means Netflix is doing the correct thing here. All they can know is that the emails are potentially different and so they should treat them as different emails.
Yup. Since I run my own email server, I have 200 email addresses that are delivered to a single account. Some are service accounts (like postmaster@example.org) but a lot are single-use email accounts to track the selling of email addresses and spam.
These are all different e-mail addresses; that part should not be surprising, and Netflix is absolutely doing the right thing by considering them different. (The same goes for "+labels": a "+" is a perfectly valid character in the local part of an e-mail address and the meaning of the "+" is entirely up to the mail host, so e.g. rejecting e-mails with a "+" or stripping out the "+" and following characters would violate the RFCs.)
No, Netflix's errors lie in (a) sending e-mail for any purpose other than account validation to an unvalidated e-mail address, and (b) including a pre-authenticated link in the e-mail that bypasses the normal account access controls. Pre-authenticated links are poor security practice in general; e-mail is notoriously insecure, and simply being able to read an e-mail sent to the address on file does not imply that the reader should have access to the account.
As for "dots don't matter", it can be argued that Google made some scams a bit easier by routing e-mails to non-canonical e-mail addresses to users who don't realize they even have such addresses; my own recommendation would have been to block registration of e-mails differing only in the number or placement of dots, but bounce any incoming mail where the "To:" field doesn't match the canonical form chosen at account creation time. However, since doing away with the "dots don't matter" policy would not significantly impact the more general issue of e-mail address aliasing, I do not believe that Google's policies are to blame for this particular security gap.
Those are three different addresses. On some systems they may be three different accounts. On others they may be one account.
On some systems, anything ending in '@example.com' may be a single account.
It may be that defined address to account mappings exist on a domain and all other addresses map to a default account. It's common enough the hosting industry supports it and it has a name - a catchall email account.
Nobody sending mail to any of those addresses needs to know how many addresses map to the account associated with the address to which they are sending. It's an address, not an identifier. I would argue you don't have a reason nor a right to know the address to account mappings in my systems.
What a sender should reasonably expect is that someone who can receive mail delivered to a particular address is in charge of the email account to which that address maps. Sending a verification email to someone expecting to receive it is the way to validate the recipient is the intended recipient. That's it.
If I give you my phone number, do you need to know what other phone numbers will ring that phone or how many phones I answer in order to call me? Do I need to disclose all the possible places I might receive a package if I want one delivered to a single place? No.
Email addresses are addresses. That's all they are. Stop pretending they are something else, and this will become much clearer for you.
Google follows the standard, Netflix does not.