The likelihood of such a “hack” happening using the Turkish dotless “I” is ZERO as all Turkish email addresses and website domains are formatted WITHOUT using Turkish characters which include examples like: ç, ı, ü, ğ, ö, ş, İ, Ğ, Ü, Ö, Ş, Ç
That’s incorrect. The attack vector hinges on the ability to create email addresses with Turkish characters. There is nothing stopping an attacker from creating addresses with Turkish characters to attack existing addresses without Turkish characters.
Turkish emails are not supported in the first place.
Internationalization examples[edit]
The example addresses below would not be handled by RFC 5322 based servers, but are permitted by RFC 6530. Servers compliant with this will be able to handle these:
RFC 6530 doesn't mention those character sets explicitly. It proposes allowing all Unicode characters, apart from some control characters.
It is true that the RFC recommends mailbox providers take normalization into account. A mailbox provider that allows i and dotless-i addresses to be routed to different mailboxes is careless, if not actually uncompliant. I don't know if any popular provider does this: I'm guessing the authors created their own to demonstrate this attack.
If you are at interested in Turkish characters:
https://en.wikipedia.org/wiki/Wikipedia:Turkish_characters
https://www.turkcebilgi.com/türkçe_karakter
This should be called the Turkish character hack: A hack only possible in the theoretical realm.
These characters are rendered in HTML and supported by OSes. They are just not used for emails AND website domains.
So the password reset “hack” with an email containing Turkish characters in not a possibility from the get go.
The whole attack vector hinges on emails that exist with Turkish characters in the first place.