Search code examples
emailpunycode

Can punycode-encoded email addresses clash with "real" addresses?


The problem is this: I'm using a third-party Email delivery service that doesn't accept mail addresses with non-ASCII characters in the name part, like müller@example.com .

Encoding such an address with Punycode:

http://en.wikipedia.org/wiki/Punycode

http://idnaconv.phlymail.de/index.php?decoded=m%C3%BCller%40example.com&idn_version=2008&encode=Encode+%3E%3E&lang=de

yields this address:

xn--mller-kva@example.com

And sending mail to it via the service seems to work.

However, I'm not sure if someone couldn't register "xn--mller-kva@example.com" directly, thus receiving Emails meant for "müller@example.com".

Is this clashing possible ? Are there other solutions for this problem ?

UPDATE

Thanks for the answers. Here's a summary of what we learned:

  • Punycoding the local part of the email address works, and you can send and receive from such an encoded address (of course)
  • However, there are no guarantees at all that providers or mail clients will understand the encoding, or do it automatically. Clashes are therefore possible, and the whole idea not a good one :)
  • One should simply do what everyone else does, which is to not allow or accept non-ASCII name parts, as per specification
  • And finally, it turns out the third-party service prohibits such shenanigans anyway.

Solution

  • did a few tests.. umlauts in the local part seem to work in certain setups. neither my MUA (claws) nor the outbound relay (exim) nor the receiving MTA (postfix) complained or did any punycode conversion. providers like gmail and hotmail however don't allow the umlauts at all ( tested webmail and direct incoming and outgoing smtp). I didn't find any documentation about this case that suggests punycoding local parts.so, since it's not documented and no one does it there is no clashing problem :-)

    conclusion: you probably shouldn't accept umlauts in the local part in the first place and not even try to send an email to those addresses. (if the big players don't do it and it's not documented/supported by RFC, why should you?)