3 ms·

Which the RFCs for email do allow. The local part is the local part, under local control, and should not be assumed about by remote systems.

B1FF_PSUVM 9y ago
Regular people, upon looking at an email address, might think that - alert@example.com - A.Lert@example.com - Al.Ert@example.com etc. were different. Requiring them to know or check what's the "local control" policy at each site may be a stretch. Principle of least surprise, etc.
- nybble41 9y ago
  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.
- cestith 9y ago
  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.

B1FF_PSUVM 9y ago

Regular people, upon looking at an email address, might think that - alert@example.com - A.Lert@example.com - Al.Ert@example.com etc. were different. Requiring them to know or check what's the "local control" policy at each site may be a stretch. Principle of least surprise, etc.

nybble41 9y ago
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.
cestith 9y ago
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.