Zend Framework

The MX check is only processed when dns_get_mx is available.
Within Windows for example no mx check is done.

Well actually:

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)

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.

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 foo@yyahoo.de 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.

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.

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

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.

Hi!

@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.:

1. antoniabur@uyahoo.com
SMTP error from remote mail server after RCPT TO:<antoniabur@uyahoo.com>:
host ancksunamun2.hosting [172.16.100.252]: 550 Cannot route to <antoniabur@uyahoo.com>

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.

2. ralupop2003@yohoo.com
SMTP error from remote mail server after RCPT TO:<ralupop2003@yohoo.com>:
host ancksunamun2.hosting [172.16.100.252]: 550 Cannot route to <ralupop2003@yohoo.com>

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

• If the MX record returns with an empty (or invalid MX) value, e.g.: ".", the address should be marked as invalid

• It would be a good idea to extend the validator to OPTIONALLY detect and check for the following reserved network segments and mark as invalid:

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
224.0.0.0/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.

Ok:

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

This modified (patched) Zend_Validate_EmailAddress class allows users to perform a deeper email address analysis.

• The class contains new constant value: self::INVALID_NETWORK_SEGMENT that tells if the host is not in a routable network segment.
• There are several new private methods that calculate subnet informations from the IP address
• The isValid method has been modified to optionally use these new features over the default behaviour in the following way:
  1. if the dns_get_mx(); function does not return with any MX record, the host may sill accept messages if there's a valid A, AAAA or A6 record
  2. if the dns_get_mx(); function returns with one or more MX record for the host, each of them must be checked for at lesat one valid address.

The modified file is based on Zend Framework 1.8 RC source.

Please check it, test it, modify it if needed.

@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

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.

Implemented as new feature with r18050 for ZF 1.10