Zend Framework

after some try it appear that the ace code in not sended to dns_get_mx it's the full human string
so when münche.ch is write by the user, the dns_get_mx check have to receive this xn--mnche-kva.ch

but validatehostname complain if it is used with the ace chain ...
xn-mnche-kva.ch is not valid 'xn-mnche-kva.ch' appears to be a DNS hostname but contains a dash in an invalid position
'xn--mnche-kva.ch' appears to be a local network name but local network names are not allowed --->>> this is wrong a local host would be mypc.mydomain.mytld

Not an easy case ...

Information about ICN ( switzerland base )
http://nic.switch.ch/reg/ocView.action?request_locale=en

IDN is supported for CH.
Punycode is not accepted for email adresses as "--" is not allowed for the 3rd/4th character within domain names as per definition within the domain holder.

Optional support for PunyCode is not an issue of Zend_Validate_Email and filled within another independent issue.

Though this issue is marked as fixed/resolved, I think it's not. Or I need clearer explanation.
Here is a simple test case:
max@xn--iphignie-f1a.com does validate as it should, no problem due to hyphen in 3rd char.
max@iphigénie.com does not validate IF setValidateMx(true).

So there is a difference in the way both addresses are processed while it should not since the second should be reduced to the first.

Can someone clarify or else reopen the issue?

Forgot to mention I just tested on 1.9

Well, I dig into and found the point.
Hostname validation works the reverse: it convert xn-- form to utf8 then checks the validity of the utf8 string along definition for the given tld.
This is ok for testing the domain. Definitely not for the validateMx step since it uses dns_get_mx without prior conversion to punycode.

So the documentation is wrong stating that the validator is able to check IDN. It is only able to statically check the string, not to step on DNS part.

Alongside no way to use mail with an utf8 IDN. It should be converted to xn-- outside of Zend.

Too bad the punycode conversion is only the decoding half.

Validating MX means that the given hostname is processed by getmxrr().

When getmxrr() resolves Punycode but not IDN I would say that there is a problem with your host and not with getmxrr().

I would understand when punycode does not work but IDN.
I can not understand why the reverse does not.

Eighter way... what ever you give a input is processed by getmxrr() which itself requests this information at your host. So for me it seems like there is a host problem.

The original issue has been fixed as CH did not have an attached IDN and this case is tested in our testbed now.

Hi Thomas,
to be sure we both use the same definition lets state:
punycode: xn--iphignie-f1a.com (or do you call this IDN?)
IDN: iphigénie.com

The first is correctly resolved by getmxrr() as expected since it conform to legacy domain naming.
The second is not, and I see nowhere it should. No documentation states that getmxrr() does encode utf8 punycode.

Do you agree?
If yes, we also agree that one can't validate IDN in utf8 string form.

As said before:
If the host you are working with supports IDN depends on the host itself, and not on getmxrr().

A IDN domain must not be converted to punycode for requests. Punycode is only needed for domains which do not support IDN.

Note that IDN domains are also not converted to punycode by your host.

So: No, I do not agree and tested it with verizon.

This is not the understanding I had.
I though any effective DNS request should be in punycode form (xn-iphignie-f1a.com). And that the conversion should be handled at application level. You are saying quite the opposite. For a TLD to support IDN it should accept xn- starting domain and define a character set allowed. I'll have to check this out further.

Anyway, i tested this both on my OS X 10.6 dev host and on linux debian on the production server. I would like to know on which environment you successfully test an IDN in utf8 string format.