Issue Type: Bug Created: 2009-01-20T05:05:49.000+0000 Last Updated: 2009-09-09T12:59:03.000+0000 Status: Resolved Fix version(s): - 1.10.0 (27/Jan/10)
Reporter: Csaba Csecskedi (csecskedi) Assignee: Thomas Weidner (thomas) Tags: - Zend_Validate
Related issues: Attachments: - EmailAddress.php
$validator = new Zend_Validate_EmailAddress(Zend_Validate_Hostname::ALLOW_DNS, true); var_export($validator->isValid("email@example.com"));
Zend_Validate_EmailAddress validate invalid MX record yyahoo.de because dns_get_mx() function returns array(0=>'') value.
Posted by Thomas Weidner (thomas) on 2009-04-04T13:36:25.000+0000
The MX check is only processed when dns_get_mx is available. Within Windows for example no mx check is done.
Posted by Ben Scholzen (dasprid) on 2009-04-04T14:21:08.000+0000
dasprid@dasprid-desktop:~$ host -t MX yyahoo.com yyahoo.com mail is handled by 0 .
dasprid@dasprid-desktop:~$ host -t MX some-non-existent-domain.com Host some-non-existent-domain.com not found: 3(NXDOMAIN)
Posted by Thomas Weidner (thomas) on 2009-04-04T15:03:46.000+0000
I still don't get the point. Array(0=> '') is detected and no error is thrown as count is 1.
MX is not a good way to detect the server, because according to RFC when no MX is available it has to be set to 0 and ignored.
The reason behind is that a server may accept mails from unknown domains according to RFC. In my opinion this is not really an error as it works as defined by RFC.
Additionally dns_get_mx is not available on Windows systems.
Posted by Laszlo Berta (lalaman) on 2009-04-28T02:40:18.000+0000
I have to agree with the reporter, it is a bug. It might be working as defined in the RFC page, but it is still a functional disorder.
@Thomas: 'The reason behind is that a server may accept mails from unknown domains according to RFC.' If we're talking about accepting, recieving mails, it's okay, but if you want to validate is for sending, it's no longer correct. E.g. you try to validate an email address given by a future user, who wants to register on your website, and mistypes his/her email address, and the firstname.lastname@example.org passes the validation, the user will never get the confirmation mail. Another example: take an e-card sending website, and try to imagine, how many 'delivery status notification' emails will the server recieve only because of the incorrectly validated yyahoo.de, uyahoo.com domains given as 'Send to' email domains.
Keeping it short: the functionality implemented in the Zend_Validator_EmailAddress for checking the MX record is not correct if you have to validate a user input for email sending.
Posted by Thomas Weidner (thomas) on 2009-04-28T02:59:46.000+0000
I still don't get the point: yyahoo.com DOES exist... see http://whois.domaintools.com/yyahoo.com
The own server is only not able to detect additional data... therefor a 0 is returned and no false.
So the thing seems more that MX itself is no proper way for a verification and not that it does not work in all usecases. And my point is that when 50% of the cases are correct it should stay implemented. Erasing the MX test would mean that no case can be verified.
Posted by Gergely Sipics (gergely.sipics) on 2009-04-28T03:19:19.000+0000
Yes the primary goal for MX checking should be checking if the target server has any usable MX record. If it has only unusable records, like 0 or 127.0.0.1 (what is RFC compilant), the developer should be able to get some info about this. So in my opinion, it would be great to add an optional parameter to the validator function for MX usability checking. It shold be for checking for unusable (0) and unrouted/private IP addresses like 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 (for IPv4) too. (IPv6 checking would also be useful in futrure releases.)
Posted by James Dempster (letssurf) on 2009-04-28T03:30:14.000+0000
This method already break the RFC's.
A domain may have no MX records and can still be a valid email address and recieve emails.
"If no MX records were present, the server falls back to A, that is to say, it makes a request for the A record of the same domain." cite: http://en.wikipedia.org/wiki/MX_record
"If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host." cite: http://www.ietf.org/rfc/rfc2821.txt
"If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error." cite: http://www.ietf.org/rfc/rfc2821.txt
Therefore yyahoo.com is an invalid domain for mail delivery because it's MX records are invalid.
Secondly the isValid method should be changed to check for A records with mail servers on them if no MX records are present.
Posted by Gabor Ivan (gixx) on 2009-04-28T03:37:24.000+0000
@Thomas: we don't want to erase the MX test, but extend it to make it smarter.
In our opinion the problems are e.g.:
Question: Why? Answer: uyahoo.com mail is handled by 10 10.0.0.2. Conclusion: It is not in a routable network segment. This address should not be resolved form public network.
Question: Why? Answer: yohoo.com mail is handled by 0 . Conclusion: it's a common mistake, They have registered it, but the MX record is empty or just a "."
Recommendations: - extend the validator to check for not only the MX but also the following records: MX, A, AAAA, A6, and maybe CNAME
10.0.0.0/8 # RFC 1918 127.0.0.0/8 # this host 169.254.0.0/16 # link-local 172.16.0.0/12 # RFC 1918 192.0.2.0/24 # example net 192.168.0.0/16 # RFC 1918 198.18.0.0/15 # benchmark net 188.8.131.52/3 # multicast & reserved
VERY IMPORTANT: it should NOT be a default behaviour, but give the chance to the developers to prepare their application to use it.
Posted by Thomas Weidner (thomas) on 2009-04-28T04:13:07.000+0000
To summarize: From the 3 levels of validation we will only support 2 levels. Syntax and MX... SMTP validation will not be implemented as it can lead to a 70 seconds delay until the mail server responded.
Regarding IPV6: Please note that IPV6 is not handled by Zend_Validate_EmailAdress but from another component. This is not part of this issue and will be solved differently.
Regarding A RR: dns_get_record has the same problem as getmxrecord... not available under Windows. I have to dig if there is a simple solution.
Regarding "good idea": Please note that "good ideas" are not part of this issue. I would ask, if you have a feature enhancement, to write a separate issue describing it.
Last of my points: Please note that the solution of this bug will still take additional time as discussion is not equal with bug-fix :-) But you can be sure that I will fix this bug when no one applies a patch. It's just a matter of time ;-)
Posted by Gabor Ivan (gixx) on 2009-05-04T07:16:11.000+0000
This modified (patched) Zend_Validate_EmailAddress class allows users to perform a deeper email address analysis.
The modified file is based on Zend Framework 1.8 RC source.
Please check it, test it, modify it if needed.
Posted by Thomas Weidner (thomas) on 2009-06-10T12:53:20.000+0000
@Gabor: Thank you for the patch.
BUT: * It does not work on other environments than *nix... this limitation is not acceptable for ZF * It integrates code from another project... this is not allowed within ZF
Posted by Thomas Weidner (thomas) on 2009-09-01T14:45:37.000+0000
I just added a complete rework of Zend_Validate_EmailAddress... this feature has also been added to incubator for tests.See SVN r17945 for details.
Posted by Thomas Weidner (thomas) on 2009-09-09T12:59:00.000+0000
Implemented as new feature with r18050 for ZF 1.10
Have you found an issue?
See the Overview section for more details.