Issue Type: Bug Created: 2008-08-21T01:24:06.000+0000 Last Updated: 2013-03-08T12:03:19.000+0000 Status: Resolved Fix version(s): - 1.8.0 (30/Apr/09)
Reporter: Bruno Friedmann (brunofriedmann) Assignee: Thomas Weidner (thomas) Tags: - Zend_Validate
Related issues: - ZF-12537
With a check on
$validatorHostname = new Zend_Validate_Hostname(); $validatorEmail = new Zend_Validate_EmailAddress(Zend_Validate_Hostname::ALLOW_DNS, true, $validatorHostname);
$email to test someuser@münche.ch return false 'münche.ch' does not appear to have a valid MX record for the email address 'someuser@münche.ch'
Or this domain as a valid MX
dig mx xn--mnche-kva.ch
; <<>> DiG 9.4.2-P1 <<>> mx xn--mnche-kva.ch ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46968 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
;; QUESTION SECTION: ;xn--mnche-kva.ch. IN MX
;; ANSWER SECTION: xn--mnche-kva.ch. 43200 IN MX 10 mail.xn--mnche-kva.ch.
;; AUTHORITY SECTION: xn--mnche-kva.ch. 42170 IN NS ns3.ch-meta.net. xn--mnche-kva.ch. 42170 IN NS ns.ch-meta.net. xn--mnche-kva.ch. 42170 IN NS ns2.ch-meta.net.
;; ADDITIONAL SECTION: mail.xn--mnche-kva.ch. 43200 IN A 220.127.116.11 ns.ch-meta.net. 171770 IN A 18.104.22.168 ns2.ch-meta.net. 171770 IN A 22.214.171.124 ns3.ch-meta.net. 171770 IN A 126.96.36.199
test to confirm $email = someuser@münchen.ch return false : this is true the domain doesn't have a mx record.
dig mx xn--mnchen-3ya.ch return nothing ...
Should be corrected before 1.6 release to my opinion
Posted by Bruno Friedmann (brunofriedmann) on 2008-08-21T01:56:05.000+0000
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 ...
Posted by Bruno Friedmann (brunofriedmann) on 2008-08-21T01:58:19.000+0000
Information about ICN ( switzerland base ) http://nic.switch.ch/reg/ocView.action/…
Posted by Thomas Weidner (thomas) on 2009-03-26T13:54:51.000+0000
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.
Posted by Max Barel (max_b) on 2010-01-05T14:21:51.000+0000
Though this issue is marked as fixed/resolved, I think it's not. Or I need clearer explanation. Here is a simple test case: email@example.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?
Posted by Max Barel (max_b) on 2010-01-05T14:23:17.000+0000
Forgot to mention I just tested on 1.9
Posted by Max Barel (max_b) on 2010-01-05T15:21:03.000+0000
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.
Posted by Thomas Weidner (thomas) on 2010-01-05T15:51:19.000+0000
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.
Posted by Max Barel (max_b) on 2010-01-05T16:13:33.000+0000
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.
Posted by Thomas Weidner (thomas) on 2010-01-05T17:03:25.000+0000
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.
Posted by Max Barel (max_b) on 2010-01-05T17:28:48.000+0000
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.
Have you found an issue?
See the Overview section for more details.