That's not a hole. Those are different email addresses according to the email standard.
How exactly would this attack even work that you have in mind? And wouldn't it even be easier to conduct this so-called attach on an email host that actually treats first.last@domain.com as a different email from firstlast@domain.com since it wouldn't even require the 'victim' to click anything in their email?
The right answer is for Apple to keep treating them as separate emails and refuse to give people access to accounts with different email addresses. It's that simple.
>Those are different email addresses according to the email standard.
Not really. It's left open to interpretation from my reading of the relevant RFC. The spec says the dot-atom form should be used but does not say in what way it should be used. Google collapses x.y.z@gmail and xyz@gmail.com to the same thing which is fine they're welcome to do so. However the Apple IDs x.y.z@gmail.com and xyz@gmail.com are entirely different entities. So we have a namespace collision in one space but not the other because although an Apple ID looks like an e-mail address it's not. I'm just saying that can create a problem.
An addr-spec is a specific Internet identifier that contains a
locally interpreted string followed by the at-sign character ("@",
ASCII value 64) followed by an Internet domain. The locally
interpreted string is either a quoted-string or a dot-atom. If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the quoted-
string form SHOULD NOT be used. Comments and folding white space
SHOULD NOT be used around the "@" in the addr-spec.
> It's left open to interpretation from my reading of the relevant RFC
No. The part of the spec you quoted says that if the local part of the email address is in the format "atext+ (\. atext+)*" where atext is "Any character except controls, [spaces], and specials", then the quoted-string form shouldn’t be used. In other words, don’t use quotes when you don’t need them. This has nothing to do with how to "interpret" dots; they are interpreted like any other char except they can’t occur everywhere in the local part (e.g. "foo.@bar.com" isn’t valid).
>The locally interpreted string is either a quoted-string or a dot-atom
That's pretty clearly stating (to me) that the dot-atom is locally interpreted. It doesn't say anything about how to interpret a dot-atom. Just to use it in preference to the quoted string if the rules you mention apply.
You're mixing up two different concepts. E-mail address and mailbox. Multiple e-mail addresses can be used to deliver to the same mailbox. That's what "local intepretation" means. a.a@b is still a different address than aa@b.
And in the end is what happens with gmail. You have one mailbox and all versions of your mailbox with dots in between the characters as alias automatically.
How exactly would this attack even work that you have in mind? And wouldn't it even be easier to conduct this so-called attach on an email host that actually treats first.last@domain.com as a different email from firstlast@domain.com since it wouldn't even require the 'victim' to click anything in their email?
The right answer is for Apple to keep treating them as separate emails and refuse to give people access to accounts with different email addresses. It's that simple.