In traditional ASCII mail, the local part of the address, what goes before the @ sign, can be any printable ASCII characters. Although an address like %i()/;~f@examp1e.com is valid, and mail systems will handle it, users don't want addresses like that. A good address is one that is easy to remember, easy to tell someone over the phone, and easy to type.

Mail systems all give senders some help when interpreting addresses. If an address is Bob@example, they'll accept bob@ or BOB@. If the address is joe.smith@, they'll accept Joe.Smith@ and often variations in punctuation like joesmith@ without the dots.

The flip side of this is that you don't assign different addresses that are too similar. While it is techincally possible that BOB@ and bob@ could deliver to different mailboxes, nobody does that. Similarly, nobody makes joesmith@ and joe.smith@ different. (They may not both work, but if they do, they're the same mailbox.)

The domain (the part of the address after the @ sign) has to follow the DNS rules, which don't allow any fuzzy matching other than ASCII upper and lower case.

How does all this extend into EAI mail?

EAI extends ASCII addresses in a straightforward way -- in addition to any printable ASCII characters the local part can contain any printable UTF-8 characters, and the domain can be UTF-8 U-labels. As before, users will have an easier time if mail systems assign addresses conservatively and interpret addresses on incoming mail liberally.

The PRECIS working group at the IETF defined string classes for different applications. The Identifier class works well for mailbox names, codepoints that are (roughly) letters and digits in various languages.

It also provided rules to prepare UTF-8 strings for use. Unicode often provides multiple ways to represent exactly the same character, e.g., a single codepoint for an accented character é or separate e and accent codepoints. It often also has variant characters that look different but mean approximately or exactly the same thing, such as full-width and half-width versions of characters, Latin digits 12345 and Arabic digits ١٢٣٤٥, or traditional and simplified Chinese characters. To prepare a string, software maps variant codepoints into preferred ones, usually precomposed characters such as é. Mail systems should assign mailbox names in prepared form, but they can and should accept addresses in incoming mail in any form since they can prepare them as they receive them. (This is different from the DNS where DNS servers only do exact matches so the client has to do any preparation.)

There's no reason that a mail system's fuzzy matching has to stop where PRECIS and ASCII addresses did. The Latin and Arabic digits aren't the same for PRECIS, but it's easy enough for a mail system to map them together and to ensure that it doesn't issue two mailboxes with digits that collide. In Latin languages with accented or multiple forms of characters (such as the Turkish dotless ı) a conservative mail system would avoid assigning addresses that differ only in the form of a letter, accept all versions of the letter, even ones that aren't valid or equivalent in the user's language. For example, even though Turkish speakers wouldn't write i for ı, correspondents who don't speak Turkish might, and it's easier all around if the slightly misspelled address works. Similarly, in Scandinavian languages the letters O Ø Ö are different, but it'd be a good idea to accept the wrong versions in incoming addresses.

Mail systems have only recently started to assign EAI addresses, and I'm not yet aware of any of them doing fuzzy matching on incoming addresses. But for the same reason we have found it a good idea to allow jimsmith@ for jim.smith@ in ASCII mail, EAI mail systems will have to figure out how to adapt to however their correspondents type the EAI addresses.