It appears that Bob Traverz <[email protected]> said: > - Normalization Rules: Before banning dot-removal or plus-tag stripping, >I recommend checking the current practices of Gmail and Outlook. This will >ensure your specification caters to the majority of email IDs.
Hi, mail person here. Our RFCs are quite clear that the local part of an address is completely opaque. Any assumptions you make about normalizing local parts are wrong, both in theory and in practice. This is a very hard problem, many people have tried to solve it in the past, and they've all failed. Gmail ignores dots so [email protected] and [email protected] are equivalent, but I do not know any other system that does that. Sometimes [email protected] and [email protected] are the same, usually they are not. Sometimes a system manually adds dotted and dotted variants to their alias tables, so it's only as consistent as the maintainer makes it. Some systems allow plus tags, some don't. Some use other characters than plus. It's not even consistent on a single system -- on mine, some foo-bar addresses go to the same places as foo, some don't. Since we added EAI addresses which allow UTF-8 characters in addresses, you can't even do case folding reliably since it's language specific. As a famous example lower case i and upper case I are equivalent in most European languages, but not in Turkish where dotted and undotted i are different characters with upper and lower case versions of both. There are lots of other variations like รถ which in German is considered a short version of oe but in Scandinavian languages is not. People have tried to come up with rule sets about mail systems' normalizations. It doesn't work for two reasons. One is that in most cases you don't know what a system's rules really are (what does Gmail do with two dots in a row?), the other is that there are more mail systems than you know, and you'll never have a complete set. The usual approach is to pretend none of this matters and to invent a scheme that will fail randomly on addresses that don't make the same assumptions you do. In this case you can do better, since you can pass the unmodified local part to the keyserver and it can do whatever the local policy is to the address and return the actual key. R's, John _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
