5 ms·
If you have a bug in a system, do you fix it at the source, or do you fix it at all the leaves? Netflix might be wrong here, but fixing it at Netflix doesn't ma
by axoltl 9y ago
If you have a bug in a system, do you fix it at the source, or do you fix it at all the leaves? Netflix might be wrong here, but fixing it at Netflix doesn't make the problem go away. Fix the problem once (GMail) and never ever have to deal with it again.
- chatmasta 9y agoBut you can’t put the cat back in the bag. People have used the system to sign up for multiple emails at multiple sites, expecting them to go to the same inbox. I suppose you could solve the problem by grandfathering all existing aliases and whitelisting delivery of only those that received at least one email before the policy change. And also continuing to forbid registration of any aliases.
- jwilk 9y agoI'm (naively?) hoping that Google doesn't know which aliases received at least one email.
- chatmasta 9y agoOf course they know. They delivered the emails to the aliases, which are permanently in the To: field of the metadata. As long as you can see the email “to” address in the gmail web interface, so can Google.
- deleted 9y ago[deleted]
- fjsolwmv 9y agoThere is no bug in Gmail. This bug has nothing to do with Gmail, it is with Netflix not clearly communicating when verifying the address a user claims to own.
- ksk 9y agoThe bug is in humans. Heck, I regularly come across people who think the case in an email address matters! While there is no bug in Gmail, that is irrelevant because you have to deal with the reality of how people use your product. Its basic engineering. Standards are simply a means for interoperability. In this case, the dots don't matter much for that goal.
- sandov 9y agoThe case in an email address does matter. Look it up.
- spc476 9y agoRFC-5322 (the current standard for Internet Message Formats) in section 3.4.1 states, "... how address is used and how messages are transported to a particular host is covered in separate documents, such as [RFC5321]." RFC-5321 states in section 2.3.11: ''The standard mailbox naming convention is defined to be "local-part@domain"; contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.' Furthermore, it states in section 2.4: 'The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.' While you are pedantically correct, to me that reads, "don't try to change the case of the local portion of email addresses and apply no meaning to it." In other words, treat it "as-is" and assume nothing about it.