ZF-4018: Zend_Email_Validate ( wrong result on idn domain )

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ü return false 'mü' does not appear to have a valid MX record for the email address 'someuser@mü'

Or this domain as a valid MX

dig mx

; <<>> DiG 9.4.2-P1 <<>> mx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46968 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4



;; AUTHORITY SECTION: 42170 IN NS 42170 IN NS 42170 IN NS

;; ADDITIONAL SECTION: 43200 IN A 171770 IN A 171770 IN A 171770 IN A

test to confirm $email = someuser@mü return false : this is true the domain doesn't have a mx record.

dig mx 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ü is write by the user, the dns_get_mx check have to receive this

but validatehostname complain if it is used with the ace chain ... is not valid '' appears to be a DNS hostname but contains a dash (-) in an invalid position '' 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 )…

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: does validate as it should, no problem due to hyphen in 3rd char. max@iphigé 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: (or do you call this IDN?) IDN: iphigé

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 ( 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.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.